Oracle Utilities Customer Care & Billing

Business Processes Guide

Oracle Corporation

Copyright © 2013, 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 software or related documentation is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS

Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

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 which 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.

This software or hardware and documentation may provide access to or information on 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. 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.

Customer Information

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

Contents

Understanding The V

Navigating The V Using Control Central

Maintaining The V

Dashboard Portal

Setting Up Bill Print Groups

Landlord Reversion

Using The Premise Replicator

Start / Stop

The Big Picture Of Customer Contacts

Printing Letters

Maintaining Declarations

Service Tasks

Self-Service Tasks

Understanding The V

The "V" is the shape of a diagram we use to illustrate the objects that form the core of the system: Person, Account, Premise, Service Agreement, and Service Point. These objects hold demographic, geographic, and financial information about your company's customers and properties. The following diagram illustrates the objects in the "V", as well as important objects related to the "V" objects ( bill, payment, meter, field activity, meter read).

You must intuitively understand the concepts embodied in the "V" before you can perform the business processes in the system. In this section, we provide an overview of these objects. In later sections, we describe how you maintain this information.

Contents

Persons

Accounts

Service Agreements (SAs)

Premises

Service Points (SPs)

Putting It All Together

Sample V For A Residential Customer

Sample V For A Commercial Customer With Multiple Premises

How To Set Up Customer Hierarchies

Persons

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

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

Most persons are linked to at least one account because, without an account, the person cannot receive a bill. There are rare examples of persons without accounts, for example, collection agencies that don't receive bills, parent companies that receive statements (as opposed to bills), etc.

Fastpath:

Refer to Maintaining Persons for more information about persons.

Accounts

Accounts are the entities for which bills are created. You must create at least one account for every customer. The account contains information that controls when bills are created and how they are formatted.

Every account must reference at least one person because the person contains the customer'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, the third party guarantor of the account's debt, persons who receive copies of bills, etc.

Most accounts are linked to at least one service agreement because, without a service agreement, there is nothing on which a bill can be based. An account without a service agreement 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.

Service Agreements (SAs)

Think of a service agreement as a contract between your company and a customer. The service agreement contains the terms and conditions controlling how the system calculates charges for the specific service supplied to the customer.

Every account should have at least one service agreement (otherwise, the account has no financial obligations with your company). There is no limit to the number of service agreements that may be linked to an account. However, most residential customers have X service agreements where X is the number of services sold by your company. For example, if your company sells both electricity and gas, most accounts will have two service agreements.

A separate service agreement is required for every service supplied to every account. Why? Because a variety of fields may differ for each service agreement:

- Obviously, the price of the service is different.

- The credit and collection criteria may be different.

- The general ledger account to which the resultant revenue and/or receivable are linked is different.

- The sales tax could be different for each good / service / location.

- The service point measuring consumption will frequently be different.

- The list goes on...

Service agreements that bill for premise -based services are linked to one or more premises via their service points. When you link a service point to a service agreement, you are telling the system that the service agreement's account will pay for the service point's service.

Fastpath:

Refer to Maintaining Service Agreements for more information.

Premises

A premise is created for every location to which your company supplies service. On a premise is maintained geographic information like:

- The address.

- Characteristics that determine tax jurisdictions.

- Descriptions of unusual situations associated with a property.

- The list goes on...

Most premises have at least one service point because, without a service point, there are no services supplied to the premise. A premise without service points may exist; you just won't be able to do much in the system with such a premise.

Fastpath:

Refer to Maintaining Premises for more information about premises.

Service Points (SPs)

Think of a service point as a specific location at a premise where your company supplies service. A service point contains information describing the type of service and how it is measured.

A premise should have at least one service point (otherwise, there are no services supplied to the premise). However, it is permissible for a new premise to exist without service points until you are ready to physically start service at the premise.

A premise may have many service points. However, most residential premises have X service points where X is the number of services sold by your company. For example, if your company sells both electricity and gas, most of your premises will have two service points.

Separate service points are required for every service supplied to a premise. Why? Because a variety of fields may differ for each service point:

- The cycle in which the meter is read.

- The network facilities that provide service.

- Basic characteristics about the service (e.g., pipe size, take point, amperes, etc.).

When you link a service point to a service agreement, you are telling the system that the service agreement's account will pay for the service point's service.

Fastpath:

Refer to Service Point - Main Information for information about how to add and update service points.

The following topics describe the relationship between a service point and the physical devices that may be installed at the service point.

Contents

Metered versus Item-Based versus Non-Badged Service Points

Service Points With Multiple Items

Metered versus Item-Based versus Non-Badged Service Points

There are three major categories of service points:

- Those where consumption is measured (e.g., electricity, gas, water) by a meter. We refer to these types of service points as metered . A metered service point may have zero or one meter installed at any instant in time. Over time, a metered service point may have many meters installed and removed.

- Those where consumption is not measured, but where there exists some type of badged (i.e., uniquely identified) item that impacts billing and dispatching (e.g., streetlights, a security camera). We refer to these types of service points as item -based. An item-based service point may have zero or one badged item installed at any instant in time. Over time, an item-based service point may have many badged items installed and removed.

- Those where one or more non-badged items (i.e., items without a unique identity) that have some impact on billing or dispatching exist. We refer to these types of service points as unbadged. At a single instant in time, a non-badged service point may have many unbadged items installed at it. Refer to Service Points With Multiple Items for an illustration of such a service point.

Note:

Multiple unbadged items can also be defined on metered and item-based service points. Under some billing scenarios, you may define non-badged items on a metered or item-based service point. For example, assume you have an item-based service point that exists to support lamp service. Also assume that the rate for lamp service is based on the type of lamp and the number of feet of electric wire between the pole and the power source. To define the number of feet of wire, you could create a non-badged item type called WIREFEET and indicate the number of feet on the item-based service point. On this service point, you can also keep track of the specific lamp that's installed.

Fastpath:

Refer to The Big Picture Of Meters, Items and Equipment for more information about meters and items. Refer to Meters & The "V" for more information about installing meters at a service point. Refer to Items & The "V" for more information about installing items at a service point.

Service Points With Multiple Items

An example will help explain a single service point with multiple non-badged items. Assume you have a parking lot with 4 lights, none of which are badged.

You can set up the above example with one premise with a single non-badged service point. On the service point, you create one item for each type of item in the parking lot:

- 20K lumen lamp

- 10K lumen lamp

- pole

- bracket

For each type of item, you indicate the quantity that exist in the parking lot:

- 20K lumen lamp - 2

- 10K lumen lamp - 2

- pole - 4

- bracket - 4

Fastpath:

Refer to Service Point - Multiple Items for more information about multi-items on service points.

Putting It All Together

To help you understand the significance of the "V", consider a few scenarios:

- When a new residential customer starts service, you create both person and account objects for the new customer. In addition, you also create service agreements and link them to the appropriate service points. You won't have to create a new premise and service points because the customer is probably moving into an existing house.

- If the residential customer moves within your service territory, you don't have to set up new person or account objects. You also don't have to set up new premise and service point objects if the customer is moving into an existing house. You only have to create new service agreements and link them to the appropriate service points (and the system does most of the service agreement set up processes for you).

- A business with a single location uses the same "V" objects as does a residential customer. If the business expands and starts using services at other locations, you simply link new service agreements to the existing account. You don't have to redefine person or account information.

Note:

Bottom line. A person and an account are needed for every customer. After these exist, future service requests simply involve stopping existing service agreements and starting new ones. You typically won't have to add or modify premise or service point information unless new locations are built.

Fastpath:

For more information, refer to Maintaining The "V", Navigating The "V" Using Control Central, The Big Picture Of Starting Service, and The Big Picture Of Stopping Service.

Sample V For A Residential Customer

The following illustration shows a simple residential customer's "V" objects.

Sample V For A Commercial Customer With Multiple Premises

The following illustration shows the "V" objects for a commercial customer who pays for service at two premises.

Note:

The above example shows a separate service agreement per premise. If your rates allow, you could link both premises to a single service agreement.

How To Set Up Customer Hierarchies

Consider the following customer hierarchy:

The above hierarchy shows a parent company ( McDonalds Corporation ) with two subsidiaries and one general manager. Each subsidiary, in turn, has subsidiaries and these subsidiaries can have their own subsidiaries ...

You must set up a person for every individual and business in a hierarchy. After the basic demographic information is defined, you define each person's children using the Person to Person page.

Note:

A script can be used to set up a hierarchy. The demonstration database contains a script that guides users through the process of setting up a hierarchy. Please speak to your implementation staff if you'd like to import this script for use in your implementation.

After a hierarchy is set up, the system displays its members in the Person Tree Zone (this is a zone on the Customer Information Portal). In addition, if the persons in a hierarchy have accounts, summary information about these accounts is displayed in the Account Summary Zone.

While hierarchies would typically be set up to define parent companies and subsidiaries, you can use this functionality for many other purposes. For example, a customer relationship manager could set up a hierarchy containing their "important" customers. To do this, they'd need to create a "dummy" person for the parent and then link the "important" customers to it. After this hierarchy is set up, the manager could see a summary of these customers in the Account Summary Zone whenever they display the "dummy" person.

Navigating The V Using Control Central

Control Central is the name given to the functionality that helps you:

- Find a person.

- Find an account.

- Find a premise.

- View information about a person / account / premise.

- View alerts and messages about a person / account / premise.

- Navigate to pages that contain information related to a person / account / premise.

Fastpath:

For more information about the relationships between persons, accounts, and premises, see Understanding The "V".

Contents

Control Central - Main

Control Central - Account Information

Control Central - Customer Information

Control Central - Account Tree

Control Central - Premise Tree

Control Central - Bill/Payment Tree

Control Central - Pay Plan Tree

How To Add A New Customer From Control Central

Finding Who Pays For A Meter

Finding Who Pays For An Item

Control Central - Main

Open Control Central, Main to find a customer and/or a premise.

Note:

Automatic transfer to Account Information tab. You are automatically transferred to Control Central - Account Information when an account / premise is selected on this page.

The contents of this section describe how to use Control Central - Main.

Contents

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 premise.

Note:

Multiple search criteria. You can search for a customer using a combination of Name, Address, City, and Postal Code. When multiple fields are populated, the system searches for customers that match all such criteria. For example, if you enter a Name of Smith , and a Postal code of 94114 ; only customers 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 customer 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 customer, 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 Customer From Control Central for more information about how to add a new customer (i.e., Person and Account) from this page.

- Click the button. Clicking this button opens the Order - Main page where you can add a new person (and initiate service for the new person). Refer to Order User Interface Flow for more information about how to add a new customer using an order.

Address

Use this field to search for a premise 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 premise 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 premise 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.

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 customer 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 premise using one of the geographic values linked to the premise or one of its service points. 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 premises / service points with these digits.

After entering this information, click the search button (or press Enter) to search for a premise / service point with this ID. The system displays every premise with the input ID in the search results.

Meter ID

Control central does not allow you to find a customer using a meter ID. If you know the meter ID and want to find who's paying for its service, transfer to Meter/Item Search and display the meter. All customers who have paid for service measured by the current configuration of the meter will be displayed on this page. You can then use the various context menu buttons to return to Control Central where details about the customer are displayed.

Item ID

Control central does not allow you to find a customer using an item ID. If you know the item ID and want to find who's paying for its service, transfer to Meter/Item Search and display the item. All customers who have paid for the item will be displayed on this page. You can then use the various context menu buttons to return to Control Central where details about the customer are displayed.

Note:

Automatic transfer to Account Information tab. If your search criteria result in a single customer being retrieved, you are automatically transferred to Control Central - Account Information with that customer's information displayed.

Search Options

The Show All Premises search option controls whether you see all of an account's premises in the search results. If turned on, every premise linked to an account is shown in the search results. If turned off, only one premise is shown per account (and this premise 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 premise-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 premises linked to the account (and then select one of the rows). Please note, an alert highlights if the selected account has other premises.

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 customer in the system before it can return the results.

Search Results

The search results at the bottom of the page contain persons, accounts, and premises that match your search criteria. The information displayed in this area differs depending on the type of search you perform. You can perform searches on a customer's name, address, or phone number.

Note:

The first X matches are returned. The number of customers 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.

Automatic selection if only one match. You don't have to select the desired person / account / premise 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.

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 customer you want, press enter to select it. If not, press tab until you've highlighted the desired customer (and then press enter to select it).

Use next and previous buttons to step through a list of customers. 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 in list and previous in list buttons 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 the Account Information 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 premise.

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 account context menu navigates to the Account Information tab page.

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.

Contents

Account Activity History Zone

Account Financial History Zone

Alert Zone

Applicable Campaigns Zone

Bill Graph Zone

Billed Consumption Zone

Context Zone

Credit and Collections Info Zone

Customer Information Zone

Field Activity Information Zone

Financial Information Zone

Premise Information Zone

SA Premise List Zone

Service Credit Membership Zone

Timeline Zone - Account Info

Account Activity History Zone

The Account Activity History Zone is a grid that summarizes a variety of account-related events (in reverse chronological order). 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

Severance Event. One row is displayed for every Pending and Awaiting Field Activity Completion severance event linked to the account's service agreements.

The severance event's description, status and trigger date (if non-blank). If the event is dependent on earlier events, the earlier events' type and status is appended

Severance Process - Events

Severance Process. One row is displayed for every Inactive severance process linked to the account's service agreements. Inactive processes are displayed (as opposed to active because active severance processes have pending events and pending events are shown separately.

The severance process's SA type description, severance process template description, status and create date/time

Severance Process - Main

Collection Event. One row is displayed for every Pending collection event linked to the account.

The collection event's description, status and trigger date (if non-blank)

Collection Process - Events

Collection Process. One row is displayed for every Inactive collection process linked to the account. Inactive processes are displayed (as opposed to active) because active collection processes have pending events and pending events are shown separately.

The collection process's description, debt class description, status and create date/time

Collection Process - Main

Overdue Event. One row is displayed for every Pending overdue event linked to the account.

The overdue event's standard information string this is dynamic as it is constructed by an algorithm)

Overdue Process - Events

Overdue Process. One row is displayed for every Inactive overdue process linked to the account. Inactive processes are displayed (as opposed to active) because active overdue processes have pending events and pending events are shown separately.

The overdue process's standard information string (this is dynamic as it is constructed by an algorithm)

Overdue Process - Main

Cut Event. One row is displayed for every Pending cut event linked to the account.

The cut event's standard information string (this is dynamic as it is constructed by an algorithm)

Cut Process - Events

Cut Process. One row is displayed for every Inactive cut process linked to the account. Inactive processes are displayed (as opposed to active) because active cut processes have pending events and pending events are shown separately.

The cut process's standard information string this is dynamic as it is constructed by an algorithm)

Cut Process - Main

Write-off Event. One row is displayed for every Pending write-off event linked to the account.

The write-off event description, status and trigger date (if non-blank)

Write-off Process - Events

Write-off Process. One row is displayed for every Inactive write-off process linked to the account. Inactive processes are displayed (as opposed to active) because active write-off processes have pending events and pending events are shown separately.

The write-off process template's description, status and create date/time

Write-off Process - Main

Customer Contact. One row is displayed for every customer contact associated with the main customer linked to the account.

The main name of the person associated with the customer contact, the customer contact's class and type, and the customer contact's date

Customer Contact - Main

Field Activity. One row is displayed for every unique non-cancelled field activity linked to the account's non-cancelled/non-closed service agreements.

The field activity type, scheduled date/time and status

Field Activity - Main

Pay Plan. One row is displayed for every non-cancelled pay plan linked to the account

The pay plan's type, status, date, and amount

Pay Plan - Main

Payment Arrangement. One row is displayed for every non-cancelled payment arrangement (i.e., service agreement with a special role of Payment Arrangement) linked to the account

The service agreement's division, SA type, status, and effective period.

Payment Arrangement - Main

Credit Rating History. One row is displayed for every credit rating transaction that affects the account's credit rating

The effect on the account's credit rating, the end date, creation date and the process that created the transaction.

Account - C&C

Cash Only History. One row is displayed for every credit rating transaction that affects the account's cash-only score

The effect on the account's cash-only score, the end date, creation date and the process that created the transaction.

Account - C&C

Case. One row is displayed for every case associated with the account.

The case's standard information.

Case - Main

Rebate Claim. One row is displayed for every rebate claim .

The rebate claim's description.

Rebate claim portal

Warning:

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.

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:

Arrears 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 , AdjustmentandAdjustment (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.

Warning:

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.

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 you click on the hyperlink. The table below lists 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. Refer to Count Customer Contacts of a Given Type and Count Pay Plans with a Given Status for examples of such algorithms.

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

6

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

Account - Alert

Account has Multiple Premises

24

Appears when the account has service agreements whose service points reference multiple premises

Control Central - Account Tree

Account SA(s) linked to Umbrella Agreement

41

Appears when the account has one or more service agreements linked to a non-canceled terms of service record for an umbrella agreement that is in effect on the current date.

Terms of Service - Main

Active Write Off Process

10

Appears when an account has an active write off process. Refer to How Are Write off Processes Cancelled for information describing when a write-off process is deactivated.

Write Off Process

Appointment Exists

37

Appears when a premise has a non-canceled, non-completed field activity that's linked to an appointment.

Appointment

Auto-Pay Active: auto pay method description

25

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

Comment Exists On Account

5

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

Account

Field Activity Pending

19

Appears when any of the premise's service points have a pending field activity

Field Activity

Field activity type alert message

12

Appears when the premise has a service point with a completed field activity whose type has been marked with an alert message (refer to Field Activity Type)

Field Activity

Held Order Exists

32

Appears when the person has a heldorder.

Order

Installation dynamic alerts

42

You can install plug-in algorithms on the installation record that will create alerts (if given situations exist). Refer to Count Customer Contacts of a Given Type and Count Pay Plans with a Given Status for examples of such algorithms

Varies by plug-in

Landlord Exists

27

Appears when a landlord is linked to the premise

Premise

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

3

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

26a

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

Control Central - Account Tree

Non-cash Deposit

15

Appears when the account has non-cash deposits effective on the current date

Account - Deposit

n Open Contact(s) for Person

4

Appears if there are open customer contacts associated with the person. Refer to Customer Contacts Can Be Used As Case Files for more information.

Customer Contact

Pending Order Exists

31

Appears when the person has a pendingorder.

Order

Pending Proposal SA Exists

36

Appears when the account has a proposal service agreement in the pending state. Refer to Proposal SA State Transition for more information.

Service Agreement

Pending Quote Exists

34

Appears when the account has a pending quote. Refer to Quote Lifecycle for more information.

Quote

Pending SA Relationships

16

Appears when the account has SA relationships that are pending

SA Relationship

Pending Stop

18

Appears when there is a service agreement in the state of pending stop linked to the account. Refer to The Lifecycle Of A Pending Stop Service Agreement for more information.

Start/Stop

Person is linked to Multiple Accounts

22

Appears when the person has multiple accounts. A person's accounts are maintained on the Account - Person page.

Control Central

n Persons on Account

26c

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

Control Central — Account Tree

Premise has Multiple Accounts

23

Appears when the premise has service points that are linked to service agreements that are linked to different accounts.

Control Central — Premise Tree

Premise has n Child Premise(s)

40

Appears when the premise is defined as the parent premise for one or more premises. Refer to Define Premise Hierarchy for more information.

Premise Management

Premise is linked to Parent Premise

39

Appears when the premise defines a parent premise. Refer to Define Premise Hierarchy for more information.

Premise

Quotable Proposal SA Exists

35

Appears when the account has a proposal service agreement in the quotable state. Refer to Proposal SA State Transition for more information.

Service Agreement

Quote Awaiting Customer Response Exists

33

Appears when the account has a complete quote with a quote detail that references a quotable proposal SA. Refer to Quote Lifecycle for more information.

Quote

Reactivated SAs Exist

21

Appears when any of the account's service agreements exist in the state of reactivated (i.e., a financial transaction has been generated after the service agreement was closed ). Refer to The Lifecycle Of A Service Agreement for more information.

Service Agreement

SA type alert message

13

Appears when the customer has a service agreement with an SA type that has been marked with an alert message (refer to SA Type - Details)

Note that if the account in control central has more than one service agreement, pressing the drill down button will also launch the service agreement search dialog.

Service Agreement

SA type description and status of a non-billed budget service agreement

14

Appears for every pending start , pending stop , and activenon-billed budget that is linked to the account.

Non-billed Budget Service Agreement

Seasonal Address Exists

38b

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)

38a

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

Statement Construct Active

28

Appears if the person has an active statement construct

Statement Construct

Third Party Guarantor

26b

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

Control Central - Account Tree

Note:

Legacy Alert Order. Certain system-generated alerts have been converted to algorithms that may be plugged-in on the installation record. This implies that the order in which these alerts now appear might differ to the prior system-generated alerts order. If your implementation wishes to retain the legacy order for these alerts, the Use Legacy AlertsOption Type for the General System Configuration Feature Configuration must be defined with a value of Y , and the alert algorithms should not be plugged-in on the installation record. If this option is set, then the alerts in the following table will be treated as system-generated alerts. These alerts are listed in alphabetical order, but a column indicating the order in which they will appear is included. Note that if both the feature option and alert algorithms are configured, these alerts may appear twice on the Alert Zone.

Alert Text

Order

Description

Drill Down Transfers You To

Cash Only Account

11a

Appears when the account's cash only score exceeds the cash only threshold on the CIS installation table. Refer to How are credit rating transactions created for information describing how a cash-only score is affected by various system and user events.

Control Central - Account Tree

Collection Process Active

8

Appears when an account has an active collection process. Refer to How Are Collection Processes Cancelled for information describing when a collection process is deactivated.

Collection Process

Collection Referral Active

9

Appears when the account has active collection agency referrals.

Collection Agency Referral

Credit rating: NNNN

11b

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

Account - C & C

Life Support / Sensitive Load on Person

1

Appears when any of the account's persons has life support or sensitive load information

Person

Life Support / Sensitive Load on Premise

2

Appears when the premise has life support or sensitive load information

Premise — Misc.

Pending Start

17

Appears when there is a service agreement in the state of pending start linked to the account. Refer to The Lifecycle Of A Pending Start Service Agreement for more information.

Start/Stop

Severance Process Active

7

Appears when any of the account's service agreement has an active severance process

Appears when an account has an active severance process. Refer to How Are Severance Processes Cancelled for information describing when a severance process is deactivated.

Severance Process

Applicable Campaigns Zone

The Applicable Campaigns Zone lists the campaigns that may be of interest to the customer. If you press a campaign's Add Order button, you will be transferred to the Order transaction where you can walk the customer through the campaign's provisions and determine if they are interested in its goods and services.

Fastpath:

Refer to The Big Picture Of Campaign Eligibility for more information.

Warning:

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 customer'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.

Billed Consumption Zone

The Billed Consumption Zone illustrates the amount of consumption on each of the customer's historical bills. Up to three units of measure (UOM) are shown for each bill. The system uses the graph UOM's defined on the SA types associated with the customer's active service agreements. If more than three graph UOM's are detected for a customer, the system uses those associated with the service agreement types with the highest bill print priorities.

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.

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.

Context Zone

The Context Zone contains basic information about the Person / Account / Premise 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 customer.

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 Amountversus Payoff Amount for more information.

Aged Debt Bar If the account's Current Balance is greater than zero, a colored bar is displayed adjacent. This bar provides information about the age of the account's debt.

The number of segments that appear in this bar is dependent on the elements of the customer's aged balance. The following segments may appear:

- disputed debt (If you handle disputed debt as described in Disputing Items),

- new charges and debt between 0 and X days old (where X is the account's customer class's bill due days),

- debt between X to 30 days old,

- debt between 31 to 60 days old,

- debt older than 60 days

Note:

If you hover the mouse pointer over a segment of the bar, the respective amount of debt will appear. If you click on the arrears bar you will be taken to the Account Financial History page. Note that information about debt balances by age is not applicable to open-item accounts.

Premise This part of the context area contains the premise address. Note, the address information is formatted by a plug-in algorithm on the installation record. Refer to the base package's premise format algorithm for an example. If you prefer a different format, your system administrator should configure the system appropriately

(Start Button) Push this button if you want to start service for the account and the service isn't at a premise (e.g., a deposit). Refer to The Big Picture Of Starting Service for more information.

(Stop Button) Push this button if you want to stop service for the account at the premise. Refer to The Big Picture of Stopping Service for more information.

Credit and Collections Info Zone

The Credit and Collections Info Zone is a grid that contains a variety of credit & collections-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

Severance Process. One row is displayed for every Active severance process linked to the account's service agreements.

The severance process's description and create date/time

Severance Process - Main

Collection Process. One row is displayed for every Active collection process linked to the account.

The collection process's description and create date/time

Collection Process - Main

Write-off Process. One row is displayed for every Active write-off process linked to the account.

The write-off process's description and create date/time

Write-off Process - Main

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 is is constructed by an algorithm)

Overdue Process - Main

Cut Process. One row is displayed for every Active cut process linked to the account's service agreements.

The cut process's standard information string (this is dynamic as is is constructed by an algorithm)

Cut Process - Main

Pay Plan. One row is displayed for every Active pay plan linked to the account

The pay plan type's description and create date/time

Pay Plan - Main

Payment Arrangement. One row is displayed for every non-cancelled, non-closed payment arrangement (i.e., service agreement with a special role of Payment Arrangement) linked to the account

The service agreement's SA type description, start date and status

Payment Arrangement - Main

Warning:

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.

Customer Information Zone

The Customer 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)

Main Customer

The main customer'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

CIS Division

The account's CIS division

Account - Main

Customer Class

The account's customer class

Account - Main

Bill Cycle

The account's bill cycle

Account - Main

Current Credit Rating

The account's current credit rating

Account - C&C

Next Credit Review Date

The next date on which the account's debt will be reviewed by the account debt monitor. Refer to When Is An Account's Debt Monitored for more information.

Account - C&C

A separate row is displayed for each characteristic linked to the account. Each row's label is the characteristic type's description. If the characteristic is future dated, the effective date enclosed in parentheses prefixes the 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)

Budget Plan

The account's budget plan

Account - Budget

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

Service Provider.

The service provider's name and a description of the service provider's billing relationship as of the effective date.

SA Relationship - Main

Warning:

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 Customer Information zone.

Field Activity Information Zone

The Field Activity Information Zone displays the following information about every non-cancelled field activity linked to the premise's service points.

- The field activity's Schedule Date/Time.

- FA Information contains a concatenation of information about the premise, service point and field activity.

- If the field activity is linked to a field order, the Field Order's Status is displayed.

You can press the adjacent Go To button to transfer to Field Activity - Main.

Warning:

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.

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. If the account's current balance is greater than zero, a colored bar is displayed adjacent. This bar provides information about the age of the account's debt. Refer to Context Zone for more information about this bar.

Clicking on the Arrears Bar or the hyperlink takes you to Account Financial History - Main

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, incompleteautomatic 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 and when your installation option's Auto Pay Creation Option is Create on Extract Date . If the installation option is Create at Bill Completion , then the Autopay will be created immediately at bill completion time and no information is displayed here. 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 when your installation option's Auto Pay Creation Option is Create on Extract Date . If the installation option is Create at Bill Completion , then the payment for the Autopay will be created immediately at bill completion time and no information is displayed here. Refer to How And When Are Automatic Payments Created? for more information.

Payment Event - Main

Premise Information Zone

The Premise Information Zone is a grid that contains information about the current premise. 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 premise.

Label

What Is Displayed

Drill Down Transfers You To

Premise Information

The premise's address. Note, the address information is formatted by a plug-in algorithm on the installation record. Refer to the base package's premise format algorithm for an example. If you prefer a different format, your system administrator should configure the system appropriately

A premise context menu has been provided (allowing you to drill to a variety of premise-oriented pages)

CIS Division

The premise's CIS division

Premise - Main

A separate row is displayed for each characteristic linked to the premise. The label in each row is the respective characteristic type's description.

The characteristic's value

Premise - Characteristic

Landlord

The name of the premise's landlord

Landlord Agreement

Service Point Information. Note, a separate row is displayed for each service point linked to the premise

The service point's type and service cycle (if specified)

A service point context menu has been provided (allowing you to drill to a variety of service point-oriented pages)

Meter Configuration. This row is displayed if a meter configuration is currently installed at the service point. If so, this row's label is indented and displayed beneath the related service point.

The meter configuration's meter type, badge number, installation date, meter configuration type, number of registers

A meter configuration context menu has been provided (allowing you to drill to a variety of meter configuration-oriented pages)

Last Meter Read. This row is displayed if a billable meter read exists for the meter configuration that is currently installed at the service point.

The most recent billable meter read's date and time.

Meter Read - Main

Next Meter Read. This row is displayed if the service point references a service cycle.

The next scheduled meter read date and an indication of the service point's service cycle

No drill down is available

Item Information. This row is displayed if an item is currently installed at the service point. If so, this row's label is indented and displayed beneath the related service point.

The item's type, badge number and status

An item context menu has been provided (allowing you to drill to a variety of item-oriented pages)

SA Premise List Zone

The SA Premise List Zone contains a row for each non-cancelled, non-closed service agreement linked to the account. The Premise (if any), Current Balance, Payoff Balance, and SA Information is displayed for each service agreement.

The service agreements appear in the following order:

- Service agreements linked to the premise on which you're working appear first.

- Next appear service agreements linked to the account that don't have a premise (deposits, charitable contributions, etc.).

- Following this are the remaining service agreements linked to the account.

Note:

Dimmed Payoff Balance. A service agreement's Payoff Balance will be dimmed if it is the same as its Current Balance. Refer to Current Amount versus Payoff Amount for more information.

Warning:

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.

Service Credit Membership Zone

The Service Credit Membership Zone contains a row for each pending and active service credit membership linked to the account. It will also show any inactive membership that contains a balance. The Service Credit Membership Type, Membership Status and Balance (if applicable) are displayed for each membership.

Timeline Zone - Account Info

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 bills have been received for a customer.

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

Contents

Timelines Zones Are Configured By Your Implementation Team

The Anatomy Of A Timeline Zone

You Can Move Through Time

Timelines Can Have Many Lines

Each Line Shows Events

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

An Event's Hover-Text Can Contain Additional Information

Clicking On An Event Shows More Information In The Detail Area

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 customer, and another that shows when bills have been sent to the customer. 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 bill line in a timeline has a separate event for every bill sent to a customer. Each line's description contains the number of events on the line.

Warning:

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.

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 meter reads have occurred can use different colors and/or icons to visually differentiate between estimated and non-estimated meter reads.

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 a case shows significant dates in the case's lifecycle (e.g., when it was created, and when it was closed). Whereas the hover text for a meter read shows each register reading.

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 field activity event, the field activity'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. For example, if you click on a bill that has been canceled and rebilled after it was initially sent to the customer, information about the net result of the changes appears.

- BPA scripts that can be executed to perform business processes on the object. For example, if you click on a bill event, BPA scripts may appear that can guide you through initiating a bill dispute or canceling the bill. Note, BPA scripts are prefixed with the "wizard's hat" icon.

Control Central - Customer 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, premises, and service agreements 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.

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.

Contents

Communication History Zone

Person Tree Zone

Active Account Summary Zone

Timeline Zone - Customer Info

Communication History Zone

The Communication History Zone displays customer contacts created for a customer and any communications (or notifications) events sent to a customer to provide a single view of all communications.

The following details are displayed for each communication and the page to which you will be transferred to if you click on a hyperlink (if applicable):

- Date / Time:

- For a customer contact related entry, the Customer Contact Date / Time for the communication

- For lead / lead event related entries, the Log Date / Time where the Log Type is Notification for the communication

- Details – Communication Details:

- For a customer contact related entry, the Contact Class Description / Contact Type Description is displayed

- For lead / lead event related entries, the Log Messages for both the lead / lead event for the communication is displayed. There will be one entry for the lead and another for the lead event. If the lead / lead event created a customer contact for a communication, then an entry for the customer contact will also exist.

- Related Object

- For a customer contact related entry, a hyperlink to the customer contact record

- For lead / lead event related entries, there will be one entry for the lead and another for the lead event.

- For the lead related entry, a hyperlink to the lead related to the communication

- For the lead event related entry, a hyperlink to the lead event related to the communication

Person Tree Zone

The tree in this zone shows a great deal of information including:

- All accounts linked to the person in context. Refer to Understanding The V for more information.

- 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 Summary Zone lists all accounts related to the person in context where they are the main customer on the account. 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 customer 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 and Arrears This column contains the account's current balance. If the account's current balance is greater than zero, a colored bar is displayed in the Arrears column. This bar provides information about the age of the account's debt. Note that information about debt balances by age is not applicable to open-item accounts. Refer to Context Zone for more information about this bar.

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 customer.

Timeline Zone - Customer Info

Your implementation may have configured this page to show one or more timeline zones. Refer Timeline Zone - Account Info for a description of how to use these zones.

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, premises, and service agreements 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 - Premise Tree

Once Control Central - Main has a premise context, you can navigate to the Premise Tree to see an overview of the accounts, service points, and service agreements linked to the premise.

Description of Page

This page is dedicated to a tree that shows the various objects linked to a premise. 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.

- Credit and correction notes appear as separate nodes.

Control Central - Pay Plan Tree

Once Control Central - Main has an account context, you can navigate to the Pay Plan Tree to see an overview of account's debt and the status of an account's pay plans.

Description of Page

This page is dedicated to a tree that shows the pay plans linked to an account. It displays both current and past (expired) pay plans. 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.

How To Add A New Customer From Control Central

There are three ways to add a new customer from control central:

- You can add a new customer by invoking the Person and Account pages from the menu bar. This is not the recommended approach, as it requires several screen interactions; either of the following approaches is preferable.

- If your team has set up sales and marketing campaigns, you can use the order transaction to add a new customer. Refer to Order User Interface Flow for more information. Refer to Sales & Marketing for background information about sales and marketing campaigns.

- Adding a Person from Control Central. You navigate as follows:

- You start from Control Central - Main . On this page, you determine if the customer already has an account. 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 customer. When finished, proceed to step 3.

- Enter the customer's names, phone numbers, and IDs. Click Save (or press ALT+S) to add the person and account. The value of Add Account and Start Service is defaulted to "on" and the Customer Class defaults based on the Person Type. This means that when you click save the following will happen: a new person is added, a new account is added, the new person is linked to the new account, and you will be automatically transferred to Start / Stop where you can start service. (Note: This is the default behavior of the system. However, an implementation can define different functionality by setting up a customer information options feature configuration.

Note:

Default note. When the system links the person to the account, it defaults the relationship type from the installation options. A different relationship type can be defined for persons versus businesses on the installation record.

If you need to tinker with information on the account, transfer to account maintenance (use the context menu) and make any necessary changes.

Finding Who Pays For A Meter

If you know the customer's meter number but you don't know the customer, you have the following options:

- Go to Meter - Main and display the meter. The meter's last premise will be displayed on this page. Use the premise's context menu to go to Control Central.

- Go to Meter/Item Search and display the meter. All customers who have paid for service measured by the current configuration of the meter will be displayed on this page. You can then use the various context menu buttons to toggle to related information.

Finding Who Pays For An Item

If you know the customer's item number but you don't know the customer, you have the following options:

- Go to Item - Main and display the item. The item's last premise will be displayed on this page. Use the premise's context menu to go to Control Central.

- Go to Meter/Item Search and display the item. All customers who have paid for the item will be displayed on this page. You can then use the various context menu buttons to toggle to related information.

Maintaining The V

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

Note:

Start / Stop Also Maintains The "V". The Start/Stop Pages also maintain many of the objects in the "V". For example, service agreements are created behind-the-scenes when you start service for a customer. This means you won't have to use most of the pages described in this section as part of your day-to-day activities. Rather, they exist in case you need to override what the system automatically set up for you.

Contents

Maintaining Persons

Maintaining Accounts

Account - SAs For A Debt Class

Using The Account / Person Replicator

Maintaining Service Agreements

Maintaining SA Relationships

Service Provider SA Relationship

Maintaining Premises

Maintaining Service Points

Maintaining Persons

On the person page, you define demographic information about your customers and every other individual or business with which your company has contact. The topics in this section describe the person page.

Fastpath:

For more information about persons and their place in the "V", refer to Understanding The "V". For more information about how most persons are added, refer to How To Add A New Customer From Control Central. For more information about how a person is required to set up a customer, refer to Customer Overview.

Contents

Person - Main Information

Person - Correspondence Information

Person - Characteristics

Person - Persons

Person - Persons Portal

Person - Main Information

The Main page contains core person information like names, telephone numbers, and forms of identification. Open this page using Customer Information, Person, Main.

Description of Page

Person Information contains basic information about the person. These values only appear after the person exists in the database. The ID is a system-assigned random number that stays with a person for the life of the system.

Note:

Formatting is performed by a plug-in. The format of Person Information is controlled 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.

The following information may be recorded about a person:

Person/Business indicates if the entity is a person or a business. Valid values are: Person , Business . This value controls how the person's primary name is validated.

Life Support / Sensitive Load indicates if the person has life support or sensitive load equipment. Valid values are: LS/SL (i.e., the person has life support / sensitive load equipment), None . If the customer has LS/SL equipment, make a note of the type of equipment in the field provided.

A premise can also have life support / sensitive load information. If the equipment is physically linked to the premise (e.g., a hospital has life support equipment), you should NOT specify the life support information on the person. Rather, transfer to Premise - Misc and specify life support information on the premise.

Note:

Alert and C&C. If the base package's C1-LSSL-PER algorithm is enabled on the installation record, and life support / sensitive load information is specified, an alert will appear when the person is displayed on control central. In addition, if a person has life support or sensitive load equipment, it is possible for a different credit & collection severance process to be kicked off if the person's account associated has overdue debt. Refer to Designing Your Severance Procedures for more information.

Person Names are used by Control Central to look for accounts and persons. In addition, a person's primary name is the addressee on the person's bill 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 RepresentationName 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.

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 by Control Central to look for accounts and persons. 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 used by Control Central when you look for a customer / premise based on their ID.

- They are used to highlight potential duplicate persons.

- Control Central displays a person's primary identification in the search results area to help a user identify the customer when multiple customers 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 customer.

- Indicate the ID Type. The ID Type defaults from the Installation Record based on the Person Type ( Person versus Business ).

- 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.

If you want to add an account for the person when you save the person information, turn on Add Account and Start Service. When this switch is on, you must also define the new account's Customer Class. If this information is specified, the system creates a new account and links the person to the account using the relationship type from the installation options. In addition, you will be transferred to Start / Stop where you can start service for the newly added account.

Note:

Default note. The account's customer class defaults from the Installation Record based on the Person Type ( Person versus Business ).

A message appears in the lower right corner of the page that describes the number of accounts the person has. You can click the adjacent go to button to transfer to Control Central - Customer Information on which all of a person's accounts appear.

Person - Correspondence Information

This page contains information that may be used to address bills, letters, quotes and statements. Use Customer Information, 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, letters, quotes and / or statements, specify the desired name in Override Mailing Name 1, 2, and 3.

Specify the Override Mailing Address fields if the person wants their bills, letters, quotes, and / or statements sent to an address other than their service addresses (for example, a post office box). In addition, 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.

Note:

Both the Start / Stop and Order transactions allow you to update the person's Override Mailing Address and their account's address source using a single transaction.

Address isn't everything. In addition to defining the person's Override Mailing Address, there may be additional tasks you must perform in order to route information to this address. Refer to the following links for more information: where are bills sent, where are letters sent, where are quotes sent and where are statements sent.

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.

- The Validate button on the person page will only be available if you have set the Allow Address Validation option type to Y on the General System Configuration feature configuration. Once clicked, the Address Validation Script on the General System Configuration feature configuration will be invoked to validate the entered address. Refer to unresolvable-reference.html for more information.

Specify the customer's Email Address if you communicate with the customer 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, where are letters sent, where are quotes sent and where are statements 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 Customer Language for more information on options for supporting multiple languages for your customers.

The Seasonal Addresses scroll is only used if the person wants their correspondence sent to an alternate address during predefined periods. For example, the customer may want their bills sent to their vacation cottage during the summer. Please be aware of the following:

- Seasonal addresses will only be used if the customer's bills, statements, quotes, and / or letters are routed via the postal service. For example, if you route bills to the customer via Email, the seasonal address will never be used to route bills to the customer. Refer to the following links for more information: where are bills sent, where are letters sent, where are quotes sent and where are statements sent.

- You don't have to specify a seasonal address for every part of the year. For example, if the customer wants their bills sent to their service 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 customer so desires.

- The Seasonal periodis 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.

- 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.

Person - Characteristics

The characteristics page contains information that describes miscellaneous information about the person. Use Customer Information, 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. Refer to How To Set Up Customer Hierarchies for more information about hierarchies.

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.

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.

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.

Warning:

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 Customer Information, 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 - Person Portal

Select Main Menu > Customer Information > Person and navigate to the Person Portal tab to view additional information associated with a Person.

Depending on your implementations requirements, you may define additional zones to appear on this Portal.

Refer to The Big Picture of Portals and Zones in the Oracle Utilities Application Framework Administration Guide for a description of portal and zone functionality.

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

General Information Zone

Person ID, Person Info are displayed.

Customer Notification Preferences Zone

The Customer Notification Preferences Zone displays notification preferences for the customer in context.

The following table lists the notification types that may appear in this zone and the page to which you will be transferred to if you click on a hyperlink (if applicable).

Type

What Is Displayed

Bill Routing for each account the person receives a copy of the bill.
Type hyperlink navigates you to the Account – Persons tab

Customer Information: Customer Information hyperlink navigates you to the Account

Contact Method: Bill Route Type specified on the account

Contact Information: Contact details for the Bill Route Type defined for the account

PPB New Charge if the person has an active prepaid biller.
Type hyperlink navigates you to the Prepaid Biller Task

Customer Information: Customer Information hyperlink navigates you to Prepaid Biller Task
Contact Method: Notification Preference for how the customer will be notified each time a new charge is calculated (specified on the Prepaid Biller Task)

Contact Information: Contact details for the new charge Notification Preference

PPB Payment Request if the person has an active prepaid biller.
Type hyperlink navigates you to the Prepaid Biller Task

Customer Information: Customer Information hyperlink navigates you to Prepaid Biller Task
Contact Method: Notification Preference for how the customer will be notified when their prepaid balance is less than the required minimum balance (specified on the Prepaid Biller Task)

Contact Information: Contact details for the payment request Notification Preference

Quote Routing for each account where the person receives a copy of quotes.
Type hyperlink navigates you to the Account – Persons tab

Customer Information: Customer Information hyperlink navigates you to the Account
Contact Method: Quote Route Type specified on the account

Contact Information: Contact details for the Quote Route Type defined for the account

Statement Routing for each statement the person will receive.
Type hyperlink navigates you to the Statement Construct – Main tab

Customer Information: Customer Information hyperlink navigates you to Person
Contact Method: Statement Route Type specified on the statement construct

Contact Information: Contact details for the Statement Route Type defined for the statement construct for each statement

Self-Service Notification Preferences Zone

The Self-Service Notification Preferences Zone displays active notification preferences for the customer in context and is only applicable if your implementation integrates with Oracle Utilities Customer Self Service.

The applicable notification types (self-service task types) are defined on the Self-Service Integration master configuration.

The following details are displayed for each active notification task (self service task) and the page to which you will be transferred if you click on a hyperlink (if applicable):

- Notification Task Information – Summary information for each of the customer’s active notification tasks. The hyperlink navigates you to the notification task (self-service task).

- Account Info – Details of the account linked to the notification task (self-service task). The hyperlink navigates you to the account.

- CSS Web User – End customer’s User ID supplied by Oracle Utilities Customer Self Service when the customer registers for the notification task (self-service task).

- Delivery Types – List of customer’s preferred communication channels specified on the notification task (self-service task).

Maintaining Accounts

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

- Most accounts are created when you add a new person or when you complete an order for a new customer.

- Many fields are populated behind-the-scenes as part of the service activation process.

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

Fastpath:

For more information about accounts and their place in the "V", refer to Understanding The "V".

Contents

Account - Main Information

Account - Auto Pay

Account - Person Information

Account - Financial Balances

Account - Bill Messages

Account - C&C

Account - Budget

Account - Deposits

Account - Characteristics

Account - Alerts

Account - Account Portal

Account - Main Information

The Main page contains core account information. Open this page using Customer Information, Account.

Description of Page

The primary name of the Account's main customer 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.

Note:

Formatting may be performed by a plug-in. The basic information about an account that appears at the top of this page (and on many other pages in the system) may be formatted by a plug-in algorithm on the installations record. Refer to the base package's account information algorithm for an example. If you prefer different formatting logic, your system administrator should configure the system appropriately.

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.

Customer Class plays a part in:

- If and when a customer is subject to late payment charges.

- The account's default collection class and when the account debt monitor reviews an account. Refer to The Big Picture of Credit & Collections for more information about how and when an account's debt is reviewed.

- And several other functions. Refer to and Setting Up Customer Classes for more information.

Note:

Default note. The customer class defaults from Installation Options - Account (Person Customer Class) and may be overridden at will.

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

Note:

CIS Division governs many functions. An account's CIS Division impacts its subsequent bill due dates, late payment charge dates, credit & collections review dates, its default budget plan, the roles assigned to To Do entries, and the calendar of workdays. Refer to Setting Up CIS Divisions and Setting Up Customer Classes for more information.

Access Group controls which users are allowed to view and update this account's information (including bills, service agreements, payments, premises, ...). 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.

Bill Cycle controls when a bill is produced for an account. This field is updated behind the scenes every time a service agreement with a service point is activated. The route the system takes to do this update is as follows:

- It looks for all service points linked to the service agreement.

- It extracts the service cycle from one of the service points.

- Finally, it takes the bill cycle from the service cycle.

While this is a little complicated, it makes sense because it keeps the bill cycle in sync with the service cycle.

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

Mailing Premise ID defines the address on bills for persons who have their bill sent to the account's mailing premise. This field may be updated behind the scenes when a service agreement is activated. The word "may" is used because the system will only update an account's mailing premise if there are no active service agreements currently linked to the account. Refer to Account - Person Information for more information about how to define where a person has their correspondence and bills sent.

If you do not want the mailing premise to change when a service agreement is activated, turn on Protect Mailing Premise.

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

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

The balances shown in the scroll are the total amounts of debt belonging to every debt class linked to the account's service agreements. The following information is displayed:

- Debt Class is the debt class associated with the account's service agreement(s).

- Current Balance is the amount of debt the customer currently owes.

- Payoff Balance is the amount the customer would owe if they wanted to pay off their debt.

To see summary information about the service agreements that contribute to the financial totals click the go to button adjacent to the respective amount.

Warning:

If you do not understand the difference between payoff balance and current balance, refer to Current Amount versus Payoff Amount.

Account - Auto Pay

The Auto Pay page is used when an account pays their bills automatically (e.g., by direct debit or credit card).

Fastpath:

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

Open Customer Information, Account and navigate to the Auto Pay tab to maintain this information.

Description of Page

The Account Auto Pay scroll defines the bank account / credit card from which the customer's automatic payments are debited. Multiple auto-pay options may exist if the customer 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 customer 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 customer 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 customer'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 customer 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 customer 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, customers 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 customers and non-customers (e.g. the accounting service that handles the bills of a commercial customer) can be linked to an account.

When you add an account from Person - Main or from Order - Main the system automatically links the person to the account, so you typically won't have to open this page. However, if you need to link multiple persons to an account (e.g., because you need to send a duplicate of the account's bill to someone other than the main customer) or change information about a person on an account, open Customer Information, Account and navigate to the Persons tab.

Description of Page

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

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

Main Customer Turn on this switch if the person is the main customer on the account. Only one person on an account may be designated as the main customer.

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

Financially Responsible Turn on this switch if the person is financially responsible for the account's debt.

This switch is on and gray if the person is the Main Customer because the main customer 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 Turn on this switch if the person is a 3 rd party guarantor of the account's debt. This switch is off and gray if the person is the Main Customer.

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

Note:

Default note. When the system links the person to the account when you add an account from Person - Main, it defaults the relationship type from the Installation Record.

Note:

Default note. This flag is defaulted to Allowed .

Prefix/Suffix and Pfx/Sfx Name Use these fields if you need to append additional information to a customer's name when correspondence or bills are 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 customer's name.

Receives Copy of Bill Turn on this switch 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 Main Customer because the main customer always receives a copy of the bill.

Fastpath:

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 Indicate how the bill is sent to the customer. 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 Indicate if the customer 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 Indicate how many copies of the bill the person receives.

Customer PO ID Indicate the purchase order ID the customer wants printed on their copy of the bill.

Note:

Note. Receives Copy of Quote and Quote Route Type only appear if the quotation Contract Management module is not turned off.

Receives Copy of Quote Turn on this switch if the person receives a copy of the account's quotes. Turning off this switch grays the remaining fields. This switch is on and gray if the person is the Main Customer because the main customer always receives a copy of the account's quotes.

Fastpath:

Refer to Printing Quotes for more information about how the remaining information is used to format the address of a quote.

Quote Route Type Indicate how the quote is sent to the customer. This field's value defaults from the Installation Record. If the Quote Route Type you select indicates that quotes 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 Quote Route Type you select indicates that quotes are routed via Email, the person's Email address is displayed adjacent. If the Quote Route Type you select indicates that quotes are routed via the Postal service, you must choose an appropriate Address Source to define which address should be used. Refer to Setting Up Quote Route Types for more information about quote route types.

Receives Notification Turn on this switch if the person receives letters (i.e., notifications) initiated by collection, severance, write-off, overdue and cut events. These events will send letters to the main customer and any other person linked to the account that Receives Notifications. This switch is on and gray if the person is the Main Customer because the main customer always receives notifications. Refer to Printing Letters for more information about how letters are produced by the system.

Address Source If the Bill Route Type or the Quote Route Type you selected indicates that bills / quotes are routed via the postal service, you must choose the appropriate Address Source.

Choose Mailing Premise on Account if bills / quotes should be sent to the address associated with the Mailing Premise on the first page. This address is displayed adjacent.

Choose Person if bills / quotes should be sent to the person's mailing address. This address is displayed adjacent.

Choose Account Override if bills / quotes 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 bills / quotes 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 If you selected an Address Source of Account Override , you must enter the address to which bills / quotes will be sent in the address constituents. 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.

The Validate button on the account page will only be available if you have set the Allow Address Validation option type to Y on the General System Configuration feature configuration. Once clicked, the Address Validation Script on the General System Configuration feature configuration will be invoked to validate the entered address. Refer to unresolvable-reference.html for more information.

Account - Financial Balances

The financial balances page is an information-only page that subdivides an account's debt by debt class. The balances shown on this page are the total amounts of debt belonging to every debt class linked to the account's service agreements.

Note:

The source of debt class. An account's debt comes from its service agreement(s). Every service agreement has an SA type. Every SA type references a debt class.

Open Customer Information, Account and navigate to the Financial Balances.

Description of Page

The account's Current Balance displays at the top of the page.

The Debt Class Balances scroll contains one entry for every debt class linked to the accounts non-closed / non-cancelled service agreements. The following information is displayed for each debt class.

- Debt Class is the debt class associated with the account's service agreement(s). To see summary information about the service agreements that contribute to the debt class totals click the adjacent Go To button.

- Current Balance is the amount of debt the customer currently owes.

- Payoff Balance is the amount the customer would owe if they wanted to pay off their debt. Payoff balance is only displayed if it differs from current balance.

Warning:

If you do not understand the difference between payoff balance and current balance, refer to Current Amount versus Payoff Amount.

- The Debt Class Arrears shows the age of all amounts that make up the current balance.

- The Days Old and Amount information shows the age of the debt class's debt.

Note:

Information about debt balances by age is not applicable to open-item accounts.

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 Customer Information, Account and navigate to the Bill Messages tab to access this page.

Description of Page

The following fields are displayed:

Bill Message The message code and description of the message that appears on the customer'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 - C&C

The Credit Rating page contains the credit rating transactions that impact an account's credit rating and cash-only score. To view or modify these transactions, open Customer Information, Account and navigate to the C&C (credit and collections) tab.

Description of Page

Collection Class controls how the account's debt is compared against collection criteria to determine if a collection process should be started. Refer to The Big Picture of Credit & Collections for more information about how and when an account's debt is reviewed.

Note:

Default note. The Collection Class defaults from the account's customer class when the account is first added. It may be overridden at will.

If you need to prevent an account from being reviewed by credit and collections processes (i.e., the account debt monitor and the write-off monitor), use Postpone Credit Review Until to define the future date when these processes can again review the account's debt.

Last Credit Review Date is the date when the account's debt was last reviewed by the account debt monitor (ADM).

Note:

Forced ADM review. If you want the ADM to review an account's debt the next time it runs, simply change the Credit Review Date to a date in the distant past (e.g., 1/1/1900). The next time the ADM2 background process runs, it'll see that a great deal of time has past since the last time it reviewed the account's debt and review it (and then set the Credit Review Date accordingly).

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

The account's Current Cash Only Score is displayed. For an explanation of how this number is derived, see How is an account's cash-only score calculated?.

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

Start Date This is the first date the credit rating transaction affects the account's credit rating and cash-only score.

End Date This is the last date the credit rating transaction affects the account's credit rating and cash-only score.

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

Affect Credit Rating By This is the effect of the credit rating transaction on the account's credit score. This should be a negative number because the lower the score the worse the credit rating.

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

Affect Cash-Only Score By This is the effect of the credit rating transaction on the account's cash-only score. The higher the score, the greater the chance this account will be marked as cash-only. Therefore, a positive number should be used to make the score go up.

An account's cash-only score is equal to the start cash-only score defined on the installation record plus the sum of cash-only points that are currently in effect. When an account's cash-only score exceeds the cash-only threshold score defined on the installation record, the account is flagged as cash-only in the Alert Zone and on the payment event page.

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

Contents

How are credit rating transactions created?

How is credit rating calculated?

What impact does credit rating have in the system?

How is cash-only score calculated?

What impact does cash-only score have in the system?

How are credit rating transactions created?

Credit rating transactions may be created as follows:

- Certain types of collection events add credit rating transactions. The number of credit rating and cash-only points is defined on the collection event type.

- Certain types of severance events add credit rating transactions. The number of credit rating and cash-only points is defined on the severance event type.

- Certain types of write-off events add credit rating transactions. The number of credit rating and cash-only points is defined on the write-off event type.

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

- You may configure your system to create a credit rating transaction when a pay plan is broken. To do this, you must plug in an appropriate Broken Algorithm on the pay plan type.

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

- Algorithms may add credit rating transactions. The system provides sample overdue event and cut event activation algorithms that add credit rating transactions. Refer to C1-OE-CR-RT and C1-CE-CR-RT for more information. Some examples of algorithms your implementation may decide to introduce: the creation of a late payment charge. To do this you could introduce a new adjustment freeze algorithm.

Note:

Created By Flag. The credit 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 credit 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 credit rating calculated?

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

What impact does credit rating have in the system?

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

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

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

Fastpath:

For more information, refer to Designing Your Collection Class Control Overrides.

How is cash-only score calculated?

An account's cash-only score is calculated by summing the Affect on Cash-Only Score from credit rating transactions effective on the current date. This value is added to the beginning cash-only score defined on the installation record. The result is the customer's current cash-only score.

What impact does cash-only score have in the system?

If an account's current cash-only score exceeds the cash-only threshold on the installation record, and the base package's C1-CASH-ACCT algorithm is enabled on the installation record:

- The customer is flagged as cash-only in the Control Central Alert area.

- If a user attempts to add a payment whose tender type is a cash-equivalent, a warning is issued.

Account - Budget

The Budget page contains information about all service agreements linked to an account that are eligible to participate in a budget billing plan. Refer to Budget Billing for more informationabout how this information affects the account's bills.

Note:

You are actually changing service agreements. When you change a service agreement's budget amount on this page, you are actually changing the service agreement's recurring charge amount. Refer to Service Agreement - Recurring Charge for more information.

Eligible service agreements. It's important to be aware that some service agreements linked to an account may not be eligible for budget plans. For example, assume you have a customer with a deposit service agreement and one or more utility service agreements. This customer will be billed for their deposit regardless of the utility service agreements' budget amounts. You define whether a service agreement may participate in a budget plan on the service agreement's SA type.

Open Customer Information, Account and navigate to the Budget tab to view this information.

Description of Page

The appearance and dialogue of this page differs slightly for an account with a small number of service agreements (100 or less) versus a large number of service agreements (more than 100).

- For an account with a small number of service agreements, the user may click the Recommend Budget button to generate a New Budget for each service agreement. At that point the service agreement's budget amount has not been updated. The user may review the calculated amounts; make desired changes and then click Save to update the budget amount for the service agreements.

Warning:

You must save the page in order for the budget changes to take affect.

- For an account with a large number of service agreements, the user may click the Calculate and Apply New Budget button. At that point the system will calculate the recommended budget and update the Budget Amount on all the eligible service agreements. To change the budget amount for one or more of the service agreements, the user navigates to the service agreement page using the drill down button adjacent to the service agreement in question.

Click Cancel Budget to have the system set the New Budget amount to zero for all the account's service agreements on budget.

Note:

Budget Recommendation. Though this page lists all SAs eligible for a budget, the budget recommendation only calculates a budget amount for SAs whose start and end date (if any) includes the budget date. Additionally, the budget date is used to select the rate schedule that is in effect for an SA if estimating consumption is necessary.

Budget Plan controls how the account's debt is managed for budget-related purposes. Specifically, it controls how the recommended budget amount is calculated and how / when the customer's budget is periodically changed.

Note:

Default note. Budget plan defaults based on the account's customer class / division combination.

Use New Budget Date to define the effective date of any changes to the customer's budget amount (this date is the effective date on the respective service agreements' recurring charge history).

The system displays the sum of the service agreements' current budget amounts in Total Budget Amount.

For accounts with a small number of service agreements, the system displays the sum of the service agreements' new budget amounts in Total New Budget.

The grid that follows contains a row for each service agreement linked to the account that is eligible to participate in a budget billing plan:

SA Information This is a concatenation of basic information about the service agreement.

Last Changed Date This is the date when the service agreement's budget amount (i.e., recurring charge amount) was last changed.

Budget Amount This is the existing budget amount (i.e., recurring charge amount) for the service agreement.

New Budget For accounts with a small number of service agreements, the service agreement's budget amount (i.e., recurring charge amount) will be changed to reflect this value when the page is changed. The effective date of the change is defined in New Budget Date.

Account - Deposits

The Deposits page contains information about all cash and non-cash deposits linked to an account.

Note:

Cash versus Non-cash Deposits. Non-cash deposits (e.g., letters of credit, surety bonds, 3 rd party deposits) can be added and maintained on this page. Cash deposits are maintained using service agreements. Refer to Cash Deposits for information about how to add and maintain cash deposits.

Open Customer Information, Account and navigate to the Deposits tab to view this information.

Description of Page

The following fields appear in the Deposit Summary:

Cash Deposits On Hand The total amount of cash deposits currently held for the account. This value is equal to the sum of the payoff balances from all service agreements whose SA type has a special role of Cash Deposit . Refer to Cash Deposits for information about how to add and maintain cash deposits.

Cash Deposits Requested This value is equal to the sum of Total Amount to Bill from all service agreements whose SA type has a special role of Cash Deposit . Refer to Cash Deposits for information about how to add and maintain cash deposits.

Non-Cash Deposits The total amount of active non-cash deposits currently held for the account. This value is equal to the sum of non-cash deposits displayed in the scroll below (note, non-cash deposits can be maintained in the same scroll).

Total Deposits on Hand This is the sum of cash and non-cash deposits held for the account.

Turn on Do Not Review or Refund if this account should not be considered by the Deposit Review background process (this process highlights customers who require an additional deposit) or by the Deposit Refund background process. Refer to The Big Picture Of Deposits for more information about these processes.

The Non-Cash Deposit scroll contains an entry for every non-cash deposit linked to the account. Refer to Non Cash Deposits for more information.

To modify a non-cash deposit, simply move to a field and change its value. To add a new non-cash deposit, click the + button and then fill in the information for each field.

Start Date This is the date the non-cash deposit is effective.

End Date This is the expiration date of the non-cash deposit.

Non Cash Deposit Type Select the appropriate non-cash deposit type. The value selected is important as it controls whether the system requires a Third Party Deposit and whether the system will create a To Do entry near the expiration date of the deposit. Refer to Setting Up Non-Cash Deposit Types for more information.

Deposit Class Select the deposit class in which this non-cash deposit should be included. This value is used when the system amalgamates an account's total deposits when checking if the account holds an adequate deposit (amalgamation and recommendation happens within a deposit class). Refer to Deposit Class Controls Everything for more information about the significance of deposit class.

Deposit Amount Indicate the amount of the non-cash deposit.

Document Number Enter the document number, if any, associated with the non-cash deposit (e.g., the letter of credit number, the surety bond number, etc.).

Third Party Deposit SA If a 3 rd party has paid the cash deposit for the account, reference the deposit SA associated with the 3rd party. Refer to 3rd Party Deposits for more information about how 3 rd party deposits are maintained in the system.

Comments Enter any free-form comments about the non-cash deposit.

Account - Characteristics

The characteristics page contains information that describes miscellaneous information about the account. Use Customer Information, Account 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 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 Customer Information, Account and navigate to the Alerts tab 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 customer service representative 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 on Control Central.

Start Date Indicate the date on which the alert starts showing in Control Central. The current date defaults.

End Date Indicate the date on which the alert stops showing in Control Central. 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.

Account - Account Portal

Select Main Menu > Customer Information > Account and navigate to the Account Portal tab to view additional information associated with a Account.

General Information

Account ID, Account Info are displayed.

Depending on your implementations requirements, you may define additional zones to appear on this Portals

Refer to The Big Picture of Portals and Zones in the Oracle Utilities Application Framework Administration Guide for a description of portal and zone functionality.

Account Management Portal

The Account Management portal is used to maintain multiple accounts linked to a particular customer.

Open this page using Customer Information, Account Management.

Some examples of customers with large numbers of accounts include:

- Public school districts with many school locations

- Corporate entities with many franchise locations

- Large apartment complexes with many open units

- Service providers billed for many end customers

- Cities, counties, or townships (for street lights, sewer service, etc.)

You can select one or more accounts to update, or you can broadcast an account’s service agreements for group SA maintenance. Update actions can be performed on either accounts or SAs. The following items are examples of the account information that can be updated:

- Mailing address

- Characteristics

- Autopay information

- Bill cycle

- Account management group

The following items are examples of the service agreement information that can be updated:

- Rate schedules

- Contract riders and contract values

- Tax exemptions

- Characteristics

When you update information, you can select an account or SA to use as a template, and use this as a basis for updating multiple accounts. The system will copy information from the template to the selected accounts or service agreements. Refer to the embedded help on the Update Details page for more information about using a template to update accounts.

Description of Page

Use the Account Search zone to search for a person. The Person ID is required. Include Hierarchy determines whether you wish to search for accounts directly linked to the person id specified, or if you want to find all accounts in the hierarchy using person to person relationships. You can also enter one or more of the following values to further restrict the list of accounts returned: Customer Class, Account Management Group, Bill Cycle or Characteristic Type/Value.

Once a person is selected, you can view and maintain the accounts and the service agreements associate with the person. Click the broadcast icon next to an account to view SAs for the account. The Service Agreement List zone includes a summary listing of the non-closed, non-canceled service agreements of the broadcast account.

Select one or more accounts and click Update Accounts to modify account information. Select one or more service agreements and click Update Service Agreements to modify service agreement information. Refer to the embedded help on the Update Details page for descriptions of the values that can be updated.

The Person Tree zone, similar to that of Control Central, shows the hierarchy of child persons for the person that has been broadcast.

Account - SAs For A Debt Class

This is an information-only page that shows an account's service agreements grouped by debt class.

Note:

The source of debt class. An account's debt comes from its service agreement(s). Every service agreement has an SA type. Every SA type references a debt class.

To access this page, drill down on a debt class shown on Customer Information, Account, Main.

Description of Page

The Account ID and the primary name of the account's main customer are displayed.

Debt Class is the debt class associated with the account's service agreement(s).

Note:

An account may have service agreements that belong to other debt classes. Navigate to Account - Main Information to see a list of all debt classes associated with an account.

The Service Agreement scroll contains one entry for each service agreement that belongs to the Debt Class. The following information is displayed for each service agreement.

- SA (service agreement) Info is a concatenation of important details about the service agreement.

- Premise defines the service agreement's main premise.

- Current Balance is the amount of debt the customer currently owes.

- Payoff Balance is the amount the customer would owe if they wanted to pay off their debt. Payoff balance is only displayed if it differs from current balance.

Warning:

If you do not understand the difference between payoff balance and current balance, refer to Current Amount versus Payoff Amount.

- SA Arrears displays the age of the amounts that make up the current balance.

- The Days Old and Arrears Amount information shows the age of the service agreement's debt.

Note:

Information about debt balances by age is not applicable to open-item accounts.

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 3 rd party agencies who enroll customers on its behalf. In this situation, the 3 rd party agency may receive blocks of pre-allocated account numbers to be used when they enroll a customer. When a customer signs up, the person information can be updated with information about the newly enrolled customer.

- 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 customer 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 customer 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 Customer Information, Account/Person Replicator to open this page.

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.

Contents

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.

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 customer, 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:

- Mailing premise will be set to blank

- Setup Date is set to the current date

- Credit Review Date and Postpone Credit Review Until Date will be set to blank

- Auto Pay information will not be copied

- Credit Rating History will not be copied

- Non-cash deposit information will not be copied

Note:

that all miscellaneous persons linked to the account (i.e., those who are not flagged as Main Customers) 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 Service Agreements

A service agreement contains the terms and conditions controlling how the system calculates charges for a specific service supplied to a customer. The topics in this section describe the pages on which service agreement related information is maintained.

Note:

The system creates most service agreements behind the scenes. Most service agreements are created "behind the scenes" by the system as part of the Start Service and Order completion processes. You should only have to access the service agreement pages if you need to fine-tune what the system defaults. Refer to Start / Stop and Maintaining Orders for the details.

Fastpath:

For more information about service agreements and their place in the "V", refer to Understanding The "V". For more information about the source of information defaulted onto service agreements, refer to Setting Up Start Options.

Warning:

Take special care when adding a new service agreement to specify the appropriate Division and SA Type as it will affect how the customer is billed, what rate can be specified, how overdue debt is collected, and much more. After the service agreement is activated, you may not change its SA type.

Contents

The Lifecycle Of A Service Agreement

Service Agreement - Main Information

Service Agreement - Rate Info

Service Agreement - SA / SP

Service Agreement - Chars, Qty & Rec. Charges

Service Agreement - Miscellaneous

Service Agreement - Contract Options

Service Agreement - Interval Info

Service Agreement - TOU Contract Values

Service Agreement - Billing Scenarios

Service Agreement - SA Portal

Service Agreement - SA Portal

The Lifecycle Of A Service Agreement

The following diagram shows the possible lifecycle of a service agreement.

Pending Start When you initiate a request to start service, the system initiates a service agreement in the state of Pending Start . A pending start service agreement remains in this state until everything necessary to start service is defined in the system.

Active The system automatically changes the state of Pending Start service agreements to Active when everything necessary to start service exists in the system. Refer to Activating Pending Starts for more information. While in this state, the system bills the service agreement's account for the service.

Pending Stop When you initiate a request to stop service, the system progresses the service agreement to the Pending Stop state. A pending stop service agreement remains in this state until everything necessary to stop service is defined in the system.

Stopped The system automatically changes the state of Pending Stop service agreements to Stopped when everything necessary to stop service exists in the system. Refer to Finalizing Pending Stops for more information. The service agreement remains in this state until it is paid in full.

A service agreement can be automatically stopped depending on the SA Type configuration of the Stop Option Flag. Service agreements configured to automatically stop will be stopped when all SP related SAs of the account are stopped. For example, if an account has a cable service and a charitable contribution service agreement then the charitable contribution service agreement can be configured to automatically stop when the cable service agreement is stopped. The stop date of the charitable contribution will be set equal to the stop date of the electric SA.

Closed The system moves a service agreement to the Closed state when it no longer has a financial balance.

Reactivated The system moves a service agreement to the Reactivated state if a financial transaction is created after a service agreement is Closed (e.g., when a payment is canceled after the service agreement is closed). Please be aware that Reactivated service agreements are processed by the Write Off Monitor.

When the service agreement once again has a zero balance (e.g., because the customer pays or the debt is written off), the service agreement returns to the Closed state.

Cancelled You may Cancel a service agreement if it shouldn't exist (because the customer doesn't want service). While cancellation doesn't physically remove a service agreement from the database, most queries and trees suppress information about canceled service agreements. This means cancellation is a nice way to logically delete undesired service agreements.

You'll notice in the above diagram that you can cancel an Active, Pending Stop or Stopped service agreement. You may only do this if the service agreement's financial transactions and non-billed billable charges are all cancelled.

You should rarely have to change a service agreement's status. Why? Because the system changes the status behind-the-scenes when various events take place. For example,

- When you request a service start using the Start/Stop page, the system creates a service agreement in the pending start state.

- If you cancel a pending start before service is activated, the system automatically changes the state of the service agreement to cancelled .

- When everything necessary to start service exists, the system automatically changes the state of the service agreement to active .

- When you request a service stop using the Start/Stop page, the system changes the state of the stopped service agreement to pending stop state.

- When everything necessary to stop service exists, the system automatically changes the state of the service agreement to stopped .

- When a final payment is received and the stopped service agreement's balance becomes zero, the system automatically changes the state of the service agreement to closed . The system can also close a service agreement as part of the write-off processing.

- If the payment bounces, the system automatically changes the state of the service agreement to reactivated . And the system will change it back to closed when the account's balance returns to zero.

- If a billable charge is interfaced into the system, the system automatically changes the state of the service agreement to reactivated .

You may need to manually change a service agreement's state for the following reasons:

- If a service agreement was activated inadvertently, you may cancel it (and therefore logically remove it from the system) after canceling all of its financial transactions. You do this by clicking the cancel button on the service agreement page. You may also cancel an incorrect service agreement if the status transitions to pending stop or stopped before you have a chance to correct the mistake.

- If you don't want to wait for the system to automatically activate a pending start service agreement, you may push the activate button on the service agreement page. You might do this in order to create a bill for an impatient customer.

- If you don't want to wait for the system to automatically finalize a pending stop service agreement, you may push the stop button on the service agreement page. You might do this in order to create a real time final bill for a customer.

- If you don't want to wait for the system to automatically close a stopped service agreement, you may push the close button on the service agreement page.

- Sometimes a service agreement is closed or stopped by mistake. You can activate a stopped, closed, or reactivated service agreement using the Reinstate SA button on the service agreement page. Using the Reinstate SA button retains the current service's billing history.

Note:

One time invoices (i.e., one-time billable charges) are interesting. One-time invoice service agreements follow the above lifecycle; it's just that they do it quickly. You see, when a one-time invoice service agreement is created, both its start and stop dates are known (they are the invoice date). If you followed the above state transition discussion, you'll understand that the system progresses these invoices from pending start to stopped when the service agreement is activated.

Contents

Renewing Service Agreements

Expiring Service Agreements

Renewing Service Agreements

Some service agreement types (e.g., non-billed budgets) may allow or require renewal. If renewal is optional, a renewal date may be specified when the service agreement is created. If renewal is required, you must specify a renewal date.

The SA renewal background process initiates the renewal for all active service agreements when the renewal date is reached (i.e., the renewal date is on or before the process date). When a service agreement is renewed:

- The SA renewal algorithm (specified on the SA type) is executed. The SA renewal algorithm can be used to customize the processing required to renew an SA.

- If the SA renewal algorithm is successful, the renewal and expiration date (if calculated by the renewal algorithm) on the service agreement are updated with the values returned from the renewal algorithm.

- If the renewal process is not successful, a To Do list entry (of type TD-SARN ) is created for the account and service agreement.

Expiring Service Agreements

Service agreements may specify an expiration date. Some service agreement types (e.g., non-billed budgets) require an expiration date. The SA expiration background process initiates the request to stop service for all active SAs when the expiration date is reached (i.e. the expiration date is on or before the process date).

Service Agreement - Main Information

The Main page contains basic service agreement information. Open Customer Information, Service Agreement to maintain this information.

Description of Page

SA (service agreement) Info and SA ID are displayed on every page. These values only appear after the service agreement exists on the database. The ID is a system assigned random number that stays with a service agreement for life. The SA Info is a concatenation of important details about the service agreement and its account.

Note:

Formatting may be performed by a plug-in. The contents of SA Info may be formatted by a plug-in algorithm on SA Type. Refer to the base package's C1-SAT-INFO for an example. If such an algorithm is not plugged-in on the SA Type, the system looks for a corresponding algorithm on the installation record. Refer to the base package's C1-SAI-INFO for an example. If you prefer different formatting logic, your system administrator should configure the system appropriately.

SA Status defines the state of the service agreement. The system typically changes the state of a service agreement behind-the-scenes. If you can't wait for the system, use one of the adjacent buttons:

- Click the Activate SA button to activate a Pending Start service agreement.

- Click the Cancel SA button to cancel a Pending Start or Active , Pending Stop or Stopped service agreement.

- Click the Initiate Stop button to populate the End Date and change the state of the service agreement to Pending Stop .

- Click the Stop SA button to stop a Pending Stop service agreement.

- Click the Close SA button to close a Stopped or Reactivated service agreement.

- Click the Reinstate SA button to reinstate a Closed , Reactivated , or Stopped service agreement to an Active service agreement.

Fastpath:

Refer to The Lifecycle of a Service Agreement for more information about SA Status.

If the quotation module is not turned off, a "real" service agreement can be created when a proposal service agreement is accepted. If the service agreement you've displayed was created in such a way, information about the Proposal SA will appear beneath SA Status.

Enter the Account ID that is financially responsible for the service agreement. If you change a service agreement's Account ID, you are effectively transferring this service agreement (and its debt) to the new account.

Indicate the CIS Division and SA Type. These fields are very important as they control numerous aspects of the service agreement's behavior. These fields are gray when the status is not Pending Start .

Fastpath:

For more information about what the SA type controls, refer to Setting Up SA Types.

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 service agreement has not yet been terminated.

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. Refer to How To Correct A Bill Segment That's In Error for more information.

Note:

Default note. The value of Maximum Bill Threshold defaults from the service agreement's SA type.

If the SA Type has a special role of Interval , you must enter the Cutoff Time and Start Day Option that is used by interval pricing and derivation algorithms to determine the start and end intervals to process. Similarly, if the SA Type has a special role of Bill Determinants Required , you must enter the Cutoff Time and Start Day Option that is used on a bill determinants usage request. Refer to Start and End Times for Billing for more information about how these fields are used.

- The Cutoff Time is entered in "legal time". This value defaults from either the start option or the installation record. Refer to Bill Period and Seasonal Time Shifts for information describing how this field is used.

- For Start Day Option, you may choose Current Day or Previous Day . This value defaults from either the start option or the installation record.

Use Customer Read to define if the customer reads his or her own meter. Valid values are: Yes , No .

Turn on Allow Estimates if it's OK for the billing process to estimate this service agreement's consumption if a real meter read is missing at billing time. If the SA type does not allow estimates, this field will be gray.

Note:

Consumption estimation. Consumption is only estimated by billing if all of the following points are true:

a) A real read cannot be found;

b) The service agreement allows estimation;

c) The bill cycle schedule allows estimation (if the bill is produced by the BILLING background process);

d) The operator allows estimation (if the bill is produced as a result of an ad hoc request);

e) The rate schedule allows estimation;

If you've set up the system to use start options, you can have the system default many fields by copying the terms from a start option when service is started using either Start / Stop or the Order transaction. The Start Option field contains the last start option whose field values were copied to the service agreement. If you need to change a service agreement's terms by applying a different start option, you can. Refer to Changing A Start Option for a description of how to do this.

If the service agreement's rate uses premise-based characteristics for taxation and other purposes, Characteristic Premise ID defines the premise that supplies these characteristics. This field also defines the premise under which the service agreement's bill segments are classified and is used to identify where the service agreement's service is located on various windows. This field is gray if the service agreement's SA type doesn't require a characteristic premise. For more information about rates and their use of characteristics, refer to Setting Up Bill Factors .

Note:

Selecting a characteristic premise. If the service agreement has service points, only premises associated with these service points may be selected as a Char Premise. If the service agreement doesn't have service points, any premise may be selected.

Your conversion process will fill in Old Account ID for service agreements that were converted from your legacy CIS system. The payment upload process uses this field to locate the accounts for payments that reference a legacy account number.

If the service agreement requires a total amount to bill, the amount is displayed. This field is typically only used on loan or cash deposit service agreements. It holds either the loan amount or the desired cash deposit. If you increase this field's value, the customer will be billed for any difference between the new amount and the total amount billed (and paid for) to date. The label that appears for this field is defined on the SA type (on the Billing tab). We recommend that the system be set up so that this label is very specific, for example:

- It should be called Cash Deposit Amount if the total amount to bill is for a deposit.

- It should be called Loan Amount if the total amount to bill is for a loan.

Number of Payment Periods only appears for loan SA types. It displays the number of periods specified when the loan was first activated. (The number of payment periods may have been subsequently changed on Loan maintenance.)

If the service agreement uses a recurring charge, the current recurring charge amount is displayed. Transfer to the Service Agreement - Recurring Charge to update this value. This field is not visible if the service agreement's SA type doesn't allow recurring charges. The label that appears for this field is defined on the SA type (on the Billing tab). We recommend that the system be set up so that this label is very specific, for example:

- It should contain Budget Amount if the recurring charge is for a budget.

- It should contain Installment Amount if the recurring charge is used for a deposit being paid in installments.

- It should contain Payment Amount if the recurring charge is used for a loan.

SA Relationship ID contains the ID of the SA Relationship that is associated with a sub service agreement. This field is only visible on sub service agreements. Refer to Sub Service Agreements for more information.

CIAC Review Date displays the last date that the Contributions In Aid of Construction (CIAC) review process ran for this service agreement. This field is only visible if the SA type indicates this is a CIAC service agreement. Refer to CIAC Segmentation for more information on CIAC.

Deposit Interest Calculated contains the last date the system applied interest. This field is only visible if the SA type has a special role of Cash Deposit .

The Scheduled Payment Autopay flag determines if the non-billed budget 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 non-billed budget, this flag cannot be set. This field is only visible if the SA has a special role of Non-billed Budget .

The NBB Recommendation Rule displays the description of the non-billed budget recommendation rule used for this SA. This field is only visible if the SA has a special role of Non-billed Budget .

Expiration Date contains the date at which the service agreement is set to expire.

Renewal Date contains the date at which the service agreement is to be renewed. Renewal date is disabled if renewal is not allowed on the SA type.

Debt Class indicates the debt class into which the service agreement's current balance is categorized by credit and collections. A service agreement's debt class is defined on its SA type. Refer to Different Collection Criteria For Different Customers And Different Debt for more information about debt class.

Current Balance indicates the amount the customer currently owes for the service.

Payoff Balance indicates the amount the customer would owe if they wanted to close the service agreement. This value is only displayed when it differs from current balance.

Fastpath:

Refer to Current Amount versus Payoff Amount for more information.

The Days Old and Arrears Amount information shows how old the current balance is. This information will be blank if the current balance is a credit.

Note:

Information about debt balances by age is not applicable to open-item accounts.

This bottom of this page contains a tree that shows the various objects linked to the service agreement. 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.

Contents

Changing A Start Option

The Impact of Proposal Service Agreements

Changing A Start Option

If the service agreement is in the pending start state, you can use the Start/Stop - Pending SAs page to change the service agreement's SA type and/or start option.

If the service agreement is in the active or pending stop states and if the SA type uses start options, a button appears on Service Agreement - Main called Apply New Start Option. When clicked, the Apply New Start Option dialog box opens.

The fields in this dialog box allow you to define a Start Option whose terms should be copied to the service agreement as of a given effective date ( Apply Start Option on). Because most terms on a service agreement are effective-dated, it's important that you understand the following ramifications of applying a start option (note, we use the word "terms" to generically reference any of the fields that can be defaulted from a start option):

- Terms are reused if Start Option contains the same value as defined in the service agreement. For example,

- If the Start Option references the same rate as defined in the service agreement, a new rate record will NOT be created.

- If the Start Option references a contract rider that's currently defined in the service agreement, a new rider will NOT be created.

- Terms that support explicit expiration (i.e., those with an end date) are expired if they are not referenced on the new start option. For example, if the service agreement has a rider that is not referenced on the new start option, it will be expired.

Note:

Interval profiles and TOU maps are expired using the Start Day Option and Cutoff Time in the new start option and not the existing values for the SA.

- Terms that support implicit expiration (i.e., those without an end date) are left unchanged if they are not referenced on the new start option. For example, a service agreement characteristic that isn't referenced on the new start option will NOT be modified when a new start option is applied.

Note:

Only start options related to the service agreement's SA type can be used. It should be noted that only start options related to the service agreement's SA type can be specified. If the service agreement is in the pending start state, you can change the service agreement's SA type on the Main tab or via Start/Stop - Pending SAs. If the service agreement is active , you may not change its SA type.

When you click OK a warning window will appear that summarizes the changes that will be made to the service agreement. After confirming what will be changed, click OK to change the service agreement's terms. The Start Option that is shown on the Main tab will now reflect the start option whose terms were just applied.

The Impact of Proposal Service Agreements

If the quotation module is not turned off, you may display a proposal service agreement on Service Agreement - Main. This section describes how Service Agreement - Main differs when a proposal service agreement is displayed.

The SA Status section is replaced with a section that shows the status of the proposal service agreement (proposal SA).

Proposal SA Status defines the state of the proposal service agreement. The Quote Maintenance transaction typically changes the status of a proposal SA when users accept, decline and cancel quote details. If you wish to change the status of a proposal SA independent of this transaction, you can press one of the adjacent buttons

- Click the Activate button to change the status from Pending to Quotable . Note, you can set up the system to automatically make newly created proposal SAs quotable by plugging in the appropriate Proposal SA Creation algorithm on the SA's SA type.

- Click the Accept button to change the status from Quotable to Accepted . When you accept a proposal SA, you will be asked to supply the Start Date of the real service agreement that will be created.

- Click the Decline button to change the status from Quotable to Declined . When you decline a proposal SA, you will be asked to supply a Decline Reason.

- Click the Cancel button to change the status from Quotable to Canceled .

- Click the Reactivate button to return a Canceled or Declined proposal SA to the Quotable state.

Fastpath:

Refer to Proposal SA State Transition for more information about Proposal SA Status.

If the proposal SA has been declined, the Decline Reason appears beneath Proposal SA Status. Refer to Accepting / Declining Quote Details for more information.

It the proposal SA was changed after a quote detail was generated using the proposal SA's terms, a Remark appears beneath Proposal SA Status highlighting such.

Note:

Changing A Start Option. You can Apply A New Start Option on pending and quotable proposal SAs.

If a real service agreement was created when the proposal SA was accepted, Real SA ID appears and contains the ID of the real service agreement. Refer to Accepting / Declining Quote Details for more information.

Service Agreement - Rate Info

The rate info page contains the service agreement's rate and information needed by the rate to calculate the service agreement's bill segments. This information is only displayed if the service agreement's SA type allows a rate.

Open Customer Information, Service Agreement and navigate to the Rate Info tab to access this page.

Description of Page

The Rate grid controls the rate used to calculate the service agreement's bill segments. Multiple rows will only exist if the service agreement's Rate changes over time.

A service agreement's Rate is populated by the system when service is started. The method used to populate the initial Rate depends on how service is started and whether you use start options:

- If the service agreement's SA type uses start options:

- If the Order transaction is used to start service, the rate is populated using the start option associated with the package that was selected by the user when the order was completed.

- If Start / Stop is used to start service, the rate is populated using the start option selected by the user when service was initiated.

- If the service agreement's SA type does not use start options, the SA type's default rate is populated on the service agreement.

Billing selects a single rate from the Rate grid when it calculates a bill segment for the service agreement. If multiple rates are defined in this grid, the rate is selected based on the service agreement's SA type's Rate Selection Date. The following fields display:

- Effective Date is the date the rate becomes effective. The service agreement's start date defaults.

- Rate Schedule defines the rate used to calculate the service agreement's bill segments. Note, you can only choose rates defined as permissible on the service agreement's SA type; the permissible rates are shown in the adjacent tree.

Note:

Possible override. If your service agreement is linked to a terms of service record, it is possible that the rate used by the system could get overridden by one referenced on the terms of service. If the rate is overridden by the TOS, the tree on this page indicates the rate source.

The Contract Rider grid contains the contract riders that are in effect for the service agreement. This information is defaulted when service is started using a start option (using the contract rider information defined on the start option). You should only have to access this section if you need to fine-tune what the system defaults.

Billing uses this information when it calculates a bill segment for the service agreement if:

- The rate used to calculate the bill segment contains a rate component that references a bill factor.

- The referenced bill factor requires a contract rider to levy the associated charge.

If a Contract Rider does not exist or is not effective, the charge associated with the rate component is not applied to the customer's bill.

To modify a contract rider linked to the service agreement, simply move to a field and change its value. To remove a contract rider, click the - button. To add a new contract rider, click the + button and fill in the information for each field. The following fields display:

- Use Start Date to define the date on which the contract rider becomes effective. The service agreement's start date defaults.

- Use End Date to define the date on which the contract rider expires. This field need only be specified if the contract rider expires on an explicit date.

- Use Bill Factor to define the type of rider. You may only reference Bill Factors designated as being applicable for contract riders. Note, the Bill Factors linked to the rate that are marked with contract rider applicability are shown in the adjacent tree under the Contract Rider node.

Fastpath:

For more information about contract riders, refer to Defining General Bill Factor Information .

The Contract Values grid contains the contract values that are in effect for the service agreement. This information is defaulted when service is started using the contract value information defined on the start option used to start service (if any). You should only have to access this page if you need to fine-tune what the system defaults.

Billing uses this information when it calculates a bill segment for the service agreement if:

- The rate used to calculate the bill segment contains a rate component that references a bill factor.

- The referenced bill factor uses a contract value to define the amount charged.

The following fields display:

- Use Start Date to define the date on which the contract value becomes effective. The service agreement's start date defaults.

- Use End Date to define the date on which the contract value expires. This field need only be specified if the value rider expires on an explicit date.

- Use Bill Factor to define the type of value. You may only reference Bill Factors designated as allowing values in contract terms. Note, the Bill Factors linked to the rate that are marked as allowing values in contract terms are shown in the adjacent tree under the Contract Value node.

- Use Value to define contract value.

Fastpath:

For more information about contract values, refer to Defining General Bill Factor Information .

The Tax Exemptions section contains the taxes from which the service agreement is all or partially exempt.

Billing uses this information when it calculates a bill segment for the service agreement if:

- The rate used to calculate the bill segment contains a rate component that references a bill factor.

- The referenced bill factor can have tax exemptions that limit the amount of the charge.

If the bill factor doesn't have a tax exemption or there are none that are effective during the bill period, the tax is levied in full. If the service agreement is exempt, the appropriate charge associated with the tax is calculated. We strongly recommend using the "%T" substitution character in the Description on Bill on tax-exemptible rate components so that an appropriate tax exemption message appears on the customer's bill.

Fastpath:

For more information about tax exemptions, refer to Defining General Bill Factor Information .

The following fields display:

- Use Start Date to define the date on which the tax exemption becomes effective.

- Use End Date to define the date on which the tax exemption expires.

- Use Bill Factor to define the tax from which the service agreement is exempt. You may only reference bill factors designated as being tax exemptible. Note, the Bill Factors linked to the rate that are marked as tax exemptible are shown in the adjacent tree under the Tax Exemption node.

- Use Percent Exempt to define the customer tax exemption percent (e.g., 90 means the customer is 90% exempt and will only pay 10% of the normal tax rate).

- Use Tax Exempt Type to specify the type of exemption.

- Use Tax Certification if the customer has a tax exemption certificate.

Rate Information Tree

The tree shows the service agreement's permissible rates and the related types of contract riders, contract values and tax exemptions that are possible given these rates.

- The Permissible Rates node displays all the rate schedules associated with the service agreement's SA Type.

- The Effective Rate Schedule node indicates the rate schedule currently effective.

- The Contract Rider node displays the bill factors linked to the service agreement's rate(s) that may have contract riders defined for them. If you expand a node, you can see the individual rate component(s) on which the bill factor is specified. If the service agreement has a value defined for the contract rider that is currently in effect, it is also shown.

- The Contract Value node displays all the bill factors linked to the service agreement's rate(s) that may have contract values defined for them. If you expand a node, you can see the individual rate component(s) on which the bill factor is specified. If the service agreement has a contract value defined that is currently in effect, it is also shown.

- The Tax Exemption node displays all the bill factors linked to the service agreement's rate(s) that may have tax exemptions defined for them. If you expand a node, you can see the individual rate component(s) on which the bill factor is specified. If the service agreement has a tax exemption defined for the bill factor that is currently in effect, it is also shown.

If the service agreement is currently linked to a terms of service record for an effective umbrella agreement, additional information is displayed in the tree.

- The Permissible Rates node displays the rate source value associated with the service agreement's SA Type.

- If the terms of service record linked to the service agreement has a template SA and the rate source is Check TOS First, then SA , the Effective Rate Schedule node displays the rate schedule for the template SA. An additional node indicating whether the rate source is the template SA or the current SA is displayed below.

- The Contract Rider, Contract Value and Tax Exemption nodes include the terms of service usage value from the bill factor.

Fastpath:

Refer to Rate Terms Overridden By Terms Of Service for more information.

Service Agreement - SA / SP

The SA / SP page contains the service points that are linked to the service agreement. This information is only displayed if the service agreement's SA type allows service points.

This information is updated by the system when service is started. You should only have to access this page if you need to fine-tune what the system defaults.

Warning:

You must understand the "V" very well before attempting to maintain this information. Refer to Understanding The "V" for more information.

Use Customer Information, Service Agreement and navigate to the SA/SP tab to open this page.

Description of Page

Billing uses SA / SP information to amalgamate consumption when it calculates a bill segment for the service agreement. The following fields are displayed:

Service Point ID The identity of the service point. The type and location of the service point is displayed adjacent. This field is gray after the service point is committed to the database.

Meter/Item Info The meter / item that is currently installed at the service point is displayed. Refer to Installing and Removing A Meter and Installing and Removing An Item for more information.

How to Use (SP) Indicates how billing uses the consumption associated with the service point. This field is gray for item-type service points. Valid values are: Add , Check , Subtract . Add service points have their consumption added to the total amount of consumption billed under a service agreement. Subtract service points have their consumption subtracted from the total amount of consumption billed under a service agreement. Check service points are ignored by billing.

Use Percent Indicates the percentage of this service point's consumption that is billed under the service agreement. This field is gray for item-type service points.

Start Date/Time The date and time the service point's consumption starts being billed under the service agreement. The service agreement's start date defaults. If the SA Type has a special role of Bill Determinants Required , the system sets this date based on the service agreement's start date, the service agreement's start day option and cutoff time, and the SA Type's initial start date option to reflect the earliest possible date/time that usage may be requested for the SA.

Start Meter Read The meter read that records the register values, as they appeared when the service point was linked to the service agreement. The meter reading's date and time are displayed adjacent. This field is disabled for item-type service points.

Note:

Only meter reads that have been marked as "Use on Bill" may be specified.

Stop Date/Time The date and time the service point's consumption stops being billed under the service agreement. If the SA Type has a special role of Bill Determinants Required , the system sets this date based on the service agreement's stop date and the service agreement's start day option and cutoff time to reflect the latest possible date/time that usage may be requested for the SA.

Stop Meter Read The meter read that records the register values as they appeared when the service point was unlinked from the service agreement. The meter reading's date and time are displayed adjacent. This field is disabled for item-type service points.

Note:

Only meter reads that have been marked as "Use on Bill" may be specified.

The Field Activity grid contains the list of field activities that have been generated in respect of this SA / SP. Refer to Field Activities to Start Service, Field Activities to Stop Service and The Big Picture Of Severance Events for more information.

Field Activity The unique ID of any field activity associated with starting, stopping, investigating, or severing the service at the service point.

Field Activity Type Indicates why the field activity is linked to the SA/SP. Valid values are Start Activity , Stop Activity , Severance Activity , or Service Activity .

The Characteristics grid contains characteristics that are only applicable for a given SA / SP combination. These are typically only used for obscure SA/SP relationships for which unusual pricing terms or interval billing options have been set up.

Note:

You can only choose characteristic types defined as permissible on the SA/SP 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 service agreement's start date defaults.

Characteristic Type Indicate the type of characteristic.

Characteristic Value Indicate the value of the characteristic.

Service Agreement - Chars, Qty & Rec. Charges

This page contains the Characteristics, Contract Quantities and Recurring Charges that are in effect for the service agreement.

Use Customer Information, Service Agreement and navigate to the Chars, Qty & Rec. Charges tab to open this page.

Description of Page

The Characteristics grid contains information that describes miscellaneous information about the service agreement. This information is defaulted when service is started using the characteristics defined on the start option used to start service (if any). You should only have to access this section if you need to fine-tune what the system defaults.

Note:

You can only choose characteristic types defined as permissible on the service agreement 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 service agreement's start date defaults.

Characteristic Type Indicate the type of characteristic.

Characteristic Value Indicate the value of the characteristic.

The Contract Quantity grid contains the contract quantities that are in effect for the service agreement. This information is defaulted when service is started using the contract quantities defined on the start option used to start service (if any). You should only have to access this section if you need to fine-tune what the system defaults.

Billing may use this information when it calculates a bill segment for the service agreement if the rate has SQ (service quantity) rules or register rules. Refer to Defining Measured Quantity Manipulation Rules for more information.

The following fields display:

Effective Date The date this quantity becomes effective. The service agreement's start date defaults.

Contract Quantity Type The type of contract quantity.

Contract Quantity The contract quantity.

The Recurring Charge section contains effective-dated information that defines the recurring charge amount used to calculate the service agreement's bill segments. This information is only displayed if the service agreement's SA type allows a recurring charge amount.

A service agreement's recurring charge amount history is updated by the system behind-the-scenes as part of the Start Service process. The budget recalculation process can also update this information. You should only have to access this section if you need to change a service agreement's recurring charge amount on some future date.

Billing uses recurring charge information to select the appropriate recurring charge when it calculates a bill segment for the service agreement. To modify a recurring charge, simply move to a field and change its value. To change the recurring charge amount effective on a given date, click the + button to insert a row, then fill in the information for each field. The following fields display:

Effective Date The date the charge becomes effective. The service agreement's start date defaults.

Note:

Recurring charge changes during a bill period. Only one recurring charge will be used on any bill segment. The system selects the recurring charge value effective on the end date of the bill segment.

Recurring Charge Amount The recurring charge amount.

Service Agreement - Miscellaneous

The miscellaneous page contains information that describes miscellaneous information about the service agreement. Use Customer Information, Service Agreement, Misc to open this page.

Description of Page

Start Requested By displays the information entered in the Requested By field on the Start Stop page when this SA was started.

Stop Requested By displays the information entered in the Requested By field on the Start Stop page when this SA was stopped.

Select the SIC Code associated with the customer. This is typically only used for commercial and industrial customers.

Enter a Business Activity associated with the customer. This can be used to further define what types of activities are served by this contract.

The bill message grid contains information about the message(s) to appear on a service agreement'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 customer'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.

The terms and conditions (T&C) grid contains the service agreement's T&C's. This information is defaulted when service is started using a start option (using the T&C information defined on the start option). You should only need to change this information if you need to fine-tune the defaults. Refer to Legal Terms and Conditions May Be Specified on Service Agreements for more information. The following fields display:

- Use Start Date to define the date on which the T&C becomes effective. The service agreement's start date defaults.

- Use End Date to define the date on which the T&C expires. This field need only be specified if the T&C expires on an explicit date.

- Use Terms and Conditions to define the type of T&C.

Service Agreement - Contract Options

The contract options page contains the contract options and contract option events for interval billing service agreements. Refer to Contract Option Background Topics for more information.

Note:

This tab may not appear. This tab is suppressed if the interval billing Complex Billing module is turned off.

Open this page using Customer Information, Service Agreement and then navigate to the Contract Options tab.

Description of Page

The Contract Option collection contains effective-dated information that defines the contract options linked to the service agreement. The following information may be defined for each contract option:

Contract Option Id This is the id of the contract option to link to the service agreement. The SA Contract Option ID is displayed adjacent. This is the unique identifier of the SA / contract option record.

Effective Date/Time This is the date and time that the contract option is in effect for the service agreement.

Expiration Date/Time This is the date and time that the contract option is no longer in effect for the service agreement.

The Override Events Collection contains information about the override events for a shared contract option. Refer to SA May Override a Shared Event for more information.

If a contract option event for a shared contract option should not be applicable to this service agreement, enter the Contract Option Event ID, the Override Date/Time that the override is effective and the Status. The status value of Active means that the override is in effect. The status value of Inactive 'cancels' the override, meaning that the event is applicable to this service agreement.

If seasonal time shift records are linked to both the base time zone and to the time zone on the service agreement's characteristic premise, the Seasonal Time Shift associated with the time zone on the characteristic premise is displayed. Refer to Time Zone and Time Changes for more information.

The Seasonal Time Shift Remark indicates whether the data is displayed and should be entered in legal time or standard time. Refer to Interval Time Display for more information. If the data is displayed in legal time use the Show in Standard button to toggle to standard time. If the data is displayed in standard time use the Show in Legal button to toggle to legal time.

Service Agreement - Interval Info

The interval info page contains various collections needed by an interval service agreement. This information may be used by validation and derivation algorithms or may be used by interval and time of use pricing algorithms. Refer to Interval Billing for more information.

Note:

This tab may not appear. This tab is suppressed if the interval billing Complex Billing module is turned off.

Open this page using Customer Information, Service Agreement and then navigate to the Interval Info tab.

Description of Page

The tree at the bottom of this page shows information about interval profiles and TOU maps that are referenced in the rate components linked to one of the service agreement's rates.

- A node will display for each Interval Profile Relationship Type, which is priced directly, i.e., it is referenced on a rate component with an RC Type of Interval Pricing . When this node is expanded, information about every Interval Pricing rate component, which references this relationship type is displayed.

- A node will display for each TOU Map Relationship Type and Interval Profile Relationship Type, which are referenced on a rate component with an RC Type of TOU Pricing . When this node is expanded, information about every TOU Pricing rate component, which references these relationship type is displayed.

- A node will display for each Interval Profile Relationship Type, which is referenced on a rate component with a generic RC Type of Calculation Algorithm . When this node is expanded, information about every Calculation Algorithm rate component, which references this relationship type is displayed.

- A node will display for each TOU Map Relationship Type, which is referenced on a rate component with a generic RC Type of Calculation Algorithm . When this node is expanded, information about every Calculation Algorithm rate component, which references this relationship type is displayed.

The Interval Profile collection contains effective-dated information that defines the interval profiles linked to the service agreement. Refer to Interval Pricing Background Topics for more information.

To link an interval profile to a service agreement, enter the Interval Profile Relationship Type that defines the role that this interval profile will serve for the service agreement. Choose the Interval Profile Id for the profile that you wish to link to this service agreement. This profile may be Common or SA Owned .

Fastpath:

If the profile does not exist yet, then you must create it. Refer to How to Link Common Profiles to a Service Agreement and How to Link SA Owned Profiles to a Service Agreement for more information.

The Start Date/Time indicates the date and time that this profile is linked to the service agreement for this profile relationship type.

The End Date/Time indicates the date and time that this profile is no longer linked to the service agreement for this profile relationship type.

The Status values are Active and Inactive . By default, all records are active. The system will use the start date/time and end date/time to ensure that it processes the correct profile for the SA and Profile Relationship Type for the correct time period. No two profiles may be active for the same SA, Profile Relationship Type and overlapping time period. A user may change the status of a record to Inactive . The system will not change this status.

If data for this profile is derived using a creation algorithm on the interval profile's profile type, then the Derivation Algorithm and the Creation Priority for the interval profile type are displayed.

Fastpath:

Refer to Setting Up Interval Profile Types for more information about linking data creation algorithms to an interval profile type.

The Derive Interval Data button will be enabled when the service agreement is in a billable status. Use this button to create profile data through data derivation. Clicking this button opens the Derive Interval Data dialog box.

In the resulting dialog box, turn on Force Derivation and enter a Force Derivation Start Date if you wish the system to re-derive data for a period that may have already been derived.

Note:

Not all algorithms will necessarily support force derivation. It depends on whether or not the algorithm can detect changes in the source data.

Enter the Cutoff Date to indicate to the system until what date to generate data for.

After clicking Process, the system will execute any "Interval Data Creation" derivation algorithm linked to the profile type of an SA Owned profile where this SA is the owner. The algorithms are executed in creation priority order.

Note:

You can design your control tables so that the appropriate common and SA-owned profiles are linked to the service agreement at start time. Refer to Designing Your Interval Billing Start Options for more information about designing and setting up these start options.

The TOU Map collection contains effective-dated information that defines the TOU maps linked to the service agreement. Refer to Time of Use Mapping Background Topics for more information.

To link a TOU map to a service agreement, enter the TOU Relationship Type that defines the role that this TOU map will serve for the service agreement. Choose the TOU Map ID for the map that you wish to link to the service agreement. This map may be Common or SA Owned .

The Start Date/Time indicates the date and time that this TOU map is linked to the service agreement for this TOU map relationship type.

The End Date/Time indicates the date and time that this TOU map is no longer linked to the service agreement for this TOU map relationship type.

The Status values are Active and Inactive . By default, all records are active. The system will use the start date/time and end date/time to ensure that it processes the correct map for the SA and Map Relationship Type for the correct time period. No two maps may be active for the same SA, Map Relationship Type and overlapping time period. A user may change the status of a record to Inactive . The system will not change this status.

If data for this map may be created using a creation algorithm on the TOU map's map type, then the Derivation Algorithm and the Creation Priority for the TOU map type are displayed.

The Derive TOU Data button will be enabled when the service agreement is in a billable status. Use this button to automatically create TOU map data. Clicking this button opens the Derive Interval Data dialog box.

In the resulting dialog box, turn on Force Derivation and enter a Force Derivation Start Date if you wish the system to re-derive data for a period that may have already been derived.

Note:

Not all algorithms will necessarily support force derivation. It depends on whether or not the algorithm can detect changes in the source data.

Enter the Cutoff Date to indicate to the system until what date to generate data for.

After clicking Process, the system will execute any "TOU Data Creation" algorithm linked to the TOU map type of an SA Owned profile where this SA is the owner. The algorithms are executed in creation priority order.

Note:

You can design your control tables so that the appropriate common and SA owned TOU maps are linked to the service agreement at start time. Refer to Designing Your Interval Billing Start Options for more information about designing and setting up these start options.

If seasonal time shift records are linked to both the base time zone and to the time zone on the service agreement's characteristic premise, the Seasonal Time Shift associated with the time zone on the characteristic premise is displayed. Refer to Time Zone and Time Changes for more information.

The Seasonal Time Shift Remark indicates whether the data is displayed and should be entered in legal time or standard time. Refer to Interval Time Display for more information. If the data is displayed in legal time use the Show in Standard button to toggle to standard time. If the data is displayed in standard time use the Show in Legal button to toggle to legal time.

Service Agreement - TOU Contract Values

This page enables you to define customer specific time of use values. Refer to Customer Specific TOU Values for more information.

Open this page using Customer Information, Service Agreement, TOU Contract Values.

Description of Page

The service agreement may contain a collection of TOU contract values, which change over time.

Choose the Bill Factor that defines the type of value. You may only reference bill factors designated as "TOU" bill factor types and where the value may be in contract terms.

Indicate the TOU Group that corresponds with the TOU group on the service agreement's TOU Map. Once entered, the collection of TOU codes linked to this TOU group will display.

For a given TOU contract value entry, the Start Date and End Date indicate when these TOU values are effective.

For each Time of Use code, enter the appropriate Value.

TOU Contract Values Tree

The tree shows bill factors linked to the service agreement's rate that may have TOU contract values defined for them.

Service Agreement - Billing Scenarios

Note:

This tab may not appear. This tab is suppressed if the quotation Contract Management module is turned off.

This page allows you to define a proposal service agreement's billing scenarios. Refer to Proposal SAs Contain Billing Scenarios for more information.

Open this page using Customer Information, Service Agreement, Billing Scenarios.

Description of Page

This page is protected if the service agreement being displayed is not a proposal service agreement .

When a quote is generated for a proposal SA, the system creates a simulated bill segment for each billing scenario linked to the proposal SA. Each simulated bill segment shows the prospect how much their bill would be if the pricing terms on the proposal SA were applied to the billing scenario's consumption in the related time period.

Note:

You should not have to enter this information from scratch. You can set up the system to automatically generate billing scenarios when a proposal SA is created. Refer to Proposal SAs Contain Billing Scenarios for the details.

The following information is defined for each billing scenario:

- Start Date and End Date define the simulated bill segment's period.

- The grid contains the consumption that will be priced during this period:

- Unit of Measure is the unit of measure of the service quantity.

- TOU is the time-of-use code of the service quantity.

- SQI is the service quantity identifier of the service quantity.

- Initial Service Quantity is the initial quantity passed to the rate (and massaged by the rate's SQ rules).

- Service Point ID is used if your rate uses register rules that require characteristic values from the service point or premise. For example, the register rule that converts CCF to therms uses a bill factor to store the conversion factor. This bill factor may have been configured to use characteristics on the service point / premise (e.g., the conversion factor may differ based on the storage location associated with the service point).

Note:

Interval service agreements and template consumption. Refer to Proposal SAs And Interval Consumption for a description of how interval consumption is defined on a proposal SA.

Service Agreement - SA Portal

Select Main Menu > Customer Information > Service Agreement and navigate to the SA Portal tab to view additional information associated with an SA.

General Information

SA ID, SA Info are displayed.

Depending on your implementations requirements, you may define additional zones to appear on this Portals

Refer to The Big Picture of Portals and Zones in the Oracle Utilities Application Framework Administration Guide for a description of portal and zone functionality.

Maintaining SA Relationships

The SA Relationship page contains information about a specific relationship between a service provider and a customer.

Warning:

The following page looks deceptively simple. It's not. Refer to The Big Picture of SA Relationships and Service Providers for more information.

Open Customer Information, SA Relationship to maintain this information.

Description of Page

The SA Relationship Info is a concatenation of important information about the SA relationship record. The SA Rel ID is a system-assigned random number that stays with a SA relationship record for life. This value is assigned when the record is added to the database.

SA Relationship Status defines the state of the SA relationship. The buttons beneath the status are used to change the state:

- Click the Activate SA Rel button to activate a Pending SA relationship. This button is only enabled when the status of the SA relationship is Pending .

- Click the Cancel SA Rel button to Cancel an Active or Pending SA relationship. This button is only enabled when the status of the SA relationship is Active or Pending .

Note:

Automatic SA Relationship creation and activation. The system automatically creates and activates required SA Relationships when the Activate SA background process sees that there are required SA relationships for the master SA Type.

Account ID is the account associated with the Service Agreement ID. This field is protected after the SA relationship has been added to the database.

Use Service Agreement to define the "master" service agreement ID that has a relationship. This field is protected after the SA relationship has been added to the database.

Premise is a display-only field that shows the Service Agreement's characteristic premise (i.e., the primary premise associated with the service agreement).

Use SA Relationship Type to define the type of relationship. This field is only enabled if:

- a Service Agreement ID is specified, and

- the status of the SA Relationship is not Cancelled , and

- all sub SAs in the grid at the bottom of the page (if any) are Cancelled .

Enter the Effective Date of the relationship. This field is only enabled if:

- a SA Rel Type is specified, and

- the status of the SA Relationship is not Cancelled .

Usage defines how this relationship is used. The following options are available:

- Relationship With SPr . Use this option if this relationship is used to define a relationship between a customer and a service provider.

- Expire SA Relationship . Use this option if this relationship expires any prior relationship between a customer and a service provider and there is no relationship with a service provider going forward.

The Service Provider associated with this relationship is the one who provides the related service, if any. You can only choose service providers who are linked to the "master" service agreement's SA type and the above SA Rel Type. This field is only enabled if:

- Usage is Relationship with SPr , and

- a SA Rel Type is specified, and

- the status of the SA Relationship is not Cancelled , and

- all sub SAs in the grid at the bottom of the page (if any) are Cancelled .

If the Service Provider reads the customer's meter (as defined on the service provider's record), the customer's override Read Cycle should be defined. This field is only enabled if:

- a Service Provider is specified, and

- the Service Provider has the ability to override the service point's service cycle, and

- the status of the SA Relationship is not Cancelled

The Account Number in Provider's CIS is the customer's ID in the service provider's system. This field is only enabled if:

- a SA Rel Type is specified, and

- the status of the SA Relationship is not Cancelled .

The Create Sub SA button is used to create Sub Service Agreements for a service provider for which your organization provides billing services. This button will be gray if:

- you do not provide billing services for the service provider (i.e., the service provider doesn't have a billing relationship of It's Us or We Bill For Them ), or

- if the SA relationship's Status is not active , or

- if the status of the master Service Agreement is not Active , Pending Start , or Pending Stop .

The grid at the bottom contains the sub service agreements (if any) that exist when your organization provides billing service for the Service Provider. You can click the Go To button on a row to transfer to the sub service agreement. Refer to Sub Service Agreements for more information. Note: you can click the Create Sub SA button to create sub service agreements for a service provider.

Note:

Automatic sub SA creation. The system will automatically create sub service agreements for you. It does this when the Analyze SA Relationships background process (known by the batch control ID of ANLYZSAR ) sees that a new SA relationship has been activated.

Service Provider SA Relationship

Use this page to manage a service provider's SA relationships and customers. You can view a given service provider's SA relationships of a given type that is in effect on a specified date. You can expire existing relationships or add new relationships. This page is particularly useful for managing negotiated terms.

Open Customer Information - Service Provider SA Relationship to view this information.

Description of Page

Enter the Service Provider and SA Relationship Type of the SA relationships that should be displayed.

Enter an Effective Date. This date filters the results so that only those SA relationships that are in effect on this date are shown.

Use SA Filter to restrict the SA relationships that are shown in the grid based on criteria of the related master service agreement. The following options are available:

- Address . Use this option to restrict SA relationships to those whose service agreements are linked to service points associated with a given Address, City and/or Postal code. Note, you can specify any combination of these fields.

- All . Use this option if you do not wish to restrict SA relationships based on service agreement attributes.

- Geographic Type . Use this option to restrict SA relationships to those whose service agreements are linked to premises or service points associated with a given Geo Type and Value.

- SA Type . Use this option to restrict SA relationships to those whose service agreements are linked to a given CIS Division and SA Type.

Don't forget to click the search button after changing the filters.

The Select All / Clear All buttons are used to select / unselect the SA relationships in the results grid. These buttons are enabled if there is at least one SA relationship in the results grid.

The grid that follows contains a line for each SA relationship that has a status of pending or active that meets the search criteria. Canceled SA relationships are not shown. If an SA relationship has more than one sub-SA, additional lines are used to show the additional sub-SA information. The following information appears in the grid:

- Select box. Use this checkbox to select SA relationships that you want to expire using the Expire SA Relationship(s) button.

- Click the go to button to transfer to the Account - Main page where you can perform maintenance functions on the account listed under Account Information.

- The Account ID column shows the account of the master SA linked to the SA relationship.

- The Account Information column shows information about the account identified by the account ID.

- Click the go to button to transfer to the Premise - Main page where you can perform maintenance functions on the premise listed under Premise Information.

- The Premise Information column shows information about the premise of the service point linked to the master SA of the SA relationship. If the master SA is linked to multiple service points, one is selected at random.

- The Premise ID column shows the ID of the premise whose premise information is shown.

- Click the go to button to transfer to the Service Agreement - Main page where you can perform maintenance on the service agreement listed under SA Information.

- The SA Information column shows information about the master SA that the SA relationship is linked to.

- The SA ID column shows the ID of the master SA that the SA relationship is linked to.

- Click the go to button to transfer to the Service Agreement - Main page where you can perform maintenance on the service agreement listed under Sub SA Information.

- The Sub SA Information column shows information about the sub SA linked to the SA relationship.

- The Sub SA ID column shows the ID of the sub SA linked to the SA relationship.

- Click the go to button to transfer to the SA relationship page where you can perform maintenance functions on the SA relationship listed under SA Relationship Information.

- The SA Relationship Information column shows information about the SA relationship meeting the search criteria.

- The SA Relationship ID column shows the ID of the SA relationship meeting the search criteria.

Following the grid is a section with action buttons that allow you to add or expire relationships for the given service provider:

- Press the Expire SA Relationship(s) button to expire the SA relationships that you have selected with the checkbox. You will be asked to confirm the date that you want the selected SA relationships to expire. Each selected SA relationship is expired by creating a new SA relationship without a service provider, i.e., its Usage is to Expire SA Relationship . This new SA relationship will be effective the day after the expiration date you specify. This is because an SA relationship that expires on a given day is deemed to be effective until the end of that day.

- Note that you can only expire SA relationships where the SA type and SA relationship type allow gaps in the relationship.

- Press the Add SA Relationship button to add a new SA relationship for the service provider and SA relationship type entered above. Enter the effective date for the new SA relationship and the service agreement that the new SA relationship is for. After confirmation, a new SA relationship is added in a pending status. Note that if there is an existing SA relationship with the same effective date whose Usage is Expire SA , this relationship is replaced by a new SA relationship with the given service provider.

Maintaining Premises

The premise record contains geographic information about your service addresses.

The following methods list the various ways in which premises can be created:

- A premise can be added via the premise replicator.

- A premise can be added when an order is completed.

- A premise can be added using this transaction.

The topics in this section describe the premise maintenance transaction.

Fastpath:

For more information about premises and their place in the "V", refer to Understanding The "V". For more information about the relationships between premises, service points, meters and items, refer to An Illustration Of A Premise.

Contents

Premise - Main Information

Premise - Characteristics

Premise - Miscellaneous

Premise - Geographic Data

Premise - Alternate Address

Premise - Premise Portal

Premise - Main Information

The Premise page contains basic premise information. Open Customer Information, Premise and navigate to the Main tab to maintain this information.

Description of Page

Basic information about the Premise and the premise's unique identifier (i.e., the Premise ID) are displayed on every page. These values only appear after the premise exists on the database. The ID is a system assigned random number that stays with a premise for life.

Note:

Formatting is performed by a plug-in. The basic information about a premise that appears at the top of this page (and on many other pages in the system) is controlled by a plug-in algorithm on the installation record. Refer to the base package's premise format algorithm for an example. If you prefer a different format, your system administrator should configure the system appropriately.

Indicate the Premise Type to categorize the type of premise.

The address's constituent fields vary based on the Country. Please refer to the Country page for more information.

Note:

Default note. A premise's state, city, county, division, characteristics, trend area and geographic data default from your postal default information. Refer to Setting Up Premise & Service Point Postal Defaults for more information. If you change the premise's postal code, the system will default geographic values based on the new postal code.

Use CIS Division to define the jurisdiction in which the premise is located. This defaults based on the Country and the Postal Code, but can be overridden here.

The Validate button on the premise page will only be available if you have set the Allow Address Validation option type to Y on the General System Configuration feature configuration. Once clicked, the Address Validation Script on the General System Configuration feature configuration will be invoked to validate the entered address. Refer to unresolvable-reference.html for more information.

Indicate whether the address is a valid Mailing Address. Premises that are valid mailing addresses may be specified as the mailing premise on an account. Refer to Account - Person Information for more information.

Use Landlord Agreement to define the landlord agreement that covers the premise, if any.

Note:

Landlord reversion. When you specify a landlord agreement on a premise, you are telling the system that service associated with the premise's service points should be reverted to the landlord's account when a tenant stops service. The system uses this information during the stop service process to automatically create pending start service agreement(s) for the landlord.

Managing a large number of premises for the same landlord If the premise management module is not turned off, the premise management page helps you to manage the premises linked to the landlord.

If the premise management module is not turned off, you may reference a Parent Premise to include this premise in a premise hierarchy.

At the bottom of this page is a tree that shows the various objects linked to the premise. 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.

Premise - Characteristics

The Characteristics page contains information that controls taxation and other rate options that differ based on geography. Use Customer Information, Premise and navigate to the Characteristics tab to open this page.

Description of Page

Many charges that appear on bills associated with consumption at this premise are controlled by the premise's characteristic values (e.g., the taxing city defines the city tax percent applied to the premise's consumption). Refer to An Illustration Of A Bill Factor And Its Characteristics for more information.

Characteristics also matter if your rates were set up to convert measured consumption into some other unit of measure before charges can be calculated (e.g., converting a cubic foot of gas to its therm value). Refer to Setting Up Register Rules for more information.

Note:

You can only choose characteristic types defined as permissible on the premise 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 premise. The effective date defaults to the current date when you are changing an existing premise.

Characteristic Type Indicate the type of characteristic.

Characteristic Value Indicate the value of the characteristic.

Note:

Default note. A premise's characteristics default from your postal default information. Refer to Setting Up Premise & Service Point Postal Defaults for more information. If you change the premise's postal code, the system will default characteristic values based on the new postal code.

Premise - Miscellaneous

The Miscellaneous page contains information meter read controls and life support information related to the premise. Use Customer Information, Premise and navigate to the Misc tab to open this page.

Description of Page

Turn on OK to Enter if the meter is located in the interior of the premise and your company has permission to enter.

Indicate a MR Warning if a specific warning should be downloaded to the person who reads the meter.

Indicate a MR Instruction if specific instructions should be downloaded to the person who reads the meter. Meter read instructions and warnings are downloaded as part of the meter read download.

Use Instruction Details to provide more detailed instructions to the individual who reads meters at this premise.

Turn on Key at Premise if the meter is secured in a locked area and your company has the key. If this field is turned on, you may also specify the Key ID.

Specify the Trend Area in which the premise is located. A premise's trend area plays an important role in how consumption at the premise is estimated for high / low and missing read purposes.

Note:

Default note. A premise's trend area defaults from your postal default information. Refer to Setting Up Premise & Service Point Postal Defaults for more information.

Indicate if the premise has life support or sensitive load equipment. Valid values are: LS/SL (i.e., the premise has life support / sensitive load equipment), None . If a value of LS/SL has been selected, define the type of equipment in LS / SL Description.

Note:

A person can also have life support / sensitive load information. If the equipment is personal (i.e., it travels with the person as they move from premise to premise), you should NOT specify the life support information on the premise. Rather, transfer to Person - Main and specify life support information on the person.

Alert and C&C. If the base package's C1-LSSL-PREM algorithm is enabled on the installation record, and life support / sensitive load information is specified, an alert will appear when the premise is displayed on control central. In addition, if a premise has life support or sensitive load equipment, it is possible for a different credit & collection severance process to be kicked off if the account associated with the premise has overdue debt. Refer to Designing Your Severance Procedures for more information.

Premise - Geographic Data

The Geographic Data page contains information that defines where the premise is located. Use Customer Information, Premise and navigate to the Geographic Data tab to open this page.

Description of Page

Enter the Time Zone in which the premise is located. This value defaults from your postal defaults. Please note that Time Zone is only relevant for interval billing customers. Refer to Time Zone and Time Changes for more information.

The geographic information is used by Control Central to look for premises. 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).

Default note. A premise's geographic data defaults from your postal default information. Refer to Setting Up Premise & Service Point Postal Defaults for more information. If you change the premise's postal code, the system will default geographic values based on the new postal code.

Premise - Alternate Address

Warning:

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 premise'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 premise has an alternate address, both the main and alternate addresses can be used to search for a premise.

Open Customer Information, Premise and navigate to the Alternate Address tab to maintain this information.

Description of Page

The remaining fields on the page are used to define the premise's alternate address.

The address's constituent fields vary based on the Country. Country is always protected on this page because a premise'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 Premise & Service Point 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.

Premise - Premise Portal

Select Main Menu > Customer Information > Premise and navigate to the Premise Portal tab to view additional information associated with a Premise.

General Information

Premise ID, Premise Info are displayed.

Depending on your implementations requirements, you may define additional zones to appear on this Portal.

Refer to The Big Picture of Portals and Zones in the Oracle Utilities Application Framework Administration Guide for a description of portal and zone functionality.

Maintaining Service Points

Service point records contain information describing the services supplied to a premise.

The following methods list the various ways in which service points can be created:

- A service point can be added when a premise is created using the premise replicator.

- A service point can be added when an order is completed.

- A service point can be added using this transaction.

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

Fastpath:

For more information about service points and their place in the "V", refer to Understanding The "V". For more information about the relationships between premises, service points, meters and items, refer to An Illustration Of A Premise.

Contents

Service Point - Main Information

Service Point - Facilities

Service Point - Characteristics

Service Point - SP Type Info

Service Point - Geographic Information

Service Point - Multiple Items

Service Point - Device History

Service Point - Equipment

Service Point - Operations Area

Service Point - SP/SA

Service Point - Field Info

Service Point - SP Route Configuration

Service Point - SP Portal

Service Point - Main Information

This page contains basic service point information. Use Customer Information, Service Point to open this page.

Description of Page

Service Point information and SP ID are displayed on every page. These values only appear after the service point exists on the database. The ID is a system assigned random number that stays with a service point for life. The Service Point information is a concatenation of important details about the service point and its premise.

Enter the Premise ID of the premise at which the service point is located.

Indicate the SP Type. A service point's SP type controls the following:

- It defines the type of service delivered at the SP.

- It defines the service point as metered or item-based.

- It plays a part in how consumption at the service point is estimated for high / low and missing read purposes.

- It defines characteristics that are the same for all of its service points.

- It defines the type of field activities that may be performed at its service points.

- It defines the type of meters that may be installed at its service points.

- It defines the type of service agreements that may pay for service at its service points.

- It defines the types of equipment that may be linked to its service points.

Fastpath:

Refer to Setting Up Service Point Types for more information about SP types.

Use the Service Point Status to indicate if the service point is In Service or Abolished . SP status controls whether the service point can be linked to new service agreements.

Note:

The values for the SP status field are customizable using the Lookup table. This field name is SP_STATUS_FLG.

If the Service Point Status is In Service , the Abolished Date is gray; otherwise, it contains the date the service point was abolished.

Specify the Install Date. This is the date of the installation of the service point at the premise. It is not the date of installation of any meters or other physical device(s) at the service point.

The following service point information will not be displayed for all SP Types. If the SP Type allows external service requests, portions of this information will be hidden for adding service points. All of these fields will be hidden for maintaining an existing service point that allows external service requests:

- Use the Service Point Source Status to define whether the service point is connected to the source of power. Valid values are: Connected and Disconnected . If the source status is disconnected, use Disconnect Location to specify where service was severed. Source status impacts the type of field activity created for the service point under various circumstances. For example, if a customer wants to start service at a service point that is disconnected, a field activity that reconnects the service point would be generated. Refer to Setting Up Field Activity Type Profiles for more information about automated field activity generation.

- Use Location to define where the service point is located on the premise. If needed, Location Details may be used to clarify the location at the premise.

- If the SP Type uses a service route, specify the Service Cycle, Service Route, and Service Cycle / Route Sequence to define the logical position of the service point in the meter reader's route.

- At the bottom of this page is a tree that shows the various objects linked to a service point. 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.

Service Point - Facilities

This page contains miscellaneous information about a service point. Use Customer Information, Service Point and navigate to the Facilities tab to open this page.

Description of Page

Designate the facility hierarchy that supplies service to the service point using the Facility Levels. The prompts that appear in front of the facility levels differ depending on the type of service (the type of service is defined on the service point's SP type).

Use the Description to specify anything special about the service point.

Service Point - Characteristics

The characteristics page contains information that describes miscellaneous information about the service point. Use Customer Information, Service Point, Characteristics to open this page.

Description of Page

Service point characteristics are purely informational. The following fields are displayed:

Effective Date Indicate the effective date of the characteristic type and value. The service point's install date defaults.

Characteristic Type Indicate the type of characteristic.

Characteristic Value Indicate the value of the characteristic.

Note:

Default note. A service point's characteristics default from your postal default information. Refer to Setting Up Premise & Service Point Postal Defaults for more information.

Service Point - SP Type Info

The SP type info page is an information only page that shows the characteristics the service point inherits from its SP type. Use Customer Information, Service Point and navigate to the SP Type Info tab to open this page.

Description of Page

This page shows the characteristics the service point inherits from its SP type. No fields on this page may be modified.

Service Point - Geographic Information

The Geo page contains geographic information that defines where the service point is located. Use Customer Information, Service Point and navigate to the Geo tab to open this page.

Description of Page

The following fields are displayed:

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.

If the geographic type has a required format, you must enter the geographic value in the respective format; the system will NOT convert the input value into the relevant format.

Note:

Default note. A service point's geographic data defaults from your postal default information. Refer to Setting Up Premise & Service Point Postal Defaults for more information.

Service Point - Multiple Items

The multi-item page is used to define the non-badged items that exist at the service point. Refer to Service Points With Multiple Items for more information about when to set up this information for a service point.

Use Customer Information, Service Point and navigate to the Multi-Item tab to open this page.

Description of Page

Billing accumulates all unbadged items linked to a service point and levies a charge for each type of item based on information in the service agreement's rate.

The collection of items at a service point is effective dated and therefore when you modify this information, you must differentiate between:

- Correcting how the collection of items looked historically by changing existing data.

- Adding another collection of items to reflect how the items look after field work has taken place.

Note:

Removing Multi-items from a Service Point. If you want to remove all multi-items from a service point, add a multi-item collection that doesn't include any items. The effective date should be the date the multi-items were removed from the service point (i.e. no longer applicable to the rate).

Define the Effective Date of the collection of items.

The following fields display:

Item Type Indicate the type of item, its description is displayed adjacent.

Item Count Indicate how many of the given type of item exist at the service point.

Service Point - Device History

The device history page is an information only page that shows the meters or items that have been installed at the service point. Use Customer Information, Service Point and navigate to the Device History tab to open this page.

Description of Page

This page shows the history of meters / items that have been installed at this service point. No fields on this page may be modified. Refer to Installing and Removing A Meter and Installing and Removing An Item for more information.

Service Point - Equipment

The equipment page contains the equipment that is linked to the service point. Use Customer Information, Service Point, Equipment to open this page. Refer to Equipment May Be Associated With Service Points for more information.

Description of Page

The following fields display:

Equipment ID Indicate the unique equipment identifier. When a piece of equipment is entered, its Badge Number and Equipment Type description are displayed adjacent.

Note:

This is actually the ID of an item as an item must be set up for each piece of equipment that can be linked to a service point. Only items with an item type defined on the service point's SP type's equipment collection may be defined (in other words, the valid types of equipment are defined on the service point's SP type).

Equipment Count This field should be 1 except when you are using an item to define a generic piece of equipment. If you use an item to define a generic piece of equipment, you can indicate the number of such generic pieces of equipment that are associated with this service point.

Install Date Define the date that the equipment was installed at the service point.

Removal Date Define the date that the equipment was removed from the service point.

Comment Use comments to explain anything unusual about the piece of equipment.

Service Point - Operations Area

The Op Area page is used to define the operation area that is assigned to field activities associated with this premise. A different operation area can be associated with different categories of field activities (identified by a field activity's field activity type's field service classification). Use Customer Information, Service Point, Op Areas to open this page.

Description of Page

The following fields display:

Field Service Class Indicate the field service classification.

Operation Area Specify the operation area that manages field activities associated with the field service classification.

Note:

Default note. A service point's operations areas default from your postal default information. Refer to Setting Up Premise & Service Point Postal Defaults for more information.

Service Point - SP/SA

The SP / SA page contains the service agreements that are linked to the service point.

This information is updated by the system when service is started. You should only have to access this page if you need to fine-tune what the system defaults.

Warning:

You must understand the "V" very well before attempting to maintain this information. Refer to Understanding The "V" for more information.

Use Customer Information, Service Point and navigate to the SP/SA tab to open this page.

Description of Page

Billing uses SP / SA information to amalgamate consumption when it calculates a bill segment for a service agreement. To modify information for a service agreement linked to the service point, simply move to a field and change its value. To add a new service agreement, click +, then fill in the information for each field.

This page works exactly the same as the Service Agreement - SA / SP page except for the field described below:

Service Agreement The identity of the service agreement. The division and type of the service agreement is displayed adjacent. This field is gray after the service agreement is committed to the database.

Fastpath:

For a detailed description of the remaining fields on this page, refer to Service Agreement - SA / SP.

Service Point - Field Info

The Field Info page allows the user to override premise field information on a specific service point. It also shows the corresponding premise field information.

Use Customer Information, Service Point and navigate to the Field Info tab to open this page

Description of Page

To override premise field information on a specific service point, set Override Premise Field Information to Yes . If the value is set to No , the premise information may not be overridden.

Turn on OK to Enter if the meter is located in the interior of the premise and your company has permission to enter.

Indicate a MR Warning if a specific warning should be downloaded to the person who reads the meter.

Indicate a MR Instruction if specific instructions should be downloaded to the person who reads the meter. Meter read instructions and warnings are downloaded as part of the meter read download.

Use Instruction Details to provide more detailed instructions to the individual who reads meters at this premise.

Turn on Key at Premise if the meter is secured in a locked area and your company has the key. If this field is turned on, you may also specify the Key ID.

Service Point - SP Route Configuration

The SP Route Configuration page contains the effective dated route configurations for the Service Point.

Note:

This tab may not appear. This tab page only appears if the service point's SP Type allows multiple route usage.

Description of Page

Define the Effective Date of the collection of Service Routes.

Use Comments to explain anything unusual about the service point.

The Service Routes grid contains a row for each unique Service Cycle/Route :

Specify the Service Cycle in which the service point resides.

Use External Route Reference to indicate how this service point is referenced in an external system, if applicable.

Enter the Service Cycle/Route Sequence to define service point's relative position within the route.

Fastpath:

Refer to Designing Cycles for Metered Services and Designing Cycles for Waste Collection Services for information on designing service cycles.

Service Point - SP Portal

Select Main Menu > Customer Information > Service Point and navigate to the SP Portal tab to view additional information associated with a Service Point.

General Information

SP ID, SP Info are displayed.

Depending on your implementations requirements, you may define additional zones to appear on this Portals

Refer to The Big Picture of Portals and Zones in the Oracle Utilities Application Framework Administration Guide for a description of portal and zone functionality.

Dashboard Portal

The Dashboard is a portal that always appears on the Oracle Utilities Customer Care and Billing 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.

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 premise 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 Utilities Customer Care and Billing. Please see Core Dashboard Zones for a description of other zones that can appear on the dashboard.

Contents

Current Context Zone

Customer Contact Zone

Financial Information Dashboard Zone

Alert Dashboard Zone

Current Context Zone

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

A maximum of three rows may appear:

- The first row contains a person context menu and 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. 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.

- The second row contains an account context menu and the account's:

- ID and check digit

- The primary name of the main customer

- Customer class

- The last row contains a premise context menu and the premise's address and premise type. Note, the address information is formatted by a plug-in algorithm on the installation record. Refer to the base package's premise format algorithm for an example. If you prefer a different format, your system administrator should configure the system appropriately.

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, you can click the hyperlink in the Last area to go to the newly added contact where you can set up reminders or indicate the contact should remain open until future resolution.

Financial Information Dashboard Zone

The Financial Zone that appears on the dashboard contains the same information that is described in the Financial Information Zone on the account information portal.

Alert Dashboard Zone

The Alert Zone that appears on the dashboard contains the same information that is described in the Alert Zone on the account information portal.

Setting Up Bill Print Groups

Bill print groups allow you to categorize an account's service agreements into groups for bill print purposes.

Note:

Bill print groups are optional. Typically, only accounts with many SAs will use bill print groups because the standard bill print priority is sufficient for accounts with a limited number of SAs. Refer to SA 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 service agreements (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 customer, their bill segments will be printed in the order dictated by each segment's service agreement's SA type's bill print priority. If you create a bill print group for this customer, you can define the customer's desired categories (e.g., police, courts, DPW, etc.) and then link each of the account's SAs 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 customers have the exact categorization preferences, you will have to set up multiple bill print groups.

- Over time, a customer could have many bill print groups. This would happen if a customer'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 service agreements appear on the bill maintenance transaction.

- If new service agreements 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 service agreements 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).

Warning:

While the system supports the definition of bill print groups and the categorization of an account's service agreements 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 service agreements to its subgroups.

Contents

Bill Print Group - Main

Bill Print Group - SA Sub Group

Bill Print Group - Main

Open Customer Information, Bill Print Group to maintain an account's bill print group and subgroups. After defining this information, transfer to the SA Sub Group tab to link the account's service agreements 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 customer to change their preferences over time. For example, if the customer 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 service agreement 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 a service agreement that is not linked to a subgroup (it links this service agreement 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 SA Sub Group tab to link the account's service agreements to the subgroups.

Bill Print Group - SA Sub Group

This page is used to link the account's service agreements to one of the bill print group's subgroups.

Open Customer Information, Bill Print Group and navigate to the SA Sub Group page 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 service agreements that appear in the SAs in Bill Print Group grid. The following points describe the various options:

- Use the SA Filter to define the types of service agreements that appear in the grid. The following options are available:

- Address. Use this option to restrict service agreements to those linked to service points associated with a given Address, City and/or Postal code. Note, you can specify any combination of these fields.

- All. Use this option if you do not wish to restrict service agreements based on service agreement attributes.

- Bill Print Sub Group. Use this option to restrict service agreements to those that are linked to a given Bill Print Sub Group.

- Geographic Type. Use this option to restrict service agreements to those linked to service points associated with a given Geo Type and Value.

- SA Type. Use this option to restrict service agreements to those linked to a given CIS Division and SA Type.

- Use Status Filter to restrict the service agreements based on their status. The following options are available:

- All . This option shows all service agreements regardless of status.

- Refer to Service Agreement Lifecycle for the various status values.

Don't forget to click the search button after changing the filters.

The SAs in Bill Print Group contains an entry for every non-cancelled service agreement 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 service agreement.

- Use Sequence when there is more than one service agreement in the subgroup. The sequence controls the order in which the service agreement's financial information appears on the bill.

- The SA Information column provides a brief description of the service agreement.

- The Service Agreement column contains the unique identifier of the service agreement.

- The Premise Information column contains the characteristic premise associated with the bill segment's service agreement.

The next set of filters control the service agreements that appear in the SAs Not in Bill Print Group grid. The following points describe the various options:

- Use the SA Filter to define the types of service agreements that appear in the grid. The following options are available:

- Address. Use this option to restrict service agreements to those linked to service points associated with a given Address, City and/or Postal code. Note, you can specify any combination of these fields.

- All. Use this option if you do not wish to restrict service agreements based on service agreement attributes.

- Geographic Type. Use this option to restrict service agreements to those linked to service points associated with a given Geo Type and Value.

- SA Type. Use this option to restrict service agreements to those linked to a given CIS Division and SA Type.

- Use Status Filter to restrict the service agreements based on their status. The following options are available:

- All . This option shows all service agreements regardless of status.

- Refer to Service Agreement Lifecycle for the various status values.

Don't forget to click the search button after changing the filters.

The SAs Not in Bill Print Group contains an entry for every non-cancelled service agreement 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 service agreement.

- Use Sequence when there is more than one service agreement in the subgroup. The sequence controls the order in which the service agreement's financial information appears on the bill.

- The SA Information column provides a brief description of the service agreement.

- The Service Agreement column contains the unique identifier of the service agreement.

- The Premise Information column contains the characteristic premise associated with the bill segment's service agreement.

Landlord Reversion

Landlord reversion occurs when a landlord would like to have service reverted to his/her name when a tenant moves out. The landlord defines his/her reversion preferences using a landlord agreement.

- A landlord's preferences can differ for each type of service. For example, you can indicate that a specific landlord always wants electric and gas service reverted to his/her account when a tenant stops service. However, they do not want water service to revert.

- A landlord's preferences can also be seasonal. For example, you can indicate water service should only revert to the landlord's account during the winter.

The account to use for the reversion of service is defined on the landlord agreement.

Assuming that you have plugged-in a landlord reversion algorithm on SA type, the system uses the information defined on landlord agreement to create a pending start service agreement(s) for the landlord when service for the existing tenant is stopped.

The following examples illustrate how your organization's landlord reversion algorithm might handle various scenarios for a premise that defines a landlord agreement that indicates service should be reverted:

- When the existing customer calls to stop service and no new customer is scheduled to move in, a pending start service agreement is created for the landlord.

- When a new customer calls in to start service

- If the start date matches the outgoing customer's start date, the pending start service agreement for the landlord is canceled

- If the start date is earlier than the outgoing customer's stop date, the pending start service agreement for the landlord is canceled and the stop date of the outgoing customer is changed to match the new date

- If the start date is later than the outgoing customer's stop date, the pending start service agreement for the landlord is updated with a stop date that matches the new customer's start date

- If changes are made to start or stop dates for the tenants' service agreements, a service agreement for the landlord may need to be created or canceled

- If the change in dates causes a gap in service that did not exist before, a landlord service agreement is created to cover the gap

- If the change in dates means that the tenants are now starting and stopping on the same date (and there used to be a gap), a landlord service agreement is canceled

- If the new customer cancels their pending stop, a landlord service agreement is created (if one did not exist) or the landlord SA's stop date is removed (if the new customer's start date resulted in a gap that was being covered by the landlord.

Setting Up Landlord Agreements

The landlord agreement page is used to maintain a landlord's service reversion preferences.

Note:

A landlord could have many landlord agreements. A landlord will have at least one landlord agreement. However, if the landlord has different service reversion preferences for different properties, you can create multiple landlord agreements - one for each set of preferences. After a landlord's reversion preferences have been defined, link the landlord agreement record to the respective premises.

Use Customer Information, Landlord Agreement to open this page.

Description of Page

Landlord and Landlord ID only appear after the landlord is added to the database. Landlord ID is a system-assigned random number that stays with the landlord agreement for life. Landlord is the description of the landlord agreement.

If the premise management module is not turned off, a message is displayed indicating the number of premises linked to this landlord. Clicking the hyperlink message text transfers you to the premise management page, which helps you to manage the premises linked to the landlord.

Enter a Description of the landlord agreement.

Use Account ID to define the account to use when service is reverted to the landlord. This should be one of the landlord's accounts.

The grid that follows contains one row for each type of service to be reverted to the landlord's account. Any service point whose service type is not referenced in this scroll will NOT revert to the landlord's account when a tenant stops service. For each row define the following:

- Service Type defines the type of service point that will revert to the landlord's account when a tenant stops service. Note, a service point inherits its service type from its SP Type.

- Turn on Seasonal if the service should only revert to the landlords account during a specific season of the year. When turned on, you must define the Start Month/Day and the End Month/Day of the effective season.

Note:

The month and day must be entered in the format MM/DD. For example, if a season starts on March 1, you must enter the value as 03/01.

Using The Premise Replicator

You use the premise replicator to create many copies of a premise and its service points.

Perform the following steps to replicate a premise:

- Add a premise .

- Add one or more service points to the premise.

- Use the premise replicator to create copies of the premise and its service points.

The topics in this section describe how to use the premise replicator.

Contents

Premise Replicator - Main Information

Premise Replicator - Premise

Premise Replicator - Premise SPs

Premise Replicator - Main Information

You use this page to create many copies of a given premise and its service points.

Warning:

The system warns you if you attempt to create. However, this is just a warning as you may want to generate similar premises and then update them with, for example, a unique apartment number on Premise - Main Information.

Use Customer Information, Premise Replicator to open this page.

Description of Page

Choose the Premise that serves as the template premise.

Note:

Recommendation. Carefully verify the template premise using the other pages in this page before you save the replicated premises. After you save the replicated premises, any corrections could prove time consuming.

The two sections at the top of the page determine the number of replica premises to be created and the address information that will be set up for each premise. The left section is used to define how the system will create the part of the address that is different for each replica premise. The right section defines the parts of the address that will be the same for each replica premise.

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 premise. 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 premise will be 1020 Main St .

- Choose Apartment Number if the replicated number should suffix the Base value in the first address line of the premise. 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 premise will be 101 Main St, Apt. 1020 .

Indicate the Number Of Premises 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 premises. Use Start # to define the number assigned to the first copy of the premise. 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 Premises 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 premise. This information is defaulted from the template premise 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 premises. You can use the sections at the bottom of the page to view the premises that will be created when you click save. The left section will show how Address Line 1 will look on the first 10 premises. If you are creating more than 10 premises, the right section will show how Address Line 1 will look on the last 10 premises. If everything looks clean, click save.

Premise Replicator - Premise

The Premise page is a display only page provided to let you confirm that the premise you selected on the add dialog is the one to be used as the template by the replicator. Use Customer Information, Premise Replicator, Premise to open this page.

Description of Page

This is a display only page that displays key information about the premise being replicated.

Premise Replicator - Premise SPs

This is a display only page provided to let you confirm that the premise you selected on the add dialog is the one to be used as the template by the replicator. Use Customer Information, Premise Replicator, Premise SPs to open this page.

Description of Page

This is a display only page that displays the details about the template premise's service points.

Start / Stop

The topics in this section describe how to start and stop service.

Warning:

Please see Order versus Start / Stop for a discussion of the pros and cons of using the order transaction versus the start / stop transaction to start service.

Contents

The Big Picture Of Starting Service

The Big Picture Of Stopping Service

Start/Stop Maintenance

The Big Picture Of Starting Service

Almost all requests to start service involve a conversation between a customer and a customer service representative (CSR). During this conversation, the following is defined:

- WHO will pay for the service (i.e., the account).

- WHERE the service is consumed (i.e., the premise). Note, this is only required for premise-oriented services.

- WHEN the service is requested (i.e., the start date).

- WHAT TYPE of service is desired (i.e., the service agreement and service points).

- HOW MUCH will be paid for the service (i.e., the rate and contract riders).

After the conversation is complete, one or more service agreements in the state of pending start will exist. If the service agreement uses service points, field activities may also be created.

In this section, we provide background information about the start process. For information about the page used to start service, refer to Start Stop Maintenance.

Contents

The Lifecycle Of A Pending Start Service Agreement

Starting Service & Field Activities

Activating Pending Starts

What Happens After A SA Is Started?

The Lifecycle Of A Pending Start Service Agreement

When you request a new service for a customer, a pending start service agreement is created. The following diagram illustrates the lifecycle of a typical pending start service agreement:

The above diagram is referenced in the topics that follow.

Starting Service & Field Activities

When you initiate a request to start service, the system creates a service agreement in the state of pending start . If the service agreement is service point-oriented, pending field activities necessary to start will be created at some point prior to the service agreement being activated. The question is when? The contents of this section provide information about when they are created and what types of activities are created.

Fastpath:

When you enable the Control Central alert algorithm, C1-PEND-STRT, an alert displays when there is a pending start service agreement linked to the account. This algorithm is plugged-in on the installation record.

Contents

What Type Of Start Field Activities Are Created

When Start Field Activities Are Created

How To Start Service Using A Scheduled Meter Read

What Type Of Start Field Activities Are Created

The type of the service point (e.g., electric residential, gas industrial) and the state of service (e.g., disconnected / no meter, connected / meter installed) at the service point dictate the type of field activity. For example, if the service point doesn't currently have a meter, the new field activity should request a meter installation. Whereas if there's already a meter installed, but it's turned off, the type of field activity should be to turn on the meter.

If you've set up your system properly, the system creates the appropriate field activity given the type and state of the service point; you shouldn't have to be aware of field activities.

In addition to being linked to the service points, these field activities are also linked to the service agreement / service point relationship so that the system can automatically activate the service agreement when the field activities are complete .

Note:

Back-to-Back. We use the term back-to-back to describe the situation when a single field activity supports both the stop and start service requests. The fieldwork algorithm delivered with the base package sets up a back-to-back situation by default when it is aware of both the start AND stop customers at a premise.

Fastpath:

For more information about the field activities associated with your SP types, refer to Setting Up Field Activity Type Profiles. Refer to The System Activates Most Service Agreements Behind-The-Scenes for information about how the system monitors field activities linked to a service agreement. Refer to The Lifecycle Of Field Activities And Field Orders for information about how field activities are dispatched and completed.

When Start Field Activities Are Created

Field activities will be created when the pending start service agreement is created if the following conditions are true:

- The Create Field Activity Start Stop switch is enabled on the installation record. Refer to Installation Options - Main for more information.

- The appropriate create fieldwork creation algorithm is defined on the service agreement's SA type. Refer to SA Type - Algorithms for more information.

If the Create Field Activity Start Stop switch is NOT enabled on the installation record, field activities will NOT be created when the pending start is saved. Rather, a background process (referred to by the batch ID of PSASPM ) creates the field activities shortly before the start date. The number of days before the start date on which field activities will be created is defined on the service agreement's SA type's fieldwork creation algorithm.

Note:

A fail safe. If any person or process attempts to activate a pending start service agreement and neither of the above events has taken place, field activities will be created when the user attempts to activate the pending start . The creation of the field activities will prevent the service agreement from being activated as described under The System Activates Most Service Agreements Behind The Scenes.

Warning:

Field activities will only be created if you have defined the appropriate field work creation algorithm on the service agreement's SA type. The algorithm that is supplied with the base package checks if the service agreement / service point already has a start read or a start field activity, if so, field activities will not be created (the field work has already been initiated).

How To Start Service Using A Scheduled Meter Read

Another option exists for starting service when all that is required is a meter reading. If the requested start date is close to a scheduled meter read date, you can forego a special trip into the field to get the reading. The system can use the scheduled meter read as long as it is close enough to the start date (you can determine how "close enough" is defined using a parameter on the batch process described below).

If the start date does not exactly match the date that the meter was read, it will prorate the reading, store it as a meter read of type system prorated , and will link it to the SA/SP so that the service agreement can be started. A special batch process (called FANRMRCO ) exists to perform the analysis of whether or not a reading is available and if its date is close enough (the number of days is an input parameter to the process). It performs the proration as well and creates the special meter reads.

Fastpath:

Refer to Background Processes for more information on this process.

To use scheduled reads to start service, you need to set up and use a special field activity type: "Meter Read Near Cycle" - it will not be eligible for dispatch and its only step type is "read meter". The base package supplied field activity creation algorithm accepts this field activity type as an input parameter. Start (and stop) events are then created with field activities that use this field activity type. The batch process mentioned above looks for field activities of this type and tries to use a scheduled meter read to complete them.

Note:

Note: if FANRMRCO cannot find a reading in the specified time period, it will cancel the special field activity and create a normal activity according to the field activity profile. If it finds a peak demand type reading or a consumption type reading, it posts a To Do entry. The type of To Do entry is defined as a parameter of the batch process.

Activating Pending Starts

When you initiate a request to start service, the system initiates a service agreement in the state of pending start . A pending start service agreement remains in this state until everything necessary to start service is defined in the system. At that time, the service agreement can be activated.

Contents

What Is Necessary To Start Service?

The System Activates Most Service Agreements Behind-The-Scenes

What Happens At Activation Time?

What Is Necessary To Start Service?

The service agreement's SA type defines what is necessary to start service:

- For SA types that have service points, all field activities linked to the service point must be complete before the service agreement can be activated. If field activities are linked to the service agreement, the system automatically links the appropriate billable read to the service point as its start read when the field activity is complete. (The completed field activity should have a read linked to it. If it is billable, it is used as the start read.)

- For SA types that don't have service points (e.g., charitable donations, deposits, one-time charges), everything necessary to activate the service agreement is defined when you initiate the request to start service. These types of service agreements can be activated immediately.

Warning:

If the completed field activity linked to the SA / SP doesn't have an associated read (for whatever reason), the system still activates the service agreement but leaves the SA/SP without a starting read. It does this because it relies on billing to create a bill segment error the first time it attempts to bill the service agreement.

If a service agreement has required SA relationship types (e.g., if an energy supply service agreement must have a SA relationship defining the distribution company), the system activates the service agreement even when these required relationships are not defined. It does this because it counts on billing to create a bill segment error the first time it attempts to bill the service agreement (billing creates an error bill segment for a service agreement if it does not have its required SA relationships defined).

The System Activates Most Service Agreements Behind-The-Scenes

Service agreements are activated by one of the following methods:

- The SA activation background process (referred to by the batch control ID of SAACT ) automatically activates pending start service agreements once it detects that everything necessary to start service is defined in the system. This is the most common method for activating service agreements. This process runs as often as your organization desires (but it should run at least daily).

Note:

Sub SAs are not handled by the SA activation background process. If your organization uses the SA relationship functionality and you have service providers that necessitate sub service agreements, you should be aware that the SA activation background process only activates normal and master SAs; sub SAs are activated by the analyze SA relationships background process (described in the next bullet point).

- If your organization uses the SA relationship functionality and you have service providers that necessitate sub service agreements, the analyze SA relationships background process (referred to by the batch control ID of ANLYZSAR ) automatically activates pending start sub SAs if their master SA is active .

- You can automatically activate a service agreement when it's created if you plug-in an SA creation algorithm of type SACR-AT on the SA type. Because everything necessary to start service must be defined in the system before a service agreement can be activated, this method only works for SA types that don't have service points (e.g., charitable donations, deposits, one-time charges, etc.). If this algorithm is not plugged in on an SA type, service agreements of that type are activated by the SA activation background process or manually.

- You can activate a service agreement manually (assuming everything that's necessary to activate service is in place). Simply open Service Agreement - Main and click the Activate SA button. This is only necessary if you do not want to wait until the SA activation background process next runs.

What Happens At Activation Time?

When a service agreement is activated, the following takes place:

- If the service agreement has start-oriented field activities linked to its service points, billable read(s) from the field activity(s) are linked to the service agreement's service points as their start reads. If there are no associated billable reads, the system still starts the service agreement knowing that billing will generate an error when the service agreement is billed.

- The service agreement's state is changed from pending start to active .

- If the account's bill cycle is not protected and the service agreement has a metered service point, the bill cycle will be changed to reflect the service point's service cycle's bill cycle.

- If the account's mailing premise is not protected and the service agreement has a service point whose premise is a mailing premise, the mailing premise is changed to reflect the service point's premise.

- If the account's division is not protected, the division is changed to reflect the service agreement's SA type's division.

- If there is a start adjustment defined on the service agreement's start option, an adjustment is levied.

- The main customer's billing address is changed to reflect the value specified on the Start/Stop page (and this may involve changing the main customer's override mailing address on their person record).

What Happens After A SA Is Started?

Fastpath:

Refer to The Lifecycle Of A Service Agreement for more information about a service agreement's lifecycle.

The Big Picture Of Stopping Service

To stop service you must define:

- WHO pays for the service (i.e., the account).

- WHEN service should stop (i.e., the stop start date).

- WHAT services to stop (i.e., the premise or specific service agreements).

After the above is defined in the system, the state of one or more service agreements will be changed to pending stop . If the service agreement uses service points, field activities may also be created.

In this section, we provide background information about the stop process. For information about the page used to stop service, refer to Start Stop Maintenance.

Contents

The Lifecycle Of A Pending Stop Service Agreement

Stopping Service & Field Activities

Finalizing Pending Stops

What Happens After A Service Agreement Is Stopped?

The Lifecycle Of A Pending Stop Service Agreement

When you request to stop service for a customer, the status of an existing service agreement becomes pending stop . The following diagram illustrates the lifecycle of a typical pending stop service agreement:

The above diagram is referenced in the topics that follow.

Stopping Service & Field Activities

When you initiate a request to stop service, the system changes the service agreement to the state of pending stop . If the service agreement is service point-oriented, pending field activities necessary to stop will be created at some point prior to the service agreement being stopped. The question is when? The contents of this section provide information about when they are created and what types of activities are created.

Contents

What Type Of Stop Field Activities Are Created

When Stop Field Activities Are Created

How To Stop Service Using A Scheduled Meter Read

What Type Of Stop Field Activities Are Created

The type of the service point (e.g., electric residential, gas industrial) and the state of service (e.g., disconnected / no meter, connected / meter installed) at the service point dictate the type of field activity. For example, an industrial electric meter may require a different type of field activity to stop service than does a residential gas meter.

If you've set up your system properly, the system creates the appropriate field activity given the type and state of the service point; you shouldn't have to be aware of field activities.

In addition to being linked to the service points, these field activities are also linked to the service agreement / service point relationship so that the system can automatically stop the service agreement when the field activities are complete .

Note:

Back-to-Back. We use the term back-to-back to describe the situation when a single field activity supports both the stop and start service requests. The fieldwork algorithm delivered with the base package sets up a back-to-back situation by default when it is aware of both the start and stop customers at a premise.

Fastpath:

For more information about the field activities associated with your SP types, refer to Setting Up Field Activity Type Profiles. Refer to The System Finalizes Most Service Agreements Behind-The-Scenes for information about how the system monitors field activities linked to a service agreement. Refer to The Lifecycle Of Field Activities And Field Orders for information about how field activities are dispatched and completed.

When Stop Field Activities Are Created

Field activities will be created when the pending stop service agreement is recorded when the following conditions are true:

- The Create Field Activity Start Stop switch is enabled on the installation record. Refer to Installation Options - System for more information.

- The appropriate create fieldwork creation algorithm is defined on the service agreement's SA type. Refer to SA Type - Algorithms for more information.

If the Create Field Activity Start Stop switch is NOT enabled on the installation record, field activities will NOT be created when the pending stop is saved. Rather, a background process (referred to by the batch ID of PSASPM ) creates the field activities shortly before the stop date. The number of days before the stop date on which field activities will be created is defined on the service agreement's SA type's fieldwork creation algorithm.

Note:

More information about the Create Field Activity Start Stop switch on the installation record. When this switch is on (and the user doesn't override it), pending field activities will be created when a start or stop is recorded (as opposed to shortly before the start / stop date). You might want to turn this switch off if it's possible for the state of the service point (or its meter / item) to change between the time service is requested and the actual service date. Why? Because the state of the SP and its meter / item affects the type of field activity that is created. For example, if a customer wants to start service and there is no meter at the metered service point, an "install meter" field activity is created. However, if by the time the install date comes around, a meter has been installed by some other means; this field activity is inappropriate. This is why if you might want to set up the system to wait until shortly before the service date to create the field activity (i.e., it reduces the likelihood that an inappropriate field activity is created).

A fail safe. If any person or process attempts to finalize a pending stop service agreement and neither of the above events has taken place, field activities will be created when the user attempts to finalize the pending stop . The creation of the field activities will prevent the service agreement from being stopped as described under The System Finalizes Most Service Agreements Behind The Scenes.

Warning:

Field activities will only be created if you have defined the appropriate field work creation algorithm on the service agreement's SA type. The algorithm that is supplied with the base package checks if the service agreement / service point already has a stop read or a stop field activity, if so, field activities will not be created (the field work has already been initiated).

How To Stop Service Using A Scheduled Meter Read

Another option exists for stopping service when all that is required is a meter reading. If the requested stop date is close to a scheduled meter read date, you can forego a special trip into the field to get the reading. Refer to How To Start Service Using A Scheduled Meter Read for more information; the stop service option works in the same way and uses the same field activity type.

Finalizing Pending Stops

When you initiate a request to stop service, the system changes the service agreement's state to pending stop . A pending stop service agreement remains in this state until everything necessary to stop service is defined in the system. At that time, the system automatically changes the state of the service agreement to stopped, and at that time the service agreement can be final billed.

So, how does the system know that "everything necessary" is in the system? In this section we provide the answer and explain the many other things that may take place at pending stop finalization.

Contents

The System Finalizes Most Service Agreements Behind-The-Scenes

What Happens At Finalization Time?

The System Finalizes Most Service Agreements Behind-The-Scenes

The SA activation background process (referred to by the batch control code SAACT ) finalizes a pending stop service agreement when everything necessary is in place. The service agreement's SA Type defines what's necessary:

- For SA Types that don't have service points (e.g., charitable donations, deposits, third party billing), everything necessary to finalize the service agreement is defined when you initiate the request to stop service. These types of service agreements can be finalized immediately.

- For SA Types that have service points, all field activities linked to the service point must be complete . If field activities are linked to the service agreement, the system will automatically link the appropriate billable read to the service point as its stop read when the field activity is complete .

Warning:

If the completed field activity linked to the SA / SP doesn't have an associated read (for whatever reason), the system still stops the service agreement but leaves the SA/SP without a stop read. It does this because it counts on billing to create a bill segment error when it attempts to final bill the service agreement.

When the SA activation background process detects that everything necessary to stop service is in place, it automatically stops the service agreement. This process runs as often as your organization desires (but it should run at least daily).

Note:

Sub SAs are not handled by the SA activation background process. If your organization uses the SA relationship functionality and you have service providers that necessitate sub service agreements, you should be aware that the SA activation background process only stops normal and master SAs; sub SAs are stopped by the analyze SA relationships background process.

You can stop a service agreement real-time (assuming everything that's necessary to stop service is in place). Simply open Service Agreement - Main and click the Stop button.

What Happens At Finalization Time?

When a service agreement is finalized, the following takes place:

- If the service agreement has stop-oriented field activities linked to its service points, billable read(s) from the field activity(s) are linked to the service agreement's service points as their stop reads. If there are no associated billable reads, the system still stops the service agreement knowing that billing will generate an error when the service agreement is billed. Note, you can see the field activities that are linked to a service agreement using Service Agreement - Service Point.

- If the service agreement's SA type has a SA Stop algorithm, the algorithm is executed.

- If the service agreement is for a non-billed budget (i.e., the SA type has a special role of Non-billed Budget ), the system removes all covered SAs from the non-billed budget. Refer to Stopping Non-billed Budgets for more information.

- If the service agreement is covered by a non-billed budget, the SA is removed from the non-billed budget. Refer to Stopping a Covered SA for more information.

- When the last active service agreement covered by a non-billed budget is stopped , the non-billed budget will be stopped (i.e., its state will be changed from active to pending stop ).

- The service agreement's state will be changed from pending stop to stopped .

- If the service agreement has an active severance process, the process and its severance events will be canceled.

- If the service agreement is linked to an active collection process, the service agreement is "removed" from the collection process. If the collection process has no other active service agreements, it is canceled .

- When the last service agreement linked to an account is stopped , the account's bill cycle will be changed so that the account will be final billed when billing next executes. The system selects the latest open bill cycle where the Freeze and Complete switch value matches the value of the Freeze and Complete switch of the account's current bill cycle. In addition, the account's protect bill cycle flag is set to No so that the next time this account starts service, its bill cycle will be set based on the new service point's service cycle.

- The main customer's billing address will be changed to reflect the value specified on the Start/Stop page (and this may involve changing the main customer's override mailing address on their person record).

- If the service agreement is for a deposit (i.e., the SA type has a special role of Cash Deposit ), the system calculates interest through the stop date. In addition, the SA's current balance is synchronized with its payoff balance (using the sync adjustment code defined on the service agreement's SA type).

- When the last active service agreement governed by a deposit class is stopped , all active deposit service agreements governed by the same deposit class will be stopped (i.e., their state will be changed from active to pending stop ). These pending stop deposit service agreement will then be stopped (as per the above points).

- When a service agreement is stopped, the system automatically cancels the budget. Refer to Canceling A Budget for more information.

What Happens After A Service Agreement Is Stopped?

Fastpath:

Refer to The Lifecycle Of A Service Agreement for more information about a service agreement's lifecycle.

Start/Stop Maintenance

You use the start/stop page to both start and stop service.

This page handles a variety of scenarios, including:

- Starting some or all services at a premise. Note, the system will automatically stop the existing customer when you indicate a new customer is starting.

- Stopping some or all services at a premise. Note, the system will automatically revert service to a landlord's account when you indicate a tenant is stopping.

- Starting non-premise-oriented services.

- Stopping non-premise-oriented services.

- Changing the mailing address associated with the account's main customer.

Fastpath:

Refer to The Big Picture Of Starting Service for more information about starting service. Refer to The Big Picture Of Stopping Service for more information about stopping service.

The topics in the section describe the start/stop page in detail.

Contents

Start/Stop - Main

Start/Stop - Start Confirmation

Start/Stop - Stop Confirmation

Start/Stop - Address/Phone

Start/Stop - Pending SA

Start/Stop - Pending Field Activity

How To

Start/Stop - Main

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 start/stop functions.

Use Customer Information, Start Stop to open this page.

Description of Page

The Account ID and the primary name of the Account's main customer are displayed at the top of the page.

If the total number of pending start / stops for the account does not exceed the start stop details threshold defined in Installation Options, the grid contains an entry for every Pending Start and Pending Stop service agreement linked to the Account ID.

If information appears on the right portion of the grid, that means that "reciprocal relationships" exist. The following points describe potential reciprocal relationships:

- A reciprocal will be shown for a Pending Start service agreement if the Pending Start service agreement has at least one service point and if another service agreement is found that satisfies the following criteria:

- The status of the service agreement is not Canceled or Active ,

- The service agreement is linked to all of the Pending Start service agreement's service points (and all SA/SP records have the same stop date as defined on the qualifying service agreement).

- The service agreement's stop date is on/before the start date.

- The service agreement's SA type has a service type that is the same as the Pending Start service agreement's service type.

- Note: if multiple service agreements meet the above criteria, the latest qualifying service agreement is shown as the reciprocal.

- A reciprocal will be shown for a Pending Stop service agreement if the Pending Stop service agreement has at least one service point and if another service agreement is found that satisfies the following criteria:

- The status of the service agreement is not Canceled

- The service agreement is linked to all of the Pending Stop service agreement's service points (and they all have the same start date as defined on the qualifying service agreement).

- The service agreement's start date is on/after the stop date.

- The service agreement's SA type has a service type that is the same as the Pending Stop service agreement's service type.

- Note: if multiple service agreements meet the above criteria, the earliest qualifying service agreement is shown as the reciprocal.

Note:

If multiple reciprocals exist for a given SA, none of the reciprocals will be shown. In this situation, an appropriate message is displayed highlighting this situation. The existence of multiple reciprocals is rare, but it could happen, for example, if multiple customers are paying for a service point's service (where one customer pays for 60% of the metered consumption and the other pays for the remaining 40%).

The following columns appear in the grid:

Drill Down (button) Click this button to drill down into details of the pending start / stop SA. This button transfers you to the Pending SA tab.

Action An icon will be displayed to highlight if the associated SA is a pending start or a pending stop. The icon appears if the SA is a pending start. The icon appears if the SA is a pending stop. If there is a reciprocal SA for the pending start, the icon appears adjacent; clicking it will cause the SA grid to scroll to the left (so that you can see the pending stop). If there is a reciprocal SA for the pending stop, the icon appears adjacent; clicking it will cause the SA grid to scroll to the left (so that you can see the pending start).

Date This is the start date for pending start service agreements and the stop date for pending stop service agreements.

Cancel Turn on this switch if you wish to cancel the pending start / stop.

Note:

Field activities will be cancelled too. If you cancel a pending start / stop that has field activities, the field activities will also be cancelled. Refer to Starting Service & Field Activities for the details about how the system automatically creates the field activities to support start service requests. Refer to Stopping Service & Field Activities for the details about how the system creates the field activities to support stop service requests.

System-generated reciprocals will be cancelled too. If you cancel a pending start / stop that has a SYSTEM-GENERATED reciprocal SA, the reciprocal will also be cancelled.

Premise Information If a characteristic premise is linked to the service agreement, summary information about the pending start / stop SA's characteristic premise is displayed.

SA Information Summary information about the pending start / stop SA is displayed.

Action If this column is blank, then there is no reciprocal start/stop for the service agreement whose details appear to the left. If this column is not blank, then the information that appears to the right describes the reciprocal SA of the SA to the left. If a reciprocal SA exists, two icons will always appear: if a combination appears, the SA to the left is a pending stop (and clicking the icon will cause the pending stop to appear); if a combination appears, the SA to the left is a pending start (and clicking the icon will cause the pending start to appear).

Date This is the start date for pending start service agreements and the stop date for pending stop service agreements.

Cancel Turn on this switch if you wish to cancel the pending start / stop.

Note:

Field activities will be cancelled too. If you cancel a pending start / stop that has field activities, the field activities will also be cancelled. Refer to Starting Service & Field Activities for the details about how the system automatically creates the field activities to support start service requests. Refer to Stopping Service & Field Activities for the details about how the system creates the field activities to support stop service requests.

System-generated reciprocals will be cancelled too. If you cancel a pending start / stop that has a SYSTEM-GENERATED reciprocal SA, the reciprocal will also be cancelled.

Account Info The name of the main customer associated with the reciprocal's service agreement's account is displayed.

Premise Information Summary information about the pending start / stop premise is displayed.

SA Information Summary information about the pending start / stop SA is displayed.

If the total number of pending start / stops for the account exceeds the start stop details threshold defined in Installation Options, the Total number of Pending Starts and Total number of Pending Stops is displayed together with a grid containing a summary of the pending start and pending stops.

The grid contains an entry for every group of Pending Start / Pending Stop service agreement linked to the Account ID with the same pending start / pending stop date, action, premise, and CIS division/SA Type.

The following columns appear in the grid:

Date This is the start date for pending start service agreements and the stop date for pending stop service agreements.

Action An icon will be displayed to highlight if the associated SA(s) are pending start or pending stop. The icon appears if the SA(s) are a pending start. The icon appears if the SA(s) are a pending stop. Click on the icon to navigate to the Start Stop - Pending SA tab where the associated pending start / pending stop service agreements will be displayed.

Premise Information Summary information about the pending start / stop premise is displayed.

CIS Division / SA Type This is the CIS division and service agreement type of the pending start / pending stop service agreements.

Total This is the total number of service agreements with the same Date, Action, Premise, and CIS Division / SA Type.

Following the Pending Start / Pending Stop grid are two sections; one is used to start service, the other is used to stop service.

The following points describe the fields in the start service section (refer to How To for a description of how to perform common start functions).

- Use Start Date to define the date on which you want service to commence.

- Use Start Method to define what you want to start. Valid values are:

- Start Premise SPs. Use this method if you want to start selected services at a premise. This method allows you to control the display of the service agreements to be started, providing a manageable view when there are many service agreements to be started at a premise.

- Start a Premise . Use this method if you want to start services at a premise.

- Start a SA . Use this method if you want to start a non-premise-oriented service (e.g., a deposit, a charitable contribution, a one-time charge).

- If you have selected the Start Premise SPsorStart a Premise option, use Address and City to select the premise. Refer to Control Central - Main for suggestions in respect of how to use these fields. The selected address and premise ID appear below the selection.

- If you have selected the Start a SA option, use CIS Division and SA Type to define the type of service agreement you wish to start.

Warning:

Take special care when adding a new service agreement to specify the appropriate CIS Division / SA Type as it will affect how the customer is billed, what rate can be specified, how overdue debt is collected, and much more. After the service agreement is activated, you may not change its SA type.

- Use Requested by to define who requested the stop (e.g., Customer , Jane Smith ).

- Click the Start button to start service. When you click this button, the Start Confirmation page appears.

The following points describe the fields in the stop service section (refer to How To for a description of how to perform common stop functions).

- Use Stop Date to define the date on which you want service to stop.

- Use Stop Method to define what you want to stop. Valid values are:

- Stop Selected SAs . Use this method if you want to stop selected service agreements linked to the account.

- Stop a Premise . Use this method if you want to stop ALL services at a premise.

- Stop a SA . Use this method if you want to stop a specific SA.

- Stop all Active SAs. Use this method if you want to stop ALL service agreements linked to the account.

- If you have selected the Stop a Premise option, choose the Premise ID. You can optionally choose a specific premise if you selected the Stop Selected SAs option.

- If you have selected the Stop a SA option, choose the SA ID.

- Use Requested by to define who requested the stop (e.g., Customer , Jane Smith ).

- Click the Stop button to stop service.

Start/Stop - Start Confirmation

The Start SA Confirmation page appears after a user clicks the Start button on Start/Stop - Main. This page presents a summary of the service agreement(s) that will be created if the Start button on this page is clicked. Refer to How To for a description of how to perform common start functions.

Description of Page

The Account ID and the primary name of the account's main customer are displayed at the top of the page.

The Start Date is the date on which the service is scheduled to start.

Start Requested By contains the name of the person who requested the start.

The SAs to Start scroll contains an entry for every service agreement that will be created if you click the Start button. If you do not want a service agreement to be created, click the - button (or turn off Start this SA). If you'd like to start a non-premise oriented service agreement, click the + button. The following fields appear on this page:

Start this SA Turn this switch on if you want this type of service agreement to be created. Turn this switch off if you do not want this type of service agreement to be created.

If you used a Start Method of Start a SA on the Start/Stop page, this switch will be turned on by default.

If you used a Start Method of Start a Premise (or Start Premise SPs ) and this is the first customer at a premise, this switch will be turned on for all service agreements that appear in the scroll. However, if there was a previous customer at the premise, this switch is only turned on for those types of service agreements used by the previous customer (we assume the new customer only wants the services used by the previous customer). Service agreements that are possible, but were not used by the previous customer, will appear in the scroll with this switch turned off.

CIS Division / SA Type These fields define the type of service agreement that will be created. If you change the CIS Division, you must change the SA Type to reflect one of the services that the division manages.

If the SA is linked to a service point, the SA types are restricted based on the type(s) of service points (SP) the system has associated with the service agreement (as indicated in the message box). If there are no SPs, only SA types that don't use SPs are displayed. If there is a single SP, only SA types valid for the related SP Type are displayed. If there are multiple SPs, only SA types valid for all related SP Types are displayed.

Note:

Default Note. If the service is linked to a service point, the SA Type defaults based on the SP Type. Refer to SP Type - SA Type for more information.

Start Option Some SA Types have start options. A start option defines the rate and contract terms defaulted on the service agreement. This field will be gray if the SA type does not use start options.

Total Amount to Bill Use this field if the service agreement is supposed to bill a given amount over its lifetime. This is typically used for deposit service agreements to define the amount of the deposit that should be billed. If the deposit is billed in installments, the installment amount is specified in the next field. This field is gray if the respective SA type doesn't use the Total Amount to Bill option.

This button is only appears if the SA typehas a "special role" of Cash Deposit and references a deposit class. When clicked, the system attempts to calculate a recommended deposit amount by calling the recommended deposit amount algorithm that is plugged in on the SA type's deposit class.

Customer Read Use this value to define if the customer reads his or her own meter. Valid values are Yes and No . This field does not appear for some SA types.

Allow Estimates Turn on this switch if it's OK for the system to estimate this service agreement's consumption if a real meter read is missing at billing time. If the SA type does not allow estimates, this does not appear.

Recurring Charge Amount This field's label is dynamic based on the content of the Recurring Charge Amount Label on the respective SA Type. This field is gray if the respective SA type doesn't use the Recurring Charge option. This field is typically used only for the following types of service agreements:

• Service agreements on a levelized payment plan. This field contains the amount charged each month for the service regardless of the actual amount owed.

• Merchandise service agreements on an installment plan. This field contains the installment amount.

• Deposit service agreements on an installment plan. This field contains the installment amount.

• Charitable contribution service agreement. This field contains the contribution amount.

Note:

Default note. The recurring charge amount defaults based on the Start Option.

SIC Code Select the SIC code associated with the customer. This is typically used only for commercial and industrial customers.

Business Activity Enter a description of the business activity at the location where this service is being started.

SA Information This is a display-only area that provides information about the specific pending start SA. For example, information about the service points linked to the SA will be displayed for SP-oriented service agreements.

Messages This is a display-only area that that provides information about the account's start / stop situation in general. For example, if there are multiple accounts paying for service at the premise an appropriate message will be displayed.

When you click the Start button, the system performs the following for every service:

- A service agreement is created effective on the start date.

- If a start option is specified, the service agreement's rate and contract terms are populated using information on the option. If a start option is not specified, the service agreement's rate is populated with the SA type's default rate.

- Service points are linked to the service agreement (if the service agreement is service point-oriented). The SA/SP start date for each service point is the same as the SA's start date.

If you use a Start Method of Start Premise SPs on Start/Stop - Main, the SAs to Start are displayed in a grid; you can control the service agreements that appear using filter options. You may want to use the filter if you have a premise with a large number of service agreements to start.

Premise Info displays summary information about the premise at which services are to be started.

The section beneath Premise Info provides you with options that control which service agreements appear in the grid. The following points describe the various options:

- Use the SP Type Filter to restrict the service agreements that appear in the grid based on the SP type of the service points that will be linked to the service agreement. The following options are available:

- All. Use this option if you do not wish to restrict service agreements based on service point type.

- Specific SP Type. Use this option to restrict service agreements to those that will be linked to service points of a specific SP Type.

- Use the Geographic Type Filter to restrict the service agreements that appear in the grid based on a geographic type and value of the service points that will be linked to the service agreement. The following options are available:

- All. Use this option if you do not wish to restrict service agreements based on a geographic type and value.

- <Geographic Type>. Use this option to restrict service agreements to those that will be linked to service points associated with the selected geographic type and Geographic Value.

- Select whether to Include or Exclude service agreements that are linked to service points where Service Exists Already. These service agreements are those that would be not be started by default. Refer to the description of the Start this SA checkbox for more information on service agreements that would be not be started by default.

Don't forget to click the search button after changing the filters.

The Select All / Clear All buttons are used to select service agreements to start. These buttons are enabled if at least one service agreement is displayed in the grid.

Note:

30 service agreements at a time. Clicking Select All selects the first 30 service agreements in the grid. If more than 30 service agreements exist, you must select and start them in batches.

The grid that displays contains the SAs to Start that match your filter criteria. Click on the drill down button to open the Start SA Confirmation Details page.

The fields in the grid on the Start SA Confirmation page and on the Start SA Confirmation Details page are as described above for the SAs to Start scroll. Differences are highlighted here:

SP Info This is summary information about the service point at which service is to be started.

SP Identifier The service point's SP type's identifying geographic type and value. Refer to Setting Up Service Point Types. Up to three geo types and values are displayed in the SAs to Start grid.

Click the Start button on the Start SA Confirmation page to start the selected SAs. Click on the Close button to return to the main page - any changes made on this page since the last time you clicked Start are discarded.

Start/Stop - Stop Confirmation

If you choose the stop method of Stop Selected SAs , the Stop SA Confirmation page appears after a user clicks the Stop button on Start/Stop - Main. This page presents a summary of the service agreement(s) that will be stopped if the Stop button on this page is clicked. Refer to How To for a description of how to perform common start stop functions.

Description of Page

The Account ID and the primary name of the account's main customer are displayed at the top of the page.

The Stop Date is the date on which the service is scheduled to stop.

Requested By contains the name of the person who requested the stop.

The section beneath Requested By provides you with options that control which service agreements appear in the grid. The following points describe the various options:

- Use the Premise Filter to restrict the service agreements to those that are linked to a specific characteristic premise. The following options are available:

- All. Use this option if you do not wish to restrict service agreements based on premise.

- No Premise. Use this option to restrict service agreements to those that do not have a characteristic premise.

- Specific Premise. Use this option to restrict service agreements to those with a characteristic premise of Premise ID.

- Use the SA Type Filter to restrict service agreements to those of a given SA Type.

- All. Use this option if you do not wish to restrict service agreements based on SA Type.

- Specific SA Type. Use this option to restrict service agreements to those of a given CIS Division and SA Type.

- Use the Geographic Type Filter to restrict the service agreements that appear in the grid based on the geographic type and value of the service points that are linked to the service agreement. The following options are available:

- All. Use this option if you do not wish to restrict service agreements based on a geographic type and value.

- <Geographic Type>. Use this option to restrict service agreements to those that will be linked to service points / premises associated with the selected geographic type and Geographic Value.

Don't forget to click the search button after changing the filters.

The Select All / Clear All buttons are used to select service agreements to stop. These buttons are enabled if at least one service agreement is displayed in the grid.

Note:

30 service agreements at a time. Clicking Select All selects the first 30 service agreements in the grid. If more than 30 service agreements exist, you must select and stop them in batches.

The grid that follows contains the service agreements to stop that match your filter criteria. The following information appears in the grid:

Select Box Use this checkbox to select service agreements that you want to stop.

Premise Information Summary information about the pending stop premise is displayed.

SA Information Summary information about the pending stop SA is displayed.

SP Identifier The service point's SP type's identifying geographic type and value. Refer to Setting Up Service Point Types. Up to three geo types and values are displayed.

Click the Stop button on the Stop SA Confirmation page to stop the selected SAs. Click on the Close button to return to the main page - any changes made on this page since the last time you clicked Stop are discarded.

Start/Stop - Address/Phone

Open Customer Information, Start Stop, Address/Phone to change basic information about a customer while you are starting or stopping service.

Note:

A subset of person and account information. This page features a subset of person and account fields that typically change when a customer moves. You can always use the Person or Account transactions to change this information.

This information is held in limbo. The information on this page will only be updated on the respective person / account when the first service agreement linked to the account is activated or stopped (i.e., this information is held in limbo until the pending start / pending stop is activated / stopped).

Main customer information. The information on this page is associated with the account's main customer (as defined on Account - Person Information ). If you need to change information about any other person linked to the account, you must transfer to Account - Person Information and make the changes there.

Use Bill Route Type to indicate how the bill is sent to the customer. If the Bill Route Type you select indicates that bills are routed via fax, make sure you specify a fax number in the Telephone Numbers below (note, 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, make sure to specify the person's Email Address below. If the Bill Route Typeyou selected indicates that bills are routed via the postal service, select the appropriate Address Source. This field is protected if bills are routed via email or fax. You have the following options:

- Choose Mailing Premise on Account if bills should be sent to the account's mailing premise. This address is displayed below.

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

- Choose Account Override if bills should be sent to the account person's override address. This address is displayed below. Typically, you would only choose this option if the person has multiple accounts and each account's bills should be sent to a different address.

If the Address Source is Person or Account Override , the respective address fields are displayed and may be changed. If the Address Source is Mailing Premise on Account , the account's mailing premise is displayed and cannot be modified. Refer to Premise - Main Information for information about these fields.

Note:

Default note. If you switch the Bill Route Type from a non-postal to postal routed, the Address Source defaults to the bill address source defined on the account (if one exists) or Mailing Premise on Account if bill address source is not specified for the main customer.

Fastpath:

Refer to Setting Up Bill Route Types for more information about bill route types.

Specify the customer's Email Address. This can be used to route bills to the customer via email (if your bill routing software supports this function).

Telephone Numbers are used by Control Central to look for accounts and persons. If the person has more than 20 phone numbers, the first 20 will be shown as display only with a message indicating that more phone numbers exist until you save your start or stop. Once the start or stop has been saved, you are able to modify the phone number collection.

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.

Start/Stop - Pending SA

If you need to change additional information about the pending start or stop SAs, navigate to the Pending SA tab. Alternatively, you can click the Drill Down button on the SA grid of the Main tab.

Description of Page

If the total number of pending start / stops for the account does not exceed the start stop details threshold defined in Installation Options, an entry appears in the scroll for each entry in the SA grid on the main page. Use the Pending Start/Stop SA navigation arrow buttons to select the pending SA you want to review or modify. This page is split between the primary SA on the top, and the reciprocal SA on the bottom. The following fields are available.

Primary SA:

SA Info Summary information about the pending start / stop SA is displayed.

Cancel Turn on this switch if you wish to cancel the pending start / stop.

Date This is the start date for pending start service agreements and the stop date for pending stop service agreements.

Reason This column indicates if the pending start / stop is System Generated or Customer Requested . System-generated starts are created when a tenant stops service at a premise covered by a landlord agreement. System-generated stops are created when a customer requests a start at a premise where the existing customer hadn't already requested a stop.

CIS Division / SA Type These fields define the type of service agreement that will be created. These fields will be gray if the service agreement is pending stop.

If you change the CIS Division, you must change the SA Type to reflect one of the services that the division manages.

If the SA is linked to a service point, the SA types are restricted based on the type(s) of service points (SP) the system has associated with the service agreement (as indicated in the message box). If there are no SPs, only SA types that don't use SPs are displayed. If there is a single SP, only SA types valid for the related SP Type are displayed. If there are multiple SPs, only SA types valid for all related SP Types are displayed.

Start Option Some SA Types have start options. A start option defines the rate and contract terms defaulted on the service agreement. This field will be gray if the SA type does not use start options or if the service agreement is pending stop.

Premise Summary information about the pending start / stop premise is displayed.

Reciprocal SA:

SA Info Summary information about the pending start / stop SA is displayed.

Cancel Turn on this switch if you wish to cancel the pending start / stop.

Date This is the start date for pending start service agreements and the stop date for pending stop service agreements.

Reason This column indicates if the pending start / stop is System Generated or Customer Requested . System-generated starts are created when a tenant stops service at a premise covered by a landlord agreement. System-generated stops are created when a customer requests a start at a premise where the existing customer hadn't already requested a stop.

CIS Division / SA Type These fields define the type of service agreement that will be created or stopped. This field will be gray if the service agreement is pending stop.

If you change the CIS Division, you must change the SA Type to reflect one of the services that the division manages.

If the SA is linked to a service point, the SA types are restricted based on the type(s) of service points (SP) the system has associated with the service agreement (as indicated in the message box). If there are no SPs, only SA types that don't use SP's are displayed. If there is a single SP, only SA types valid for the related SP Type are displayed. If there are multiple SPs, only SA types valid for all related SP Types are displayed.

Start Option Some SA Types have start options. A start option defines the rate and contract terms defaulted on the service agreement. This field will be gray if the SA type does not use start options or if the service agreement is pending stop.

Premise Summary information about the pending start / stop premise is displayed.

Account The name of the main customer associated with the reciprocal's service agreement's account is displayed.

If the total number of pending start / stops for the account exceeds the start stop details threshold defined in Installation Options, the pending start / stop SAs and their reciprocal SAs are displayed in a grid; you can control the service agreements that appear using filter options.

The section beneath Account provides you with options that control which service agreements appear in the grid. The following points describe the various options:

- Use the SA Action Filter to restrict the service agreements that appear in the grid to pending starts or pending stops. The following options are available:

- All. Use this option if you do not wish to restrict service agreements based on SA Action.

- Start. Use this option to restrict service agreements to pending starts.

- Stop. Use this option to restrict service agreements to pending stops.

- Use the date filter to restrict service agreements to those that will start or stop between the From Date and the To Date.

- Use the Premise Filter to restrict the service agreements to those that are linked to a specific characteristic premise. The following options are available:

- All. Use this option if you do not wish to restrict service agreements based on premise.

- No Premise. Use this option to restrict service agreements to those that do not have a characteristic premise.

- Specific Premise. Use this option to restrict service agreements to those with a characteristic premise of Premise ID.

- Use the SA Type Filter to restrict service agreements to those of a given SA Type.

- All. Use this option if you do not wish to restrict service agreements based on SA Type.

- Specific SA Type. Use this option to restrict service agreements to those of a given CIS Division and SA Type.

- Use the Geographic Type Filter to restrict the service agreements that appear in the grid based on the geographic type and value of the service points that are linked to the service agreement. The following options are available:

- All. Use this option if you do not wish to restrict service agreements based on a geographic type and value.

- <Geographic Type>. Use this option to restrict service agreements to those that will be linked to service points / premises associated with the selected geographic type and Geographic Value.

Don't forget to click the search button after changing the filters.

The Select All / Clear All buttons are used to select service agreements if you plan on issuing any of the mass update actions at the bottom of the page. These buttons are enabled if at least one service agreement is displayed in the grid.

Note:

30 service agreements at a time. Clicking Select All selects the first 30 service agreements in the grid. If more than 30 service agreements exist, you must select and start them in batches.

The grid that displays contains the service agreements that match your search criteria. Click on the drill down button to open the Pending SA Details page.

Please refer to the Pending Start/Stop SA scroll for a description of the fields in the pending start/stop SA grid on the Pending SA tab and on the Pending SA Details page. Additional fields are described here:

Pending SAs Grid:

- Select box. Use this checkbox to select service agreements for mass update.

- The Action icons highlight if the associated SA is a pending start or a pending stop and if there are reciprocal SAs. Refer to the action icon on Start Stop - Main.

Mass Update Buttons:

Use the Cancel Selected button to cancel the selected pending start / stops together with any associated reciprocal pending start / stops. This button is enabled if you have selected one or more pending SAs.

Use the Change Start/Stop Date button to change the start / stop date for the selected pending start / stop service agreements. If a selected start / stop has a reciprocal SA, its start / stop date is also changed. This button is enabled if you have selected one or more pending SAs.

Start/Stop - Pending Field Activity

When you start / stop service point-oriented service, field activities are typically created. You can view every non-cancelled, non-complete field activity linked to the account's service agreements on the Pending Field Activity page.

Note:

The field activities are NOT limited to those associated with starting / stopping service. So, if a customer has a pending "cut for non payment" field activity, it would also appear on this page.

Description of Page

An entry appears in the scroll for every Pending and Held field activity linked to the account's service agreements. The information in the Field Activity column contains a summary of the field activity and its service point. The information in the How Used column describes the purpose of the field activity (e.g., Start Activity , Stop Activity , Severance Activity ).

If the total number of pending start / stops for the account exceeds the start stop details threshold defined in Installation Options, you can control the field activities that appear using filter options.

The section beneath Account provides you with options that control which field activities appear in the grid. The following points describe the various options:

- Use the Schedule Date filter to restrict the field activities that appear in the grid to those that are scheduled between. The following options are available:

- All. Use this option if you do not wish to restrict field activities to a specific schedule date.

- Specific Date. Use this option to restrict the field activities to those with a schedule date between the From Date and the To Date.

- Use the Premise Filter to restrict the field activities to those that are linked to service points at a specific premise. The following options are available:

- All. Use this option if you do not wish to restrict field activities based on premise.

- Specific Premise. Use this option to restrict field activities to those linked to a service point at the given Premise ID.

- Use the SP Type Filter to restrict field activities to those that are linked to service points of a given SP Type.

- All. Use this option if you do not wish to restrict field activities based on SP Type.

- Specific SA Type. Use this option to restrict field activities to those of a given SP Type.

- Use the Geographic Type Filter to restrict the field activities that appear in the grid based on the geographic type and value of the service points that are linked to the service agreement. The following options are available:

- All. Use this option if you do not wish to restrict field activities based on a geographic type and value.

- <Geographic Type>. Use this option to restrict field activities to those that are linked to service points / premises associated with the selected geographic type and Geographic Value.

Don't forget to click the search button after changing the filters.

How To

The topics in this section describe how to perform common start/stop functions.

Contents

How To Start Service At A Premise

How To Stop Service At A Premise

How To Start A Deposit

How To Start A Charitable Contribution

How To Start A One-Time Charge Service Agreement

How To Start Service When Multiple Service Points Measure Consumption

How To Start Service At A Premise

The following instructions specifically reference the Start a PremiseStart Method. You can also use the Start MethodStart Premise's SPsand its corresponding user interface.

You navigate through the pages as follows:

- Use Control Central - Main to look for the customer. If the customer exists, click the Start Service button to transfer to Start/Stop. If the customer doesn't exist, add a new person/account by following the instructions under How To Add A New Customer From Control Central.

- Specify the Start Date, Start Method (Start a Premise), and select a premise (by entering the premise Address and clicking the search button).

- Click the Start button to review the various service agreements that will be created.

Note:

Service agreements are created. Each row in the scroll is associated with a service agreement. When you close the page, the system creates new service agreements in the state of pending start .

- If you're starting service at a premise, the system automatically populates the Start Confirmation page with information about every service agreement to be created. To do this, we make a basic assumption - the customer wants every service at the premise. If this assumption is incorrect, simply remove the service agreement from the scroll (by turning off the Start this SA switch) before closing the page.

Note:

Automatically stop the existing customer. If there's a customer currently paying for service at the premise, the system automatically sets up the stop information for the existing customer. The stop date of the existing customer is the start date of the new customer. If you don't want to stop the existing customer, simply indicate such in the scroll.

Warning:

Take special care when adding a new service agreement to specify the appropriate CIS Division and SA Type as it will affect how the customer is billed, what rate can be specified, how overdue debt is collected, and much more. After the service agreement is activated, you may not change its CIS Division / SA type.

Fastpath:

Refer to Starting Service & Field Activities for the details about how the system automatically creates the field activities to support start service requests.

How To Stop Service At A Premise

The following instructions specifically reference the Stop a PremiseStop Method. You can also use the Stop MethodStart Selected SAsand its corresponding user interface.

You navigate through the pages as follows:

- Use Control Central - Main to find the customer. Click the Stop Service button to transfer to Start/Stop.

- Specify the Stop Date, Stop Method (Stop a Premise), and select a Premise (the premise will have been pre-selected for you if you drilled down from Control Central).

- Click the Stop button to stop service at the premise.

- When you click the stop button, the system changes the status of each service agreement to pending stop and sets the stop date accordingly. If we stopped a service agreement that we shouldn't have, simply cancelthe stop by checking the Cancel column in the grid (and save the page)

Note:

Landlord reversion. If you stop service at a premise that references a landlord agreement, the system will automatically create pending start service agreements for the landlord for those service types covered by the landlord agreement.

Fastpath:

Refer to Stopping Service & Field Activities for the details about how the system creates the field activities to support stop service requests.

How To Start A Deposit

Charging a customer for a deposit involves creating a service agreement. Deposit service agreements are just like other service agreements in many ways:

- The system bills the customer for the deposit using information on the service agreement.

- The customer pays for the billed amount.

- If the customer doesn't pay, credit & collections starts a collection process to encourage the customer to pay.

Deposit service agreements differ from regular service agreements in the following ways:

- Deposit service agreements typically don't cause a receivable account to be affected when the deposit is billed. It is only when the deposit is paid that a financial transaction occurs (debit cash, credit deposit payable).

- Deposit service agreements have a credit balance when the billed amount is paid (the deposit paid by the customer is a liability of your company - it owes the customer this money).

- Deposit service agreements may be billed in installments or in a lump sum.

Creating a deposit service agreement involves the following steps:

- Select the account on Control Central and open Start/Stop.

- Enter a Start Date and Start Method of Start a Premise .

- Indicate the premise that the deposit service agreement will cover using the Address and click the Start button.

- After you click the Start button, the Start Confirmation page will appear:

- Choose an appropriate CIS Division / SA Type for the deposit service agreement.

- If Start Options have been created for the CIS Division / SA Type, you need only select the appropriate option and close the page. The system will use the information on the start option to populate the service agreement's billing parameters (e.g., the total deposit due, the installment amount, etc.).

- If Start Options have not been created for the CIS Division / SA Type, you must define the total amount of the deposit and the installment amount, if any. You define the total amount of the deposit in Total Amount To Bill. You can have the system recommend a deposit amount by pushing the that appears adjacent to this field.

- If you allow the customer to pay the deposit in installments, define the Installment Amount (the prompt for this field is defined on the SA type and therefore will differ depending on how you've set up the system). After defining this information, close the page. The system will use the information you entered to create a deposit service agreement.

Note:

The above information related to starting a deposit assumes that the deposit SA Type is set up as a premise-based service. If your company does not associate a deposit with a specific premise, you will need to set up your SA Type for the deposit accordingly. Then, you will need to use a Start Method of Start a SA.

How To Start A Charitable Contribution

If a customer elects to contribute money to a charitable organization, you must create a service agreement. Charitable contribution service agreements are just like other service agreements in many ways:

- The system bills the customer for the elected contribution amount using information on the service agreement.

- The customer pays the billed amount.

- If the customer doesn't pay, credit & collections may start a collection process to encourage the customer to pay (depending upon how the charitable contributions debt class has been set up on your system).

Charitable contribution service agreements differ from regular service agreements in the following ways:

- Charitable contribution service agreements typically don't cause a receivable account to be affected when the charitable contribution is billed. It is only when the charitable contribution is paid that a financial transaction occurs (debit cash, credit charitable contribution payable).

- Charitable contribution service agreements have no balance when the billed amount is paid because the money is being forwarded to a charity.

Creating a charitable contribution service agreement involves the following steps:

- Select the account on Control Central and open Start/Stop.

- Enter a Start Date and Start Method of Start a SA .

- Indicate the CIS Division / SA Type of the charitable contribution agreement and click the Start button.

- After you click the Start button, the Start Confirmation page will appear:

- If Start Options have been created for the CIS Division / SA Type, you need only select the appropriate option and close the page. The system will use the information on the start option to populate the service agreement's billing parameters (i.e., the charitable contribution amount to be periodically billed).

- If Start Options have not been created for the CIS Division / SA Type, you must define the charitable contribution amount (the prompt for this field is defined on the SA type and therefore will differ depending on how you've set up the system). After defining this information, close the page. The system will use the information you entered to create a charitable contribution service agreement.

How To Start A One-Time Charge Service Agreement

You create a one-time charge (i.e., billable charge) whenever a customer should be charged for a service that occurs outside the normal course of business. For example, you would create a billable charge to charge a contractor for the repair of a ruptured gas line.

A billable charge must reference a service agreement. This service agreement behaves just like any other service agreement:

- Bill segments are created for the service agreement. Whenever billing is performed for an account with billable charge service agreements, the system creates a bill segment for each unbilled billable charges.

- Payments are distributed to the service agreement. Payments made by an account are distributed to its billable charge service agreements just like any other service agreement.

- Overdue debt is monitored. The credit and collections process monitors billable charge service agreements for overdue debt and responds accordingly when overdue debt is detected.

Therefore, in order to levy a one-time charge, the customer must have a billable charge service agreement. If one already exists (because of a previous billable charge), you don't have to create a new service agreement. Rather, transfer to the Billable Charge page and add a billable charge for the service agreement. If the customer doesn't already have billable charge service agreement, create one by performing the following steps:

- Select the account on Control Central and open Start/Stop.

- Enter a Start Date and Start Method of Start a SA .

- Indicate the CIS Division / SA Type of the billable charge service agreement and click the Start button.

- After you click the Start button, the Start Confirmation page will appear. Simply close the confirmation page to save the agreement.

- After the billable charge service agreement has been created, add a billable charge to it (the easiest way is to use the SA context menu). Refer to Maintaining Billable Charges for more information.

How To Start Service When Multiple Service Points Measure Consumption

When you start service at a premise, the system automatically links service points to service agreements in the same manner as existed for the previous customer. So, if the previous customer amalgamated consumption of three service points and billed this under a single service agreement, the system will create the same configuration for the new customer.

This works fine when the unusual service point configurations have already been set up for the previous customer. However, it doesn't work when the premise is new. So, if you have a new premise that has multiple service points whose consumption needs to be amalgamated under a single service agreement, do the following:

- Start service for only one of the service points to be linked to the service agreement. When you start service, the system creates a service agreement, links the service point to it, and links a field activity to the service point.

- For every service point that wasn't linked to the service agreement:

- Create a field activity to start service at the service point.

- Link the service point to the pending service agreement and link the field activity to the service point on the service agreement. Both of these tasks are done on Service Agreement - SA / SP.

Note:

That's it. The activation process will automatically activate the service agreement when the fieldwork is complete on all of its service points.

The Big Picture Of 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 provide details about how customer contacts are created and used in the system.

Contents

Customer Contacts Are Associated With Persons, NOT Accounts

How Customer Contacts Are Created

Customer Contacts Are Used To Trigger Letters

A Customer Contact May Trigger Reminders

Customer Contacts Can Be Used As Case Files

Maintaining Customer Contacts

Customer Contacts Are Associated With Persons, NOT Accounts

Customer contacts are associated with a Person, not with an Account. 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 customer 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 plug-in an algorithm on the customer class object that creates a customer contact whenever an order is completed. Because the number and type of plug-ins can be customized for your implementation, we cannot provide a concise list of all such algorithms.

In addition to the above, a variety of events can trigger the creation of a customer contact. Refer to Customer Contacts Are Used To Trigger Letters for the details.

Customer Contacts Are Used To Trigger Letters

In order to send a letter to a customer, a customer contact must be created for the customer. 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 Printing Letters 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 customer requests a form to sign-up for automatic payment), the primary sources of customer contacts that trigger letters are via system events and algorithms. Besides algorithms, the following system events may generate customer contacts automatically:

- Collection events. When a customer falls in arrears, the system creates a collection process. A collection process is a series of events meant to encourage the customer to pay their outstanding debt. A classic collection event is one that creates a customer contact that, in turn, causes a letter to be sent to the customer requesting payment. Refer to The Big Picture Of Collection Events for more information.

- Severance events. The last event in a collection process typically creates a severance process for each service agreement that's in arrears. A severance process is a series of events that leads to service being severed. A classic severance event is one that creates a customer contact that, in turn, causes a letter to be sent to the customer warning of impending cutoff (or telling them they've been cutoff and the terms necessary to reinstate service). Refer to The Big Picture Of Severance Events for more information.

- Write-off events. After a customer has been final billed, a write-off process will be created. A write-off process is a series of events that leads to the debt being written off. A classic write-off event is one that creates a customer contact that, in turn, causes a letter to be sent to the customer informing them of that their debt has been referred to a collection agency. Refer to The Big Picture Of Write Off Events for more information.

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.

A Customer Contact May Trigger Reminders

If you want the system to remind you (via a To Do entry) about a customer-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.

Customer Contacts Can Be Used As Case Files

If a customer calls with a complaint (e.g., they suspect their bill is too high), you can start a "case file" for the complaint by creating a customer contact. This customer contact should be marked as "open".

Note:

Alerts. Customer contacts that are marked as being open cause an alert to appear when the customer is displayed on control central.

Over time, as you work on the case, you can add entries to the customer contact's log to describe your progress.

You can use the customer contact's reminder functionality to remind you to check out the case on a future date (or dates).

When the case is resolved, you simply turn off the customer contact's open indicator and add an appropriate entry to the log describing the resolution.

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.

Contents

Customer Contact - Main

Customer Contact - Log

Customer Contact - Characteristics

Customer Contact - Customer Contact Portal

Customer Contact - Main

Open Customer Information, Customer Contact to maintain a customer contact.

Note:

The dashboard. 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.

Select a Preferred Contact Method to indicate 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. Refer to Where Does The Address Come From for a description of which address the system displays.

- SMS. If this method is selected, the Contact Person's short message service (SMS) information displays.

Turn on the Open switch if the event that necessitated the contact hasn't been resolved. For example, if a customer calls with a high bill complaint and you can't resolve it immediately, you would turn on the Open switch and enter an appropriate entry in the Log. Refer to Customer Contacts Can Be Used As Case Files for more information.

Enter the Contact Date and Contact Time.

Note:

Default 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 the customer contact was created by a collection event, a severance event or a write-off event or is referenced by a field activity step, the Related Records contains information about the associated record.

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).

- 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 letter print background process executes).

- If your implementation team has plugged-in an Online Letter Image algorithm on Installation Options - Algorithms, 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 a technical description of how letter images are produced. The system comes with configurations to display letter images using BI Publisher and Documaker, but can work with other applications.

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 and Customer Contacts Can Be Used As Case Files 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 Customer Information, Customer Contact and navigate to the Log tab 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 and Customer Contacts Can Be Used As Case Files 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 Customer Information, Customer Contact and navigate to the Characteristic tab to maintain a customer contact's characteristics.

Note:

We do not anticipate a great deal of use for characteristics on customer contacts. The primary purpose of catering for 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 premise, you could create a customer contact and reference the premise as a characteristic value. Then, when the information is extracted for the letter, the extract algorithm could extract fields from the premise to 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.

Customer Contact - Customer Contact Portal

Select Main Menu > Customer Information > Customer Contact and navigate to the Customer Contact Portal tab to view additional information associated with a Customer Contact .

General Information

Customer Contact ID, Customer Contact Info are displayed.

Depending on your implementations requirements, you may define additional zones to appear on this Portals

Refer to The Big Picture of Portals and Zones in the Oracle Utilities Application Framework Administration Guide for a description of portal and zone functionality.

Printing Letters

As described under Customer Contacts Are Used To Trigger Letters, you must create a customer contact whenever you want to send a letter to a customer. The contents of this section describe the technical implementation of letter production.

Contents

Letter Templates Control The Information Merged Onto Letters

BI Publisher Versus Documaker

Where Does The Address Come From?

Technical Implementation Of Online Letter Images

Technical Implementation Of Batch Letter Production

Reproducing The Letter Print Flat File

How To Reprint A Specific Letter

The Documaker Records

The Word Records

Letter Templates Control The Information Merged Onto Letters

Customer contacts that trigger letters reference a customer contact type that, in turn, references a letter template. The letter template controls the following:

- It contains an algorithm that is responsible for extracting the information merged onto your letters. Specifically, algorithms of this type create the "flat file records" that are passed to your letter print software. Algorithms of this type are called under the following scenarios:

- The background process that builds the flat file that's passed to your letter print software calls these algorithms to construct the "flat file records" for each letter.

- If your letter print software has the ability to construct a real-time image of a letter (in a PDF), you can plug-in an Online Letter Image algorithm on the Installation Record. This type of algorithm will call the letter's letter template's extract algorithm to extract the information that is merged onto the letter. Refer to Technical Implementation Of Online Letter Image for the details.

Refer to The Documaker Records for examples of the record layouts passed to the Documaker print software.

- It contains the ID of the background process that builds the flat file that's passed to your letter print software. The base package example of this process (known by the batch control ID of LTRPRT) simply calls each customer contact's letter template's extract algorithm to format the information placed onto the flat file.

BI Publisher Versus Documaker

Using BI Publisher as your external reporting tool to display an online letter image differs from using Documaker printing software as follows:

- An extract file is not required when using BI Publisher. The sample reports provided to use with these external report tools do not have to extract information from another object to merge into a letter.

- Generating letters in batch is not supported yet.

Fastpath:

Refer to Letter Print - BI Publisher Sample Welcome Letters - CI_LTRGN_ENG REPORT for more information.

Where Does The Address Come From?

The following points describes the source of a letter's address:

- For letters generated as a result of collection events, severance events, write-off events and overdue events, the address is extracted as follows:

- The respective Account - Person record is retrieved for the letter recipient (note, the account ID is retrieved from the related collection / severance / write-off / overdue process).

- If the person has a seasonal address effective on the business date, the letter's address is the respective seasonal address.

- If the address source is Mailing Premise on Account , the letter's address is the account's mailing premise.

- If the address source is Account Override , the letter's address is the override address on the respective Account - Person record.

- If the address source is Person , the letter's address is the person's mailing address .

- If the address source is not defined, the person's mailing address is used.

- If an address was not populated as a result of the above, the letter is not produced and a warning is issued by the background process responsible for creating the letter extract file.

- For all other types of letters, the address is extracted as follows:

- If the letter's person has a seasonal address effective on the business date, the letter's address is the respective seasonal address.

- If the letter's person has a mailing address , it is used.

- Otherwise, the system checks if the letter's person has at least one account where the person is the main customer and the account has at least one active service agreement. If so, the logic described above is executed for the first such account found.

- If an address was not populated as a result of the above, the letter is not produced and a warning is issued by the background process responsible for creating the letter extract file.

Technical Implementation Of Online Letter Images

Users can view an image of any letter that is sent to a customer if you set up the following:

- Plug-in an Online Letter Image construction algorithm on the Installation Record. Refer to C1-LT-DISP for an example of such an algorithm. Note, if your letter print software is not capable of producing a PDF containing an image of a letter, users will not be able to view images of letters.

- Plug-in the appropriate extract algorithm on each letter template. Algorithms of this type format the records that contain the customer information that is passed to your printing software.

When you plug-in these algorithms, a button appears on Customer Contact - Main for customer contacts whose customer contact type references a letter template. When a user clicks this button, the following takes place:

- The installation record's Online Letter Image construction algorithm is executed.

- This algorithm calls the customer contact's letter template's extract algorithm. This algorithm constructs the information that's merged onto the letter and returns it to the Online Letter Image algorithm. This algorithm, in turn, passes it to your letter print software.

- Your letter print software renders an image of the letter in a PDF and returns it to the Online Letter Image algorithm.

- And finally, the Online Letter Image algorithm displays the PDF in a separate Adobe session.

The system provides an algorithm that interacts with BI Publisher to render an online image of a letter. The following points describe what takes place when clicking Display Letter when these sample algorithms are used.

- The sample Online Field Order Image algorithm C1-ONLTR-RPT is executed.

- This algorithm calls the letter extract algorithm. The sample letter extract algorithm C1-LTREX-RPT is supplied for displaying letters via BI Publisher. This is not actually extracting data because when you use BI Publisher, the report itself is responsible for extracting and formatting the data. The base product algorithm supplied returns the appropriate report code to the OnlineLetter Image algorithm, which in turn returns the report code to the customer contact page.

- A user exit on the customer contact page invokes BI Publisher and displays the letter in a separate browser session.

Fastpath: Refer to Letter Print - BI Publisher Sample Welcome Letters - CI_LTRGN_ENG REPORT for more information.

Technical Implementation Of Batch Letter Production

The batch process that extracts letter information (known by the batch control ID of LTRPRT) reads all customer contact records in a given run number that are marked with its batch control ID. For each customer contact, it creates numerous records on a flat file. These records contain the customer information that is merged onto your letters.

The information that is placed on each record is controlled by the customer contact's letter template's extraction algorithm. Refer to Letter Templates Control The Information On Letters for more information.

The records on the flat file can be constructed in either the Documaker format (to be used by the Documaker software), or in MS Word's field delimited format. The format that's used is controlled by a parameter supplied to the LTRPRT background process.

- The Documaker flat file is created with multiple records of various record types for every customer contact record.

- The Word flat file is created with one record for every customer contact record processed. Each of the fields is delimited by a special character (e.g. "~").

Note:

Alternate print / routing methods. If you require different print formats, you must create new letter extract algorithms and plug them in on your letter template.

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.

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.

The Documaker Records

Note:

Alternate print / routing methods. This section describes the format of letter extract records that are constructed by base-package algorithms that are passed to the Documaker software (which actually produces the letters). If you require different print formats, you must create new letter extract algorithms and plug them in on your letter templates.

Alternate letter print flat file format. The algorithms responsible for creating the letter extract records can produce the output in either Documaker flat file format (described below) or in Word format (see The Word Records). The Documaker flat file is created with multiple records of various record types for every customer contact record processed. The Word flat file is created with one record for every customer contact record processed. These algorithms extract the same fields for both formats. However, the Word flat file has all fields for a letter compressed into one record; where each field is delimited by a tilde ("~"). You control which format is used by the parameters you supply to the respective background processes that call these algorithms. For Documaker format, set FIELD-DELIM-SW=N and CNTL-REC-SW=Y. For Word format, set FIELD-DELIM-SW=Y and CNTL-REC-SW=N.

Numerous types of records are interfaced to the Documaker software. However, they all share a common structure:

- The first 4 bytes are called the Printer Key. This field is a record type used by the Documaker letter template.

- The next 26 bytes are called the Sort Key. This field is used to ensure the various records used to construct a printed letter appear in the correct order in the interface file.

- The next 12 bytes are called the Mailing Key.

- The next 3 bytes are a filler that is available for future use.

- The remaining bytes contain the Letter Information that appears on the printed letter. The type of information differs for each type of record.

The topics in this section describe each component.

Contents

Printer Keys (Record Types)

Sort Key

Mailing Key

Letter Information

Printer Keys (Record Types)

The following table defines each printer key (i.e., record type) on the letter extract flat file.

Record Type

Description

Notes

0010

Global extract information

Required. 1 per flat file.

1000

Letter record

Required. 1 per letter.

1100

Mailing Information

Required. 1 per letter.

Note

Record types 1200 through 1600 only exist if the letter was triggered as a result of a collection event, a severance event, a write-off event, a workflow event or an overdue process event, respectively. These record types are mutually exclusive and it is possible for none to exist (meaning that the letter was triggered by a user-created customer contact and therefore has no extract merge information).

1200

Collection Process/Event

Optional. 0 or 1 record will exist - see Note above.

1300

Severance Process/Event

Optional. 0 or 1 record will exist - see Note above.

1400

Write-off Process/Event

Optional. 0 or 1 record will exist - see Note above.

1500

Workflow Process/Event

Optional. 0 or 1 record will exist - see Note above.

1600

Overdue Process/Event

Optional. 0 or 1 record will exist - see Note above.

9990

End of Letter record

Required. 1 per letter (dummy).

Sort Key

The letter print records need to be sorted in the right sequence in order for Documaker to process them. The following is a description of the portion of each record that is responsible for performing this task.

The following table defines the structure of the sort key that appears on each letter print record. Please note that different components are filled in for each printer key.

Field Name

Format

Source/Value/Description

LTR_TMPL_CD

A12

CC_ID

A10

CC Record Group

A2

This field forces the letter's records into the correct order. Values:

10 - General Letter information

20 - Mailing information

30 - Credit and Collections information

40 - Workflow information

99 - End Letter

C&C Record Group

A2

This field forces the subordinate records into the correct order. Values:

10 - Collection Process/Event information

30 - Severance Process/Event information

40 - Write Off Process/Event information

50 - Overdue Process/Event information

Mailing Key

Mailing key contains the postal code.

Letter Information

The topics in this section describe the information that appears on each letter extract record type.

Contents

Global Information Record

Letter Record

Mailing Information Record

Collection Process / Event Record

Severance Process / Event Record

Write Off Process / Event Record

Workflow Process / Event Record

Overdue Process / Event Record

End of Letter Record

Definition of Address Subrecord

Global Information Record

This is a "header" record that contains information about the extract run as a whole.

Note:

Please be aware that if you do not sort your extract file by CIS Sort Key after it is produced, this record will physically be the last record on the extract file. Also note that this record will only be produced by the various letter extract processes if you supply the appropriate parameter value (CNTL-REC-SW=Y). Refer to Extract Processes for more information about the letter extract programs.

Field Name

Format

Source/Value/Description

Print Key

A4

"0010"

CIS Sort Key

A26

This is blank for this record type only.

CIS Mailing Key

A15

This is blank for this record type only.

BATCH_CD

A8

CI_BATCH_INST / The CIS Batch Process that called the Letter Extract COBOL routine

BATCH_NBR

N10

CI_BATCH_INST / A sequence number for serial instances of a Batch Process over time

BATCH_RERUN_NBR

N10

CI_BATCH_INST / The number of times a particular batch has been re-run since its initial run

Letter Count [Artificial]

N10

Total number of letters in this extract

Date/Time [Artificial]

A26

System time of extraction.

CC Id Start [Artificial]

A10

The lowest CC ID in a particular thread in the extract

CC Id End [Artificial]

A10

The highest CC ID in a particular thread in the extract

BATCH_THREAD_NBR

N10

CI_BATCH_THD / Identifies a thread distinctly within a group of threads

Thread Count [Artificial]

N10

Total number of threads in the extract run

Letter Record

One record is produced for every letter to be printed.

Field Name

Format

Source/Value/Description

Print Key

A4

"1000"

CIS Sort Key

A26

CIS Mailing Key

A15

CC_ID

A10

CI_CC / System-assigned identifier for a Customer Contact.

PER_ID

A10

CI_CC / System-assigned identifier for the Person who will receive the letter.

CC_DT

D10

CI_CC / The date of the Customer Contact.

CC_TM

T15

CI_CC / The time of the Customer Contact.

CC_CL_CD

A4

CI_CC / The category of contact.

CC_TYPE_CD

A12

CI_CC / The type of contact within the category.

LTR_TMPL_CD

A12

CI_CC / The template of the letter.

LTR_DT

D10

From the current system date/time - the date to print on the letter.

Mailing Information Record

One record is produced for every letter to be printed.

Field Name

Format

Source/Value/Description

Print Key

A4

"1100"

CIS Sort Key

A26

CIS Mailing Key

A15

ENTITY_NAME1

A64

If an override mailing name has been specified on the CI_PER row, this field contains the first line of the person's override mailing name (OVRD_MAIL_NAME1). Otherwise, the person's primary name is used (ENTITY_NAME).

ENTITY_NAME2

A64

If an override mailing name has been specified on the CI_PER row, this field contains the 2 nd line of the person's override mailing name (OVRD_MAIL_NAME2). Otherwise, this field is blank.

ENTITY_NAME3

A64

If an override mailing name has been specified on the CI_PER row, this field contains the 3 rd line of the person's override mailing name (OVRD_MAIL_NAME3). Otherwise, this field is blank.

ADDRESS_SBR

A361

See below for the fields. Refer to Where Does The Address Come From? for the source of the address information.

Collection Process / Event Record

This record contains information about the collection process and event that triggered the letter. If the letter was not triggered by a collection event, this record will not be created. So, there will be at most one collection event record for a letter.

Field Name

Format

Source/Value/Description

Print Key

A4

"1200"

CIS Sort Key

A26

CIS Mailing Key

A15

COLL_PROC_ID

A10

CI_COLL_EVT_CC / Collection process that triggered the letter.

EVT_SEQ

N3

CI_COLL_EVT_CC / Collection event that triggered the letter.

ACCT_ID

N10

CI_COLL_PROC / Account being collected on.

COLL_CL_CNTL_CD

C20

CI_COLL_PROC / Collection class control of the collection process.

DEBT_CL_CD

C4

CI_COLL_CL_CNTL / Class of debt being collected.

DESCR

C30

CI_DEBT_CL.DESCR / Description of the debt class.

CRE_DTTM

DT26

CI_COLL_PROC / Date/time that the collection process was created.

COLL_ARS_DT

D10

CI_COLL_PROC / Debt date for which this collection process was created.

AMOUNT_AMT

N13.2

Amount still owed for the collection process. This is the amount the customer must pay to have the collection process canceled. This is calculated by the same routine used by the Collection Process Monitor.

CURRENCY_CD

C3

CI_COLL_PROC / Currency for the amount.

Severance Process / Event Record

This record contains information about the severance process and event that triggered the letter. If the letter was not triggered by a severance event, this record will not be created. So, there will be at most one severance event record for a letter.

Field Name

Format

Source/Value/Description

Print Key

A4

"1300"

CIS Sort Key

A26

CIS Mailing Key

A15

SEV_PROC_ID

A10

CI_SEV_EVT_CC / Severance process that triggered the letter.

EVT_SEQ

N3

CI_SEV_EVT_CC / Severance event that triggered the letter.

SA_ID

A10

CI_SEV_PROC / SA being severed.

ACCT_ID

A10

CI_SA / SA's account.

MULTI_PREM_SW

A1

Y or N. This is set to "Y" if the SA is currently linked to multiple premises through its SA/SP, otherwise to "N".

BUSINESS_UNIT

A5

CI_SA / Business unit of the SA.

SA_TYPE_CD

A4

CI_SA / Type of SA.

SA_TYPE_DESCR

A30

CI_SA_TYPE.DESCR / Description of the SA type.

CRE_DTTM

DT26

CI_SEV_PROC / Date/time that the collection process was created.

SEV_ARS_DT

D10

CI_SEV_PROC / Debt date for which this severance process was created.

AMOUNT_AMT

N13.2

Amount still owed for the severance process. This is amount the customer must pay to have the severance process canceled. This is calculated by the same routine used by the Severance Process Monitor.

CURRENCY_CD

C3

CI_SEV_PROC / Currency for the amount.

ADDRESS_SBR

Address Subrecord.

CI_PREM / The address of the characteristic premise for the SA. This is assumed to be the premise that will be cut.

Write Off Process / Event Record

This record contains information about the write off process and event that triggered the letter. If the letter was not triggered by a write-off event, this record will not be created. So, there will be at most one write-off event record for a letter.

Field Name

Format

Source/Value/Description

Print Key

A4

"1400"

CIS Sort Key

A26

CIS Mailing Key

A15

WO_PROC_ID

A10

CI_WO_EVT_CC / Write Off Event that triggered the letter.

EVT_SEQ

N3

CI_WO_EVT_CC / Write Off Event that triggered the letter.

ACCT_ID

N10

CI_WO_PROC / Account whose SAs are being written off.

WO_CNTL_CD

C20

CI_WO_PROC / WO control code of the write off process.

WO_DEBT_CL_CD

C4

CI_WO_CNTL / Write Off debt class of the SAs being written off.

DESCR

C30

CI_WO_DEBT_CL.DESCR / Description of the write off debt class.

CRE_DTTM

DT26

CI_WO_PROC / Date/time that the write off process was created.

WO_BALANCE

N13.2

Amount still owed on the SAs linked to the write off process. This is calculated by the same routine that creates an agency referral, (Determine Referral Amount routine (CIPLWRAN)).

CURRENCY_CD

C3

CI_COLL_PROC / Currency for the amount.

Workflow Process / Event Record

This record contains information about the workflow process and event that triggered the letter. If the letter was not triggered by a workflow event, this record will not be created. So, there will be at most one workflow event record for a letter.

Field Name

Format

Source/Value/Description

Print Key

A4

"1500"

CIS Sort Key

A26

CIS Mailing Key

A15

WF_PROC_ID

A10

CI_WF_EVT / Workflow Event whose event context is the customer contact being processed.

EVT_SEQ

N3

CI_WF_EVT / / Workflow Event whose event context is the customer contact being processed.

WF_PP_CD

A12

CI_WF_PROC / Workflow process profile of the workflow process.

NT_UP_XTYPE_CD

A30

CI_WF_PROC / Notification Upload Type that caused the creation of this process.

DESCR50

A50

CI_NT_UP_XTYPE/ Description of the notification upload type.

CRE_DTTM

DT26

CI_WF_PROC / Date/time that the workflow process was created.

CTXT_VAL_ACCT

A50

CI_WF_PROC_CTXT /Context value where the value of the context flag is ACCT.

CTXT_VAL_MSA

A50

CI_WF_PROC_CTXT /Context value where the value of the context flag is MSA.

CTXT_VAL_SPR

A50

CI_WF_PROC_CTXT /CTXT_VAL where the value of the context flag is SPR.

SPR_DESCR50

A50

CI_SPR/DESCR50.

CTXT_VAL_SP

A50

CI_WF_PROC_CTXT /CTXT_VAL where the value of the context flag is SP.

CTXT_VAL_XACC

A50

CI_WF_PROC_CTXT /CTXT_VAL where the value of the context flag is XACC.

Overdue Process / Event Record

This record contains information about the overdue process and event that triggered the letter. If the letter was not triggered by an overdue event, this record will not be created. So, there will be at most one overdue event record for a letter.

Refer to the sample overdue process event extract algorithm for information about the fields below whose source is Extract Algorithm .

Field Name

Format

Source/Value/Description

Print Key

A4

"1600"

CIS Sort Key

A26

CIS Mailing Key

A15

OD_PROC_ID

A10

CI_OD_PROC_LOG / Overdue process that triggered the letter.

OD_EVT_SEQ

N3

CI_OD_PROC_LOG / Overdue event that triggered the letter.

ACCT_ID

N10

CI_OD_PROC / Account being collected on.

OD_PROC_TEMPL_CD

A12

CI_OD_PROC / Overdue process template.

DESCR

C30

CI_OD_PROC_TEMPL / Description of the overdue process template.

CRE_DTTM

DT26

CI_OD_PROC / Date/time that the overdue process was created.

Original Unpaid Amt

N13.2

Extract Algorithm / Amount owed on all objects being collected by the overdue process when the overdue process was created.

Unpaid Amt

N13.2

Extract Algorithm / Amount still owed on all objected being collected by the overdue process.

CURRENCY_CD

C3

CI_OD_PROC / Currency for the amount.

Info String 1

Extract Algorithm / Info about object 1 being collected

Info String 2

Extract Algorithm / Info about object 2 being collected

Info String 3

Extract Algorithm / Info about object 3 being collected

Info String 4

Extract Algorithm / Info about object 4 being collected

Info String 5

Extract Algorithm / Info about object 5 being collected

End of Letter Record

Field Name

Format

Source/Value/Description

Print Key

A4

"9990"

CIS Sort Key

A26

CIS Mailing Key

A15

Definition of Address Subrecord

Used in mailing address and service address, total length = 361 bytes

Field Name

Format

Description

COUNTRY

A3

ADDRESS1

A64

ADDRESS2

A64

ADDRESS3

A64

ADDRESS4

A64

CITY

A30

NUM1

A6

NUM2

A4

HOUSE_TYPE

A2

COUNTY

A30

STATE

A6

POSTAL

A12

GEO_CODE

A11

IN_CITY_LIMIT

A1

The Word Records

Note:

Alternate print / routing methods. This section describes the format of letter extract records that are constructed by base-package algorithms that are passed to Word, the software that actually produces the letters. If you require different print formats, you must create new letter extract algorithms and plug them in on your letter templates.

Alternate letter print flat file format. The algorithms responsible for creating the letter extract records can produce the output in either Documaker flat file format (see The Documaker Records) or in Word format (see below). The Documaker flat file is created with multiple records of various record types for every customer contact record processed. The Word flat file is created with one record for every customer contact record processed. These algorithms extract the same fields for both formats. However, the Word flat file has all fields for a letter compressed into one record; where each field is delimited by a tilde ("~"). You control which format is used by the parameters you supply to the respective background processes that call these algorithms. For Documaker format, set FIELD-DELIM-SW=N and CNTL-REC-SW=Y. For Word format, set FIELD-DELIM-SW=Y and CNTL-REC-SW=N.

One record is produced for every letter to be printed. The fields on each record are delimited with a tilde (~). The following table shows the format of the fields:

Field Name

Maximum Size

Source/Value/Description

POSTAL

A12

ENTITY_NAME1

A64

CI_PER_NAME1 / Primary name of the person on the Customer Contact record.

ENTITY_NAME2

A64

CI_PER_NAME2 / Primary name of the person on the Customer Contact record.

ENTITY_NAME3

A64

CI_PER_NAME3 / Primary name of the person on the Customer Contact record.

COUNTRY

A3

The next group of fields (COUNTRY through IN_CITY_LIMIT) contain the letter's address.

ADDRESS1

A64

ADDRESS2

A64

ADDRESS3

A64

ADDRESS4

A64

CITY

A30

NUM1

A6

NUM2

A4

HOUSE_TYPE

A2

COUNTY

A30

STATE

A6

POSTAL

A12

GEO_CODE

A11

IN_CITY_LIMIT

A1

CC_ID

A10

CI_CC / System-assigned identifier for a Customer Contact.

PER_ID

A10

CI_CC / System-assigned identifier for the Person who will receive the letter.

CC_DT

See Note

CI_CC / The date of the Customer Contact formatted as <month> DD, YYYY.

CC_TM

T15

CI_CC / The time of the Customer Contact.

CC_CL_CD

A4

CI_CC / The category of contact.

CC_TYPE_CD

A12

CI_CC / The type of contact within the category.

LTR_TMPL_CD

A12

CI_CC / The template of the letter.

LTR_DT

See Note

From the current system date/time - the date to print on the letter formatted as <month> DD, YYYY.

Certain types of letters may have additional fields. The topics that follow describe the additional fields that suffix the above fields:

Contents

Additional Fields For A Collection Process / Event Letter

Additional Fields For A Severance Process / Event Letter

Additional Fields For A Write Off Process / Event Letter

Additional Fields For A Workflow Process / Event Letter

Additional Fields For An Overdue Process / Event Letter

Additional Fields For A Collection Process / Event Letter

The following table describes additional fields that suffix letter extract records associated with a collection event.

Field Name

Maximum Size

Source/Value/Description

COLL_PROC_ID

A10

CI_COLL_EVT_CC / Collection process that triggered the letter.

EVT_SEQ

N3

CI_COLL_EVT_CC / Collection event that triggered the letter.

ACCT_ID

N10

CI_COLL_PROC / Account being collected on.

COLL_CL_CNTL_CD

C20

CI_COLL_PROC / Collection class control of the collection process.

DEBT_CL_CD

C4

CI_COLL_CL_CNTL / Class of debt being collected.

DESCR

C30

CI_DEBT_CL.DESCR / Description of the debt class.

CRE_DTTM

DT26

CI_COLL_PROC / Date/time that the collection process was created.

COLL_ARS_DT

See Note

CI_COLL_PROC / Debt date for which this collection process was created formatted as <month> DD, YYYY.

AMOUNT_AMT

N13.2

Amount still owed for the collection process. This is the amount the customer must pay to have the collection process canceled. This is calculated by the same routine used by the Collection Process Monitor.

CURRENCY_CD

C3

CI_COLL_PROC / Currency for the amount.

Additional Fields For A Severance Process / Event Letter

The following table describes additional fields that suffix letter extract records associated with a severance event.

Field Name

Format

Source/Value/Description

SEV_PROC_ID

A10

CI_SEV_EVT_CC / Severance process that triggered the letter.

EVT_SEQ

N3

CI_SEV_EVT_CC / Severance event that triggered the letter.

SA_ID

A10

CI_SEV_PROC / SA being severed.

ACCT_ID

A10

CI_SA / SA's account.

MULTI_PREM_SW

A1

Y or N. This is set to "Y" if the SA is currently linked to multiple premises through its SA/SP, otherwise to "N".

BUSINESS_UNIT

A5

CI_SA / Business unit of the SA.

SA_TYPE_CD

A4

CI_SA / Type of SA.

SA_TYPE_DESCR

A30

CI_SA_TYPE.DESCR / Description of the SA type.

CRE_DTTM

DT26

CI_SEV_PROC / Date/time that the collection process was created.

SEV_ARS_DT

See Note

CI_SEV_PROC / Debt date for which this severance process was created formatted as <month> DD, YYYY.

AMOUNT_AMT

N13.2

Amount still owed for the severance process. This is amount the customer must pay to have the severance process canceled. This is calculated by the same routine used by the Severance Process Monitor.

CURRENCY_CD

C3

CI_SEV_PROC / Currency for the amount.

ADDRESS_SBR

Address Subrecord.

CI_PREM / The address of the characteristic premise for the SA. This is assumed to be the premise that will be cut.

Additional Fields For A Write Off Process / Event Letter

The following table describes additional fields that suffix letter extract records associated with a write-off event.

Field Name

Format

Source/Value/Description

WO_PROC_ID

A10

CI_WO_EVT_CC / Write Off Event that triggered the letter.

EVT_SEQ

N3

CI_WO_EVT_CC / Write Off Event that triggered the letter.

ACCT_ID

N10

CI_WO_PROC / Account whose SAs are being written off.

WO_CNTL_CD

C20

CI_WO_PROC / WO control code of the write off process.

WO_DEBT_CL_CD

C4

CI_WO_CNTL / Write Off debt class of the SAs being written off.

DESCR

C30

CI_WO_DEBT_CL.DESCR / Description of the write off debt class.

CRE_DTTM

DT26

CI_WO_PROC / Date/time that the write off process was created.

WO_BALANCE

N13.2

Amount still owed on the SAs linked to the write off process. This is calculated by the same routine that creates an agency referral, (Determine Referral Amount routine (CIPLWRAN)).

CURRENCY_CD

C3

CI_COLL_PROC / Currency for the amount.

Additional Fields For A Workflow Process / Event Letter

The following table describes additional fields that suffix letter extract records associated with a workflow event.

Field Name

Format

Source/Value/Description

WF_PROC_ID

A10

CI_WF_EVT / Workflow Event whose event context is the customer contact being processed.

EVT_SEQ

N3

CI_WF_EVT / / Workflow Event whose event context is the customer contact being processed.

WF_PP_CD

A12

CI_WF_PROC / Workflow process profile of the workflow process.

NT_UP_XTYPE_CD

A30

CI_WF_PROC / Notification Upload Type that caused the creation of this process.

DESCR50

A50

CI_NT_UP_XTYPE/ Description of the notification upload type.

CRE_DTTM

DT26

CI_WF_PROC / Date/time that the workflow process was created.

CTXT_VAL_ACCT

A50

CI_WF_PROC_CTXT /Context value where the value of the context flag is ACCT.

CTXT_VAL_MSA

A50

CI_WF_PROC_CTXT /Context value where the value of the context flag is MSA.

CTXT_VAL_SPR

A50

CI_WF_PROC_CTXT /CTXT_VAL where the value of the context flag is SPR.

SPR_DESCR50

A50

CI_SPR/DESCR50.

CTXT_VAL_SP

A50

CI_WF_PROC_CTXT /CTXT_VAL where the value of the context flag is SP.

CTXT_VAL_XACC

A50

CI_WF_PROC_CTXT /CTXT_VAL where the value of the context flag is XACC.

Additional Fields For An Overdue Process / Event Letter

The following table describes additional fields that suffix letter extract records associated with an overdue event.

Field Name

Format

Source/Value/Description

OD_PROC_ID

A10

CI_OD_PROC_LOG / Overdue process that triggered the letter.

OD_EVT_SEQ

N3

CI_OD_PROC_LOG / Overdue event that triggered the letter.

ACCT_ID

N10

CI_OD_PROC / Account being collected on.

OD_PROC_TEMPL_CD

A12

CI_OD_PROC / Overdue process template.

DESCR

C30

CI_OD_PROC_TEMPL / Description of the overdue process template.

CRE_DTTM

See Note.

CI_OD_PROC / Date/time that the overdue process was created formatted as <month> DD, YYYY.

Original Unpaid Amt

N13.2

Extract Algorithm / Amount owed on all objects being collected by the overdue process when the overdue process was created.

Unpaid Amt

N13.2

Extract Algorithm / Amount still owed on all objected being collected by the overdue process.

CURRENCY_CD

C3

CI_OD_PROC / Currency for the amount.

Info String 1

Extract Algorithm / Info about object 1 being collected

Info String 2

Extract Algorithm / Info about object 2 being collected

Info String 3

Extract Algorithm / Info about object 3 being collected

Info String 4

Extract Algorithm / Info about object 4 being collected

Info String 5

Extract Algorithm / Info about object 5 being collected

Maintaining Declarations

The declaration page allows you to define a declaration percentage for a combination of account, premise, service type, declaration type and date range. The declaration may be used by algorithms to adjust certain calculations in the system. For example you may give certain customers a reduced VAT rate. The declaration is used to indicate the reduced rate for the qualifying customer.

Open Customer Information, Declaration to add or update a declaration.

Note:

Applicable for UK market. This page is intended for the United Kingdom market. Other markets may disregard this transaction.

Description of Page

The Declaration Info is a concatenation of important information about the declaration record. The Declaration ID is a system-assigned random number that uniquely identifies this record.

Use Account ID to indicate the account for this declaration.

Use Premise ID to indicate the premise for this declaration.

The Service Type controls the service agreements covered by this declaration. All service agreements for this account and premise whose service point is for this service type are covered.

Use the Declaration Type to indicate the type of declaration. The system includes the declaration types CCL Relief and Reduced Rate VAT .

Note:

The values for this field are customizable using the Lookup table. This field name is DCL_TYPE_FLG.

Enter the Start Date and End Date to indicate the effective period of this declaration. The start date defaults to the current date.

Enter the Declaration Percentage.

If this declaration is related to an external document, indicate the Document Reference.

This bottom of this page contains a tree that shows information about all the declarations linked to this 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.

Service Tasks

The topics in this section describes service tasks.

Contents

The Big Picture of Service Tasks

Searching and Viewing Service Tasks

The Big Picture of Service Tasks

Service tasks are records that can be used to perform a variety of tasks. Examples include:

- Task-related records performed by users of other Oracle Utilities applications, such as Oracle Utilities Customer Self Service.

- Task-related records performed by Oracle Utilities Customer Care and Billing to manage specific processing, such as net energy metering true-ups, or prepaid billing to create bill segments for smart meter prepaid service agreements.

For additional information about Service Tasks, see Defining Service Tasks Options

Searching and Viewing Service Tasks

Use this procedure to search for and view service tasks using the Service Task Query portal.

1. Select Main Menu > Customer Information > Service Task Search .

2. Enter your search criteria.
Base package search options include customer name, external ID and service task ID.

Self-service task search criteria include service task type.

3. Click Refresh.

4. In the search results list, click the link for the service task you want to view or edit. The selected service task opens in the Service Task portal.

Self-Service Tasks

The topics in this section describes Self-service tasks.

Contents

The Big Picture of Self-Service Tasks

About Self-Service Task Types

The Big Picture of Self-Service Tasks

Self-service tasks are records that hold information regarding self-service operations performed by users in a customer self-service integration.

Examples of self-service tasks include:

- One time payments

- Account verification

- Start/Stop requests

Searching and Viewing Self-Service Tasks

Use this procedure to search for and view self-service tasks using the Self-Service Task Search portal.

1. Select Main Menu > Self-Service > Self-Service Task Search .

2. Enter your search criteria.
Base package search options include customer name, self-service email address, self-service user ID, and service task ID.

Self-service task search criteria include:

- Service task type (except when using the service task ID).

3. Click Refresh.

4. In the search results list, click the link for the service task you want to view or edit (if allowable). The selected self-service task opens in the Self-Service Task portal.

About Self-Service Task Types

The main attribute used to define a self-service task is a self-service task type. The self-service task type defines properties common to specific types of self-service tasks. Self-service task types can be defined by the following attributes:

- Service Task Type: the name of the task type.

- Service Task Type Business Object: the business object that defines the behavior of the service task type.

- Service Task Business Object: the business object instantiated when self-service tasks of this type are created.

- Service Task Class: the category used to define service task types. The default value for a self-service task type is “Self-Service”.

- Other data based on the specific type of self-service task, such as exception handling for a self-service meter read task type, or alert information for a budget task type.

Defining Self-Service Task Types

Use this procedure to define self-service task types.

To maintain existing self-service task types, select Main Menu > Self-Service > Self-Service Task Type , then use standard actions to edit, duplicate, activate / deactivate, or delete a service task type.

1. Select Main Menu > Self-Service > Self-Service Task Type+ .
Note: If your system supports more than one self-service task type business object, you will be prompted to select a business object for this self-service task type.

2. Enter a name and a meaningful description for the self-service task type.

3. Select the related transaction object for a service task of this type.

4. Select the service task class applicable to service tasks of this type. A self- service tasks types will have a default class of “Self-Service”.

5. Enter a detailed description for the service task type

6. Complete the remaining fields and sections (if applicable).

7. Click Save.

This self-service task type can now be used to perform a specific task (such as add a meter read, add a payment, start /stop service, and so on). An inbound request for a specific process, from a self-service application such as Oracle Utilities Customer Self Service, will create a self-service task based on the applicable self-service task type. The self-service task will process the request using the common attributes defined on its self-service task type.

Meter Management

In addition to meters, the system also supports the definition and installation of non-metered devices. We use the term item to reference these non-metered devices. In this section, we describe how you set up and install both types of devices at service points.

Contents

Background Topics

Gaining Access To The V Using Meter/Item Search

Maintaining Meters

Maintaining Meter Configurations

Maintaining Items

Installing / Removing A Meter

Installing / Removing An Item

Testing A Device

Device Test Selection

Meter Replicator

Item Replicator

Usage Requests

Background Topics

The topics in this section provide background information about a variety of meter and item related issues.

Contents

Meters versus Items versus Equipment

Meters & The V

Items & The V

Meters versus Items versus Equipment

Fastpath:

Refer to The Big Picture of Meters, Items and Equipment for the details.

Meters & The V

Note:

The "V". The "V" is the nickname given to the demographic and geographic information that forms the heart of your CIS system. This section assumes you are familiar with the "V". If you aren't, refer to Understanding The "V".

Over time, a meter may be installed at many service points and a service point may have many meters installed at it (but at any instant in time, only one meter may be installed at a service point).

The meter installed at a service point measures the consumption used at a service point. It's quite possible for a single meter's consumption to be billed on multiple service agreements because its service point may be linked to multiple service agreements. This is necessary, for example, when water consumption is used to bill both water and sewage service agreements. Another example might be when electric consumption is used to bill both transportation and energy service agreements.

The following illustration will help you visualize the relationship between a meter and the "V".

Items & The V

Note:

The "V". The "V" is the nickname given to the demographic and geographic information that forms the heart of your CIS system. This section assumes you are familiar with the "V". If you aren't, refer to Understanding The "V".

If there are charges in your rates based on the number and type of items installed at a service point (e.g., lamp charges), you must use either of the following techniques:

- If the item is badged (i.e., uniquely identified), you would set up an item and link it to an item - based service point. An item-based service point may have zero or one item installed at any instant in time. Over time, an item-based service point may have many badged items installed and removed. Refer to Installing / Removing An Item for more information.

- If the item does not have a unique identifier, you do NOT have to set up phony items for it. Rather, you can use the system's multi-item functionality and simply define the number of each TYPE of item that is installed at a service point. Refer to Service Points With Multiple Items for an illustration of such a service point.

Note:

Another way to think of an item is something that does NOT measure consumption, but impacts billing in some way. Examples include streetlights, light poles, and security cameras.

Warning:

The above example illustrated a service point that has a single item installed at it at any one point in time. We use the term " badged item" to reference the thing that can be installed at such a service point (because it has a unique ID that appears on a badge). In addition to badged items, you can install an unlimited number of non-badged items at any type of service point. Refer to Service Points (SPs) for more information.

Gaining Access To The V Using Meter/Item Search

The topics in this section describe the Meter/Item Search page.

Meter/Item Search - Main

Note:

Definition of a "device". In the following discussion, we refer to meters and items interchangeably using the term "device".

This page contains functionality that helps you:

- Find where a device is installed and who pays for the device.

- Find the devices associated with a person, account, premise or service point.

- Navigate to pages that contain information related to a device, its service point, its account(s) and its service agreement(s). For example,

- After finding the meters related to account 1929210192 , you could navigate to the page where a meter read is added for one of the meters.

- After finding the account that pays for lamp BY10291 , you could navigate to Control Central to view summary information about the customer.

- Etc.

Fastpath:

For more information about the relationships between devices and your customers and premises, refer to Understanding The "V" , Meters and The V, and Items and The V.

To look for a device or the customer associated with a device, open Meter, Meter/Item Search.

Description of Page

The top half of the page is where you enter criteria used to search for a device.

In Search Type, you define the type of devices that you want to search for. You have the following options:

All This value means that you want to search for meters AND items. You'd use this, for example, if you wanted to search for all meters and items linked to a given customer. This is the default value.

Meter This value means that you want to search for meters (and exclude items).

Item This value means that you want to search for items (and exclude meters).

After defining the appropriate Search Type, you then define how to search for the device. The following search methods are available:

Note:

Closed service agreements are ignored. When the system displays a device's Account and Service Agreement Information, it ignores closed service agreements. This means that if a device is installed at a service point that is only linked to closed service agreements, no Account or Service Agreement Information will be displayed for the device.

Search Method

Description

Person Name

Use this field to search for the devices associated with an account using a person's name. The person may be the main customer on the account or a third party related to the account.

You can enter all or part of the person's name. If the person is a business, enter all or part of the business name. If the person is a human, you must enter the name in the format Last,First (e.g., Walton,Richard ).

The name search is not case sensitive.

This search method cannot be combined with other search methods.

Please be aware that only persons whose accounts have devices installed will appear in the search results at the bottom of the page.

Also note, ALL devices that were ever installed at a person's account(s) are displayed, even if the device has been subsequently replaced.

Account ID

Use this field to search for the devices associated with a given account ID.

You can enter all or part of the account ID.

This search method cannot be combined with other search methods.

Please be aware that only accounts that have devices installed will appear in the search results at the bottom of the page.

Also note, ALL devices that were ever installed at an account are displayed, even if the device has been subsequently replaced.

SA ID

Use this field to search for the devices associated with a given service agreement ID.

You can enter all or part of the SA ID.

This search method cannot be combined with other search methods.

Please be aware that only service agreements that have devices installed will appear in the search results at the bottom of the page.

Also note, ALL devices that were ever installed a service agreement are displayed, even if the device has been subsequently replaced.

SP ID

Use this field to search for the devices associated with a given service point ID.

You can enter all or part of the SP ID.

This search method cannot be combined with other search methods.

Please be aware that only service points that have devices installed will appear in the search results at the bottom of the page.

Also note, ALL devices that were ever installed a service point are displayed, even if the device has been subsequently replaced.

Premise ID

Use this field to search for the devices associated with a given premise ID.

You can enter all or part of the premise ID.

This search method cannot be combined with other search methods.

Please be aware that only premises that have devices installed will appear in the search results at the bottom of the page.

Also note, ALL devices that were ever installed at a premise are displayed, even if the device has been subsequently replaced.

Address

Use this field to search for the devices installed at a premise 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.

Address may be combined with the City and Postal search methods. Otherwise, this search method cannot be combined with other search methods.

Please be aware that only premises that have devices installed will appear in the search results at the bottom of the page.

Also note, ALL devices that were ever installed at the premise are displayed, even if the device has been subsequently replaced.

City

Use this field to search for the devices installed at a premise 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 and Address or Postal code, otherwise the resultant list can be too large to deal with. Otherwise, this search method cannot be combined with other search methods.

Please be aware that only premises that have devices installed will appear in the search results at the bottom of the page.

Also note, ALL devices that were ever installed at the premise are displayed, even if the device has been subsequently replaced.

Postal

Use this field to search for the devices installed at a premise using a postal code associated with a service address.

You can enter all or part of the postal code.

The postal code search is case sensitive.

We strongly recommend qualifying a Postal search with and Address or City, otherwise the resultant list can be too large to deal with. Otherwise, this search method cannot be combined with other search methods.

Please be aware that only premises that have devices installed will appear in the search results at the bottom of the page.

Also note, ALL devices that were ever installed at the premise are displayed, even if the device has been subsequently replaced.

Badge Number

Use this field to find where a device is installed and who pays for the device by entering the device's badge number.

You can enter all or part of the device's badge number.

This search option is case sensitive.

This search method cannot be combined with other search methods.

Also note,

- For meters, only customers associated with the latest configuration of the meter are displayed.

- For items, all customers associated with the item are displayed.

SP Geo Type / Value

Use this field to search for the devices installed at a service point by using one of the service point's Geo Types / Values. Refer to Service Point - Geographic Information for more information about Geo Types / Values.

If you use this method, you must define a SP Geo Type, however you can enter all or part of the Geo Value.

This search option is case sensitive.

This search method cannot be combined with other search methods.

Please be aware that only service points that have devices installed will appear in the search results at the bottom of the page.

Also note, ALL devices that were ever installed at the service point are displayed, even if the device has been subsequently replaced.

Meter ID Type / Number

Use this field to find where a meter is installed and who pays for the meter by entering one of the meter's alternate ID's. Refer to Meter - Meter ID for more information about Meter ID Types / Numbers.

If you use this method, you must define a Meter ID Type, however you can enter all or part of the Number.

This search option is case sensitive.

This search method cannot be combined with other search methods.

Also note, only customers associated with the latest configuration of the meter are displayed.

The system shows the results of your search request in the grid at the bottom of the page. The following information appears in the grid:

Note:

Use the context menus to navigate elsewhere. Please be aware that the context menus that prefix each cell provide a simple means to navigate to pages related to the meters / service points / accounts / service agreements.

Meter / Item Information This contains a concatenation of important information about the device. This information includes (but is not necessarily limited to) the device's type, badge number, serial number, and status.

SP Information This contains a concatenation of important information about the service point at which the device is installed. This information includes (but is not necessarily limited to) the service point's type, service cycle, premise address, and premise type. If the meter has never been installed at a service point, this column will be blank.

Account Information This contains a concatenation of important information about the account who pays for the device. This information includes (but is not necessarily limited to) the name of the main customer linked to the account, the customer class, and account ID. If the meter has never been installed at a service point or the service point is not linked to a service agreement, this column will be blank.

SA Information This contains a concatenation of important information about the service agreement that is linked to the device. This information includes (but is not necessarily limited to) the division / SA type, start option, status, and effective period. If the meter has never been installed at a service point or the service point is not linked to a service agreement, this column will be blank.

Blank column This column contains a "go to" button that will transfer you to the SA / SP page where you can see details about this service point's relationship to the service agreement.

Geographic Value This column only appears if you have used the SP Geo Type/Value search option. It will contain the geographic value associated with the service point.

Meter ID Number This column only appears if you have used the Meter ID Type / Number search option. It will contain the meter ID number associated with the meter.

Maintaining Meters

Meter records contain information about your meters. The topics in this section describe the pages on which meter-related information is maintained.

After you have set up the core meter information, navigate to Maintaining Meter Configurations to define how the meter's registers are configured.

If you need to create several copies of a given meter and its configuration, navigate to Meter Replicator - Main Information.

Contents

Meter - Main Information

Meter - Meter ID

Meter - Characteristics

Meter - SP Installation History

Meter - Equipment

Meter - Location History

Meter - Meter Tree

Meter - Main Information

The Main page contains core meter information. Open this page using Meter, Meter.

Description of Page

The following meter information is displayed at the top of the page:

Meter Info The description of the meter type concatenated with the meter's badge number and status.

Meter ID This is a system-assigned random number that stays with a meter for life. This value only appears after the meter exists on the database.

Premise ID The unique identifier of the premise at which the meter is installed (or was last installed).

Note:

Who pays for service? Use the Premise Context Menu to navigate to Control Central to see information about the customer linked to the current/last service point at which the meter is/was installed.

Service Point Information about the service point at which the meter is installed (or was last installed).

Install Date The date the meter was installed at its last location.

Removal Date The date the meter was removed from its last location.

The remaining fields are maintained on the remainder of this page.

The Badge Number is the identifier stamped on the meter. This is NOT the manufacturer's serial number. Rather, it's the number on the badge that typically appears on the face of the meter. This number is what most operators use to identify the meter.

Note:

Duplicate Badge Numbers. If the meter's meter type allows duplicate badge numbers, multiple meters of a given meter type may have the same badge number. Otherwise, duplicate badge numbers are not allowed for a given meter type.

Indicate the Meter Type. This field is very important as it defines the type of service associated with this meter. It also defines characteristics common to all meters of a given type and the type of equipment that can be linked to the meter.

Use the Meter Status to indicate if the meter is Active , Ordered , or Retired .

Note:

The values for the meter status field are customizable using the Lookup table. This field name is MTR_STATUS_FLG.

Define the meter's Manufacturer and Model.

Enter the manufacturer's Serial Number.

Use Date Received to define the date on which the meter was received from the manufacturer.

Use Date Retired to define the date when the meter is retired from service. This field is gray when the meter status is Active or Ordered .

Use Retire Reason to define why the meter was retired from service. This field is gray when the meter status is Active or Ordered .

Use Comments to describe unusual characteristics of the meter.

The Meter Configuration scroll/grid combination contains an overview of the meter's configurations and each configuration's registers. This information is not modifiable on this page. To modify this information, use the Meter Configuration context menu to transfer to the Meter Configuration page. Refer to Meter Configuration Maintenance for a description of the fields in the scroll and grid.

Meter - Meter ID

A meter may have alternate ID's other than its badge number. If it does, each alternate form of ID is defined using the Meter, Meter, Meter ID page.

Description of Page

To modify a meter ID, simply move to a field and change its value. To add a new alternate form of identity, click + to insert a row, then fill in the information for each field. The following fields display:

Meter ID Type Indicate the type of meter ID.

Meter ID Number Indicate the alternate meter id.

Where Used

The data on this page is used by the meter read upload process to identify the meter configuration that is being read. Refer to Uploading Meter Reads for more information.

Meter - Characteristics

The characteristics page contains information that describes miscellaneous information about the meter. Use Meter, Meter, Characteristics to open this page.

Description of Page

Meter Info is a concatenation of the meter's meter type and badge number.

Meter ID is the system-assigned random number that stays with a meter for life. This value only appears after the item exists on the database.

To modify a characteristic, simply move to a field and change its value. To add a new characteristic, click the + button to insert a row, then fill in the information for each field. The following fields display:

Effective Date Indicate the date on which the characteristic value becomes effective. The meter's date received defaults.

Characteristic Type Indicate the type of characteristic.

Characteristic Value Indicate the value of the characteristic.

Note:

Default note. If the meter's meter type has required characteristics, the respective characteristic types will default in the above grid.

Meter - SP Installation History

The SP Installation History is an information-only page that shows the history of service points at which the meter has been installed. Use Meter, Meter, SP Installation History to open this page.

This page shows the history of the service points at which the meter has been installed. No fields on this page may be modified.

Meter - Equipment

The equipment page contains the equipment that is linked to the meter. Use Meter, Meter, Equipment to open this page. Refer to Equipment May Be Associated With Meters for more information.

Description of Page

To modify a piece of equipment, simply move to a field and change its value. To add a new piece of equipment, press + to insert a row, then fill in the information for each field. The following fields display:

Equipment ID Indicate the unique identifier of the equipment.

Note:

This is actually the unique ID of an item as an item must be set up for each piece of equipment that can be linked to a meter. Only items with an item type defined on the meter's meter type's equipment collection may be defined (in other words, the valid types of equipment are defined on the meter's meter type).

Badge Number This is a display-only field that contains the equipment's badge number.

Equipment Type This is a display-only field that contains a description of the equipment's item type.

Equipment Count This field should be 1 except when you are using an item to define a generic piece of equipment. If you use an item to define a generic piece of equipment, you can indicate the number of such generic pieces of equipment that are associated with this meter.

Install Date Define the date that the equipment was installed at the meter.

Removal Date Define the date that the equipment was removed from the meter.

Comment Enter a comment to explain anything unusual about the piece of equipment.

Meter - Location History

The meter location history page has two purposes:

- You can view the history of the service points and stock locations at which a meter has been located.

- You can change a meter's current stock location if it is not installed at a service point.

It's important to be aware that location history is only recorded when the meter's meter type indicates that its location is tracked. Refer to The Big Picture of Asset Inventory for further information.

Use Meter, Meter, Location History to open this page.

Description of Page

The rows in the grid show where the meter has been located over its lifetime. The following types of rows may be displayed:

- When a meter is installed at a service point, a stock location history record is created with a Location History Type of SP Install .

- Location Date/Time is the time of installation. This may not be modified.

- Location is the service point at which the meter is installed. This may not be modified.

- When a meter is removed from a service point, a stock location history record is created with a Location History Type of SP Removal .

- Location Date/Time is the time of removal. This may not be modified.

- Location is a stock location. This value is defaulted based on the service point's postal defaults . You may change this Location if the defaulted value is incorrect.

- When a new meter is added, you must create a location history record to define the stock location at which the meter is stored.

- Enter the Date/ Time the meter was received.

- The Location History Type is defaulted to Stock .

- Use Location to define the stock location where the item is being stored.

- If a meter is transferred from one stock location to another, you must create a location history record as described above.

To create a new location history record, click the + button to insert a row, then fill in the information for each field.

Note:

Location history may have gaps. A meter's Stock Location History Is Created Behind the Scenes and is only created if stock location is being tracked.

Meter - Meter Tree

The meter tree page contains high-level information about various objects linked to the meter. Use Meter, Meter, Meter Tree to open this page.

Description of Page

This page is dedicated to a tree that shows the various objects linked to the meter. 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.

Meter – Meter Portal

Select Main Menu > Meter > Meter and navigate to the Meter Portal tab to view additional information associated with a Meter.

General Information

Meter ID, Meter Info are displayed.

Depending on your implementations requirements, you may define additional zones to appear on this Portal.

Refer to The Big Picture of Portals and Zones in the Oracle Utilities Application Framework Administration Guide for a description of portal and zone functionality.

Maintaining Meter Configurations

A meter's registers are defined in respect of an effective-dated meter configuration. When you reconfigure a meter's registers, you add a new configuration with an effective date equal to the reconfiguration date. Whenever you add a configuration, you must specify how all of the registers look on the configuration date; you don't just specify those registers that have changed.

Every meter must have at least one configuration, otherwise the system doesn't know what it measures and meter reads cannot be specified for the meter. A meter without meter reads cannot be billed (or linked to a service agreement!).

A meter configuration has one or more registers. The number is dependent on how many things are measured. For example, if you have a meter that measures kilowatt-hours and kilovolt-amperes, its configuration will have two registers.

Fastpath:

For more information about meter configurations, refer to The Structure of a Meter.

Contents

Changing A Configuration

Meter Configuration Maintenance

Validating Register Constants

Changing A Configuration

Because meter configurations are effective-dated, you have to deal with the difference between correcting an incorrect configuration and introducing a new configuration.

- You correct a configuration if you entered some part of the information about the configuration in error (e.g. a five-digit register is recorded as having four digits).

- You introduce a new configuration when you reconfigure the meter. All of the existing information was accurate at the time it was entered, but now something about the meter's configuration has changed. The historical information is retained intact, and the new configuration has its own unique identity on the system.

You are allowed to correct an historical configuration, but be careful. You see, meter reads reference a configuration and its registers. If you change an historical register's unit of measure, you are changing the unit of measure of all of the meter reads associated with this register - past and future. This system allows you to do this, just be aware of what you're doing.

You cannot introduce a configuration while the meter is installed at a service point (i.e., the effective date of the configuration cannot overlap with the effective date period of any SP Installation History). Think about it, you can't reconfigure the meter while it's measuring consumption. To reconfigure a meter after it's been installed at a service point:

- Remove the meter from the service point using SP / Meter Installation. To do this, you'll be required to specify a meter read showing how the registers looked when the meter was removed (and you can do this from this page).

- Next, add a new meter configuration using Meter Configuration Maintenance effective on the reconfiguration date. Specify how the registers look after reconfiguration on the new configuration.

- If you need to reinstall the meter at the service point, return to SP / MeterInstallation and add a new installation. To do this, you'll be required to specify a meter read showing how the registers look at installation time (and you can do this from this page). As you know, the registers are typically reset at installation, but we haven't made this assumption in the system.

Note:

Field activities simplify life. Rather than remembering the steps necessary to perform a meter reconfiguration on an installed meter, you should have a field activity type set up with the three steps. If such an activity type exists, you simply create a field activity referencing this type and when you complete it, you can do the 3 steps all at once.

Meter Configuration Maintenance

All meters must have an initial configuration that should be effective as of the date the meter was received. If you reconfigure the meter in the future, you must add a new effective-dated configuration to reflect how the meter is configured.

Warning:

Do not attempt to maintain a meter configuration unless you are familiar with the concepts discussed in Changing A Configuration.

Contents

Meter Configuration - Main Information

Meter Configuration - Meter Configuration Tree

Meter Configuration - Main Information

Open Meter, Meter Configuration to maintain a meter's configuration.

Please be aware that the information maintained on meter configurations associated with interval meters is slightly different than that for regular meters. The topics in this section describe how this page behaves for both types of meters.

Contents

Regular (Non Interval) Meter Configuration Maintenance

Interval Meter Configuration Maintenance

Regular (Non Interval) Meter Configuration Maintenance

The following discussion describes how the Meter Configuration page behaves for regular (non interval) meters.

Note:

A meter is viewed as being an interval meter if its meter type indicates interval registers are allowed.

Description of Page

The following meter configuration information is displayed at the top of the page:

Meter Configuration The description of the meter type concatenated with the meter's badge number, the meter configuration effective date, the description of the meter configuration type and the number of registers.

Meter Configuration ID This is a system-generated unique identifier for the meter configuration. This value is assigned when the meter configuration is added to the database.

Meter ID The system-generated unique identifier for the meter.

Effective Date / Time Defines the date and time the configuration becomes effective.

Meter Configuration Type Controls the types of registers that may be defined on this meter configuration. When you select a meter configuration type, the system defaults these attributes in the register grid. Refer to Setting Up Meter Configuration Types for more information.

The Registers accordion contains information about the meter configuration's registers. To modify existing register information, click on the register's summary bar and then move to a field and change its value. To add a new register, click the + button in the accordion to insert a row then fill in the information for each field. The following fields display:

- Sequence defines the relative physical position of the register with respect to the other registers, if any.

- Use Unit of Measure (UOM) to define the unit of measure in which the register is calibrated.

- Use Time of Use (TOU)to define the time-of-use code, if any, that specifies a particular time of day during which the register measures consumption.

- Register Constant is used to derive billable consumption. Measured consumption is multiplied by this number to derive billable consumption.

- Use Consumptive/Subtractive to define how the system calculates consumption from the register's meter reads. For Subtractive registers, the system has to subtract the previous read from the current read. For Consumptive registers, the dial reading indicates how much was consumed and no subtraction is necessary.

- Most of your registers will be set to Subtractive unless you sell electricity. For most electric meters, kWh registers will be set to Subtractive , and KW meters will be set to Consumptive .

- Use How To Use to control how billing uses the consumption from the register. Use Additive if billing adds the register's consumption to other register's consumption (with the same UOM and TOU value). Use Subtractive if billing subtracts the register's consumption from other register's consumption (with the same UOM and TOU value). Use Peak if billing compares this register's consumption against other register's consumption (with the same UOM and TOU value) and uses the higher consumption value. Use Check if billing ignores the consumption associated with this register.

- Most of your registers will be set to Additive unless you sell electricity. On electric meters, kWh registers will be set to Additive , KW meters will be set to Peak .

- Use Digits Left/Right to define the number of digits to the left and right of decimal place. This information is used to validate meter readings to ensure they do not exceed the dial's capacity.

- Full Scale is typically only specified on demand meters (but can be specified on any type). It is downloaded to the meter reading devices so they can warn the reader if the resulting consumption is close to or exceeds the register's maximum capacity.

- Read Out Type defines how the readings are displayed on the register.

- Protocol defines how the register is read.

- Tolerance is typically only specified on demand meters (but can be specified on any type). It is downloaded to the meter reading devices so they can warn the reader if the resulting consumption is close to or exceeds the tolerance of the register.

- Channel ID is used to record an external id that may exist for the register.

- Register IDis the unique system-assigned identifier of the register. This value is allocated when the register is added to the database. Note, the adjacent context menu is disabled for non-interval registers.

Characteristics

The Characteristics collection on the Meter Configuration page contains information that describes miscellaneous information about the meter configuration.

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.

Interval Meter Configuration Maintenance

The following discussion describes how the Meter Configuration page behaves for interval meters.

Note:

A meter is viewed as being an interval meter if its meter type indicates interval registers are allowed.

Description of Page

This section only highlights the fields that are different from regular (non interval) meter configurations.

Use the Complete Data Sets button if you have Pending datasets for the interval registers linked to the meter configuration and you would like the system to Complete them. When this button is clicked, all validation algorithms defined on the registers' Interval Register Types will be executed. If no errors are detected from the interval register types' validation algorithms OR if none of the interval register types contains validation algorithms, the pending data sets will be marked as complete . Refer to Validation of Register Data for more information about the validation algorithms.

The Registers accordion contains information about the meter configuration's registers. The following fields are unique to interval registers or have special behavior for interval registers:

- Turn on Interval if this register can have interval datasets associated with it.

- Use Interval Register Type to define the interval register type that controls business rules associated with an interval register's datasets. This field is disabled if Interval is turned off.

- Use Time of Use (TOU)to define the time-of-use code if any, that specifies a particular time of day during which the register measures consumption. This field is disabled if Interval is turned on.

- Channel ID is used to specify an external id for the register. It can be used, for example, to store the MV-90 channel ID suffix related to a specific register for interval meters.

Meter Configuration - Meter Configuration Tree

Open Meter, Meter Configuration and navigate to the Meter Configuration Tree tab to view a meter configuration's tree.

Description of Page

At the top of the page is a summary description of the Meter Configuration. At the right is the system-generated unique Meter Configuration ID for the meter.

This page displays a tree view of registers linked to the Meter Configuration. The root node displays the ID of the meter configuration along with its standard description.

The register nodes contained in the tree view are hyperlinks that navigate to the Registers accordion on the Meter Configuration - Main Information page.

- If any non-interval registers are associated with the meter configuration, a node is displayed for each register.

- If any interval registers are associated with the meter configuration, a node is displayed for each register. Expanding this node displays information about data sets linked to the interval register.

- The Pending Data Sets node displays if any of the data sets linked to the register are pending . Expanding this node displays each pending data set.

- The Error Data Sets node displays if any of the data sets linked to the register are in error . Expanding this node displays each error data set.

- The Data Created Through node displays the date of the latest complete interval as of the current date. Expanding this node displays the last 10 complete data sets.

Meter Configuration – Meter Configuration Portal

Select Main Menu > Meter > Meter Configuration and navigate to the Meter Configuration Portal tab to view additional information associated with a Meter Configuration.

General Information

Meter Configuration ID, Meter Configuration Info are displayed.

Depending on your implementations requirements, you may define additional zones to appear on this Portal.

Refer to The Big Picture of Portals and Zones in the Oracle Utilities Application Framework Administration Guide for a description of portal and zone functionality.

Validating Register Constants

You can validate the register constants of all installed electric meters, by service cycle (the service cycle of the service points in which the meters are installed). This allows you to check and confirm, in mass, the entered constants for all meters.

This background process (known by the batch control ID of REGCNST) selects all electric service points on the input service cycle. It uses CT (current transformer) and PT (potential transformer) equipment linked to SP to calculate register constant using the formula:

Calculated Register Constant = Product of all CT, PT ratios * Dial Constant

If the calculated register constant doesn't match to the actual register constant, a To Do entry is created.

In order for the process to know how to find the correct equipment and the correct ratios, control tables need to be set up appropriately and parameters for the background processes need to be defined accordingly.

- Equipment is set up through the use of Items. You will define an Item Type to be used for CT equipment and another to be used for PT equipment.

- The CT Ratio will need to be defined using a Characteristic Type for the CT Item.

- The PT Ratio will need to be defined using a Characteristic Type for the PT Item.

- The Dial Constant will need to be defined using a Characteristic Type for the Meter.

In order for the background process to work correctly, the following input parameters will need to be populated:

- Service Cycle

- Item Type to identify the CT Equipment

- Item Type to identify the PT Equipment

- Characteristic Type to identify the CT Ratio

- Characteristic Type to identify the PT Ratio

- Characteristic Type to identify the Dial Constant

- To Do Type and To Do Role

Fastpath:

Refer to Register ConstantValidation Process for more information.

Maintaining Items

Item records contain information describing badged items that exist at service points. Item records are also used to describe equipment that is linked to meters, service points, and other items.

Fastpath:

Refer to Equipment versus Badged Items for more information.

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

Contents

Item - Main Information

Item - Characteristics

Item - SP Installation History

Item - Equipment

Item - Location History

Item - Main Information

The Main page contains core item information. To open this page, use Meter, Item.

Description of Page

The following item information is displayed at the top of the page:

Item Info A concatenation of the item's item type, badge number and status.

Item ID This is a system-assigned random number that stays with an item for life. This value only appears after the item exists on the database.

Premise ID The unique identifier of the premise at which the item is installed.

Service Point Information about the service point at which the item is installed.

Install Date The date the item was installed at its current location.

Removal Date The date the item was removed from its last location.

The remaining fields are maintained on the remainder of this page.

Use Badge Number to define the identifier stamped on the item. This is NOT the manufacturer's serial number. Rather, it's the number on the badge that typically appears on the face of the item. This number is what most operators use to identify the item.

Indicate the Item Type. This field is important as it defines the type of service associated with this item. It also defines characteristics common to all items of a given type and the type of equipment that can be linked to the item.

Use the Item Status to indicate if the item is Active , Ordered , or Retired .

Define the item's Manufacturer and Model.

Enter manufacturer's Serial Number.

Use Date Received to define the date on which the item was received from the manufacturer.

Use Date Retired to define the date when the item is retired from service. This field is gray when the item status is Active or Ordered .

Use Retire Reason to define why the item was retired from service. This field is gray when the item status is Active or Ordered .

Enter any comments about the item in the Comments.

The tree at the bottom of the page is only relevant for items used to define pieces of equipment as it contains the following information:

- Every service point to which a piece of equipment is linked

- Every meter to which a piece of equipment is linked

- Every item to which a piece of equipment is linked

Item - Characteristics

The characteristics page contains information that describes miscellaneous information about the item. Use Maintain Items, Item, Characteristics to open this page.

Description of Page

Item Info is a concatenation of the item's item type, badge number and status.

Item ID is the system-assigned random number that stays with an item for life. This value only appears after the item exists on the database.

To modify a characteristic, simply move to a field and change its value. To add a new characteristic, click the + button to insert a row, then fill in the information for each field. The following fields display:

Effective Date Indicate the date on which the characteristic value becomes effective. The item's date received defaults.

Characteristic Type Indicate the type of characteristic.

Characteristic Value Indicate the value of the characteristic.

Note:

Default note. If the item's item type has required characteristics, the respective characteristic types will default in the above grid.

Item - SP Installation History

The SP Installation History is an information-only page that shows the history of service points at which the item has been installed. Use Item, Item, SP Installation History to open this page.

This page shows the history of the service points at which the item has been installed. No fields on this page may be modified.

Item - Equipment

The equipment page contains the equipment that is linked to the item. Use Meter, Item, Equipment to open this page. Refer to Equipment May Be Associated With Other Items for more information.

Description of Page

To modify a piece of equipment, simply move to a field and change its value. To add a new piece of equipment, click + to insert a row, then fill in the information for each field. The following fields display:

Equipment ID Indicate the unique identifier of the equipment.

Note:

This is actually the unique ID of an item as an item must be set up for each piece of equipment that can be linked to an item. Only items with an item type defined on the item's item type's equipment collection may be defined (in other words, the valid types of equipment are defined on the item's item type).

Badge Number This is a display-only field that contains the equipment's badge number.

Equipment Type This is a display-only field that contains a description of the equipment's item type.

Equipment Count This field should be 1 except when you are using an item to define a generic piece of equipment. If you use an item to define a generic piece of equipment, you can indicate the number of such generic pieces of equipment that are associated with this item.

Install Date Define the date that the equipment was installed at the item.

Removal Date Define the date that the equipment was removed from the item.

Comments Use comments to explain anything unusual about the piece of equipment.

Item - Location History

The item location history page has two purposes:

- You can view the history of the service points and stock locations at which an item has been located.

- You can change an item's current stock location if it is not installed at a service point.

It's important to be aware that location history is only recorded when the item's item type indicates that its location is tracked. Refer to The Big Picture of Asset Inventory for further information.

Use Meter, Item, Location History to open this page.

Description of Page

The rows in the grid show where the item has been located over its lifetime. The following types of rows may be displayed:

- When an item is installed at a service point, a stock location history record is created with a Location History Type of SP Install .

- Location Date/Time is the time of installation. This may not be modified.

- Location is the service point at which the meter is installed. This may not be modified.

- When an item is removed from a service point, a stock location history record is created with a Location History Type of SP Removal .

- Location Date/Time is the time of removal. This may not be modified.

- Location is a stock location. This value is defaulted based on the service point's postal defaults . You may change this Location if the defaulted value is incorrect.

- When a new item is added, you must create a location history record to define the stock location at which the item is stored.

- Enter the Date/ Time the item was received.

- The Location History Type is defaulted to Stock .

- Use Location to define the stock location where the item is being stored.

- If an item is transferred from one stock location to another, you must create a location history record as described above.

To create a new location history record, click the + button to insert a row, then fill in the information for each field.

Note:

Location history may have gaps. An item's Stock Location History Is Created Behind the Scenes and is only created if stock location is being tracked.

Installing / Removing A Meter

The installation of a meter is a small part of the process of starting / stopping service. This process begins when a customer requests service at a metered service point that is, at present, without service. It continues with the creation of a field activity required to connect service. When the system is advised of the results of the field activity, it creates a SP / Meter history record (which you can see on this page).

The removal of a meter from a service point involves an exactly analogous process where you use the SP / Meter Installation page to indicate when the meter was removed (and the dial readings at that time).

The remainder of this section is limited to a discussion about how to use the SP / Meter Installation page.

Fastpath:

For more information about starting / stopping service, refer to The Big Picture Of Starting Service and The Big Picture Of Stopping Service. For more information about how the results of a field activity are advised to the system, refer to How Does A Field Order Get Completed?. For more information about setting up field activity types to install and remove meters from service points, refer to Setting Up Field Activity Types.

Contents

SP / Meter Installation

SP Meter Installation History

SP / Meter Installation

The system automatically updates the information on this page when field activities that affect a meter's installation status (i.e., installs, removes, on/offs) are completed via Field Activity Upload Staging. You should only have to change the information on this page when you need to fine-tune what the system sets up by default.

Open Meter, SP/Meter Installation to update a meter's installation information.

Description of Page

The following information is displayed at the top of the page:

SP/Meter History This is a concatenation of meter and service point information. This information only appears after the SP/item history record exists on the database.

SP/Meter History ID This is a system-assigned random number that stays with a SP/meter history record for life. This value only appears after the SP/meter history record exists on the database.

The remaining fields are maintained on the remainder of this page.

Service Point ID is the ID of the service point at which the meter is installed.

Note:

SP Type Restrictions. The service point's SP Type controls whether or not a meter can be installed at the service point, and if so, what type of meter can be installed. Refer to Setting Up Service Point Types for more information.

Meter Configuration ID indirectly identifies the meter that is installed at the service point. A configuration may be associated with exactly one meter at any given point in time. Therefore, identifying the configuration also identifies the meter. Adjacent to the configuration ID is summary information about the configuration and the meter with which it is currently associated. This information consists of the description of the meter type of the meter, the meter's badge number, the effective date and time of the configuration, and the number of registers.

Use the Installation information to define the readings on the meter's register(s) when the meter is installed. To do this you must:

- Enter the installation Meter Read ID that shows how the meter's register(s) look at installation time. If you need to view or modify the read, click the context menu and transfer to the meter read.

Note:

The installation date and time of the meter is the installation meter read's date/time.

- Use Meter On/Off Status to define if the meter is turned on or off when it's INITIALLY installed. Valid values are On and Off . This status does not affect billing in any way. It is purely informational.

- Override the Installation Constant (i.e., set it to a value other than 1 ), if equipment is linked to this service point that affects the calculation of the constant used to manipulate the meter's consumption at billing time. It's important to be aware that this value is multiplied by the meter's registers' respective constants when billing determines the amount of consumption associated with a meter. Typically, only large industrial service points will have a value other than 1 . Note that when you want to change the installation constant for a service point you must perform an 'office exchange'. This means that you should remove the current meter and reinstall it. On the new install, specify the new installation constant - this way billing will recognize the new constant and adjust the billable quantities correctly.

Note:

Default note. The Installation Constant defaults to a value of 1 for the first meter configuration installed at a service point. The installation constant for subsequent meter configurations is defaulted to the value of the latest meter configuration's installation constant.

Warning:

Entering a meter configuration and install meter read is an important part of installing a meter at a service point. However, if the installation was done in order to activate a service agreement, you also must reference the install meter read as the start read on the respective service agreement / service point linkage. The system sets this linkage up for you if: a) the meter installation is done as part of a field activity, and b) the field activity is linked to the service agreement / service point linkage as its start activity. Refer to Starting Service & Field Activities for more information.

Use the Removal information to define the readings on the meter's registers when the meter is removed. To do this you must:

- Enter the removal Meter Read ID that shows how the meter's register(s) look at removal time. If you need to view or modify the read, click the context menu and transfer to the meter read.

Note:

The removal date and time of the meter is the removal meter read's date/time.

Warning:

Entering a removal meter read is an important part of removing a meter. However, if the removal was done in order to stop service, you must also reference the removal meter read as the stop read on the respective service agreement / service point linkage. The system sets this linkage up for you if: a) the meter removal is done as part of a field activity, and b) the field activity is linked to the service agreement / service point linkage as its stop activity. Refer to Starting Service & Field Activities for more information.

- Stock Location only appears if the meter's meter type tracks location. Enter the stock location where the meter is stored upon removal. Refer to The Big Picture Of Asset Inventory for more information.

The Meter On/Off History grid contains the history of when the meter has been turned on and off while it's installed at a service point.

When a meter's on/off status changes, insert a new entry into the grid by clicking the + button. Then,

- Enter the On/Off Meter Read ID that shows how the meter's dials look when the status is changed. When this field is populated, the meter Read Date/Time appears adjacent to it.

- Use Meter On/Off Status to define if the meter is turned on or off. Valid values are On and Off .

A unique Sequence number is given to each entry after the information is saved.

Warning:

The on/off status does not affect billing in any way. So, for example, if you turn a meter off and never expire the service agreement / service point link, the meter will still be amalgamated by billing (although it's consumption should be zero). This is intentional as many meters are turned off as part of the credit and collections process when a customer is delinquent (but the service point is still linked to the service agreement in case the customer pays up).

SP Meter Installation History

The SP installation history page is an information-only page that shows the meters that have been installed at the service point. Use Meter, SP / Meter Installation, SP Installation History to open this page.

Description of Page

This page shows the history of the meters that have been installed at the service point. No fields on this page may be modified.

Installing / Removing An Item

The installation of an item is a small part of the process of starting / stopping service. This process begins when a customer requests service at an item-based service point without an item. It continues with the creation of a field activity to connect service. When the system is advised of the results of the field activity, it creates a SP / Item history record (which you can see on this page).

The removal of an item from a service point involves an exact analogy where you use the SP / Item Installation page to indicate when the item was removed.

The remainder of this section is limited to a discussion about how to use the SP / Item Installation page.

Fastpath:

For more information about starting / stopping service, refer to The Big Picture Of Starting Service and The Big Picture Of Stopping Service. For more information about how the results of a field activity are advised to the system, refer to How Does A Field Order Get Completed?. For more information about setting up field activity types to install and remove meters from service points, refer to Setting Up Field Activity Types.

Contents

SP / Item Installation

SP Item Installation History

SP / Item Installation

The system automatically updates the information on this page when field activities that affect an item's installation status (i.e., installs, removes, on/offs) are completed via Field Activity Upload Staging. You should only have to change the information on this page when you need to fine-tune what the system sets up by default.

Open Meter, SP/Item Installation to update a meter's installation information.

Description of Page

The following information is displayed at the top of the page:

SP/Item History This is a concatenation of service point AND item information. This information only appears after the SP/item history record exists on the database.

SP/Item History ID This is a system-assigned random number that stays with a SP/item history record for life. This value only appears after the SP/item history record exists on the database.

Enter the ID of the Service Point at which the item is installed. Summary information about the service point is displayed adjacent to the service point ID.

Note:

SP Type Restrictions. The service point's SP Type controls whether or not an item can be installed at the service point, and if so, what type of item can be installed. Refer to Setting Up Service Point Types for more information.

Item ID identifies the item that is installed at the service point. Summary information about the item is displayed adjacent to the item ID.

Use the Installation information to define when the item is installed. To do this you must:

- Enter the Installation Date/Time showing when the item is installed at the service point.

- Use Item On/Off Status to define if the item is turned on or off when it's INITIALLY installed. Valid values are On and Off . This status does not affect billing in any way - it is purely informational.

Use the Removal information to define when the item is removed from the service point. To do this you must:

- Enter the Removal Date/Time showing when the item is removed from the service point.

- Stock Location only appears if the item's item type tracks location. Enter the stock location where the item is stored upon removal. Refer to The Big Picture Of Asset Inventory for more information.

The Item On/Off History grid contains the history of when the item has been turned on and off while it's installed at the service point. When an item's on/off status changes, insert a new entry into the grid by clicking the button. Then,

- Use Event Date / Time to define when the status changed.

- Use Item On/Off Status to define if the item is turned on or off. Valid values are On and Off .

Warning:

The on/off status does not affect billing in any way. So, for example, if you turn an item off and never expire the service agreement / service point link, the item will still be amalgamated by billing. This is intentional as items can be turned off as part of the credit and collections process when a customer is delinquent (but the service point is still linked to the service agreement in case the customer pays up).

Note:

Only lamps use on/off status. This grid is only applicable to items that can be switched on and off (e.g., a lamp with a photovoltaic eye can be switched on and off by installing or removing the eye). If the type of item does not possess such a property, set the status to on.

SP Item Installation History

The SP installation history page is an information-only page that shows the items that have been installed at the service point. Use Meter, SP / Item Installation, SP Installation History to open this page.

Description of Page

This page shows the history of the items that have been installed at the service point. No fields on this page may be modified.

Testing A Device

Device tests record the results of the periodic tests used to determine the accuracy of your meters and item. The topics in this section describe how to record the results of a meter or item test.

Fastpath:

Refer to The Big Picture Of Device Testing for more information.

Contents

The Lifecycle Of A Device Test

Device Test - Main

Device Test - Characteristics

Device Test - Components

The Lifecycle Of A Device Test

The following diagram shows the possible lifecycle of a device test.

In Progress The system creates a device test in the state of In Progress .

Passed The system automatically changes the state of an In Progress device test to Passed when an operator indicates such on the device test page. Note, if the device test's test type has a validation algorithm, the test must pass the validation rules embodied in the algorithm before the test will become Passed . If the device test's test type does not use a validation algorithm, the test is assumed to pass when the operator indicates such.

Failed The system automatically changes the state of a device test to Failed when an operator indicates such on the device test page. Note, if the device test's test type has a validation algorithm and the user indicates the test has passed, the system will change the test to Failed if the test fails the algorithm.

Error If the device test's test type has a validation algorithm and the user indicates the test has passed, the system will change the test to Error if a problem is encountered while the validation algorithm executes.

Canceled You may Cancel a device test if it shouldn't exist.

Device Test - Main

The Main page contains core device test information. Open this page using Meters, Device Test, Main.

Description of Page

The top portion of every page in this page contains the following information:

Device Test is a concatenation of summary information about this device test. It is composed the device's badge number, the test date, and the test's status.

Device Test ID is the unique system-generated identifier for this device test.

The remaining fields on the page are described below:

Use Device Test Type to define the type of test that was conducted.

Use Test Start Date/Time to define when the test was started.

Use Test Stop Date/Time to define when the test was completed.

Define the Meter ID on which the test was performed. This field will be gray if the Device Test Type is used for items.

Note:

You can only select a meter whose meter type indicates this Device Test Type can be performed for it.

Define the Item ID on which the test was performed. This field will be gray if the Device Test Type is used for meters.

Note:

You can only select an item whose item type indicates this Device Test Type can be performed for it.

Indicate who performed the test:

- If the test was performed by a 3 rd party service provider, enter the tester's Service Provider ID.

- If the test was performed by a user, enter the person's User ID.

Use Comments to describe anything unusual about the test.

If the device test's status is Failed or Error , a Message will be displayed describing why.

Test Status defines the state of the device test. The buttons beneath the status are used to change the state of the device test:

- Click the Validate button to indicate a test should become Passed . When this button is clicked, one of two things will happen:

- If the Device Test Type has a validation algorithm, the algorithm will be called and the status could become Passed , Failed or Error .

- If the Device Test Type doesn't have a validation algorithm, the status will become Passed .

- Click the Fail Test button to indicate the test's status should be Failed .

- Click the Cancel button to indicate the test is Canceled .

Device Test - Characteristics

The characteristics page contains device test results. Use Meters, Device Test, Characteristics to open this page.

Note:

Default note. When a device test is first created, all required characteristics will be defaulted (the operator need only specify their respective characteristic values).

Description of Page

The top portion of every page in this page contains the following information:

Device Test is a concatenation of summary information about this device test. It is composed the device's badge number, the test date, and the test's status.

Device Test ID is the unique system-generated identifier for this device test.

To modify a characteristic, simply move to a field and change its value. To add a new characteristic, click + to insert a row, then fill in the information for each field. 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.

Where Used

The data on this page may be used during the execution of the device test's test type's validation algorithm. Refer to Device Test Validation for more information.

Device Test - Components

The test components page contains test components associated with the device test (refer to A Device Test Records Test Results for examples of how and when test components are used to record test results). Use Meters, Device Test, Components to open this page.

Note:

Default note. When a device test is first created, all test component types defined on the device test type will be defaulted.

Description of Page

The top portion of every page in this page contains the following information:

Device Test is a concatenation of summary information about this device test. It is composed the device's badge number, the test date, and the test's status.

Device Test ID is the unique system-generated identifier for this device test.

The Device Test Component scroll controls the display of the test components involved in the device test. The fields that appear in the outer scroll are as follows:

Test Component Type The test component type controls the type of test results that are entered. Note well, only test component types defined as permissible on the device test type may be specified.

Sequence This field along with the Device Test ID uniquely identify this record.

Register ID This field is only used if the Test Component Type indicates that a register must be specified. This is typically only done with the component test involves the testing of a specific register.

The grid contains fields used to capture the test results. The number and the type of test results is controlled by the respective Test Component Type.

Where Used

The data on this page may be used during the execution of the device test's test type's validation algorithm. Refer to Device Test Validation for more information.

Device Test Selection

The device test selection page will generate field activities to test meters and items. Open this page using Meters, Device Test Selection.

Description of Page

To generate field activities to test you meters / items, follow these steps:

- Add a Device Test Selection record (see the field description below for information about the fields)

- Click the Complete button to have the system generate the field activities. The generated field activities will appear in the grid at the bottom on the screen.

- If, after reviewing the field activities, you decide not to perform the tests, you can cancel the field activities by clicking the Cancel button. It's important to note that the system will only cancel Pending activities that are allowed to be canceled automatically.

The remainder of this selection describes the fields associated with a Device Test Selection.

Enter a Description of the selection event.

Select a Selection Algorithm that will select meters or items for testing. Refer to Field Activities And Device Testing for more information.

Use Qty to Select to define the number of meters or items for which you want field activities generated.

Define the field Activity Type to be assigned to the generated field activities.

Define the Scheduled Date to be assigned to the generated field activities.

The Create Date/Time of the test selection is displayed.

Status defines the state of the device test selection. The buttons beneath the status are used to change the state of the device test selection:

- Click the Complete button to have the system select the devices to test and to generate the related field activities. The status will change to Complete .

- Click the Cancel button to indicate the test selection is Canceled .

The resultant field activities are displayed in the grid that follows.

Meter Replicator

When a pallet of new meters arrives in your meter shop, you can use the meter replicator to quickly create many copies of a given meter and its configuration. The individual copies may then be edited as needed.

Perform the following steps to create multiple copies of a meter:

- Add a meter using Meter - Main Information.

- Add a meter configuration using Meter Configuration Maintenance.

- Use the meter replicator page to create copies of the meter and its configuration.

The topics in this section describe how to use the meter replicator. Note that there is also an Item Replicator in the case where you need to replicate other devices.

Contents

Meter Replicator - Main Information

Meter Replicator - Meter

Meter Replicator - Meter Configuration

Meter Replicator - Main Information

You use this page to create many copies of a given meter. Use Meter, Meter Replicator, Main to open this page.

Description of Page

Define the Meter ID that is to serve as your template meter.

Note:

Recommendation. Carefully verify the template meter using the other tabs in this page before you save the replicated meters. After you save the replicated meters, any corrections could prove time-consuming.

Indicate the Number of Meters to Replicate.

If the meter's meter type tracks location, a meter history location will be created during replication. Use Stock Location to define the initial meter stock location to be used in the location history. Refer to The Big Picture Of Asset Inventory for more information.

Use Badge Prefix to define the prefix of the badge numbers assigned to the meters. Use Start From to define the suffix of the badge number assigned to the first copy of the meter. Use Increment by to define the value to increment successive badge numbers by. The first and last badge numbers to be created by the replicator are displayed adjacent.

For example, if the first badge number you want to create is E99-1021 and the last badge number is E99-1077 you'd enter the following parameters:

Number of Meters would be 57

Badge Prefix would be E99-10

Start From would be 21

Increment by would be 1

Use Serial Prefix to define the prefix of the serial number assigned to the meters. Use Start From to define the suffix of the serial number assigned to the first copy of the meter. Use Increment by to define the value to increment successive serial numbers by. The first and last serial numbers to be created by the replicator are displayed adjacent.

For example, if the first serial number you want to create is GE9101-1000-001 and the last serial number is GE9101-1000-057 you'd enter the following parameters:

Number of Meters would be 9

Serial prefix would be GE9101-1000-0

Start From would be 1

Increment by would be 1

After entering the parameters, click Replicate to generate your new meters. You can use the frames at the bottom of the page to view the meters that will be created when you click save. The left frame will show how Badge and Serial Numbers will look on the first 10 meters. If you are creating more than 10 meters, the right frame will show how Badge and Serial Numbers will look on the last 10 meters. If everything looks clean, click the save button.

Meter Replicator - Meter

The Meter page is a display-only page provided to let you confirm that the meter you selected is the one to be used as the template by the replicator. Use Meter, Meter Replicator, Meter to open this page.

Note:

Some equipment may not be copied. Equipment that is linked to the template meter will NOT be replicated on the replicated meters if the equipment references an item type that does NOT permit multiple equipment assignments. Refer to The Big Picture of Meters, Items and Equipment for more information about equipment linked to meters.

Description of Page

This is a display-only page that displays information about the registers linked to the meter identified in the add dialog. Refer to Meter - Main Information for a description of the fields.

Meter Replicator - Meter Configuration

The Meter Configuration page is a display-only page provided to let you confirm that the meter you selected is the one to be used as the template by the replicator. Use Meter, Meter Replicator, Meter Configuration to open this page.

Description of Page

This is a display-only page that displays the characteristics linked to the meter identified in the add dialog. Refer to Meter Configuration Maintenance for a description of the fields.

Item Replicator

When you receive a set of new badged items or equipment, you can use the item replicator to quickly create many copies of a given item. The individual copies may then be edited as needed.

Perform the following steps to create multiple copies of an item:

- Add a meter using Item Maintenance

- Use the item replicator page to create copies of the item.

The topics in this section describe how to use the item replicator.

Contents

Item Replicator - Main Information

Item Replicator - Item

Item Replicator - Main Information

You use this page to create many copies of a given item. Use Meter, Item Replicator, Main to open this page.

Description of Page

Define the Item ID that is to serve as your template item.

Note:

Recommendation. Carefully verify the template item using the other tab in this page before you save the replicated items. After you save the replicated items, any corrections could prove time-consuming.

Indicate the Number of Items to Replicate.

If the item's item type tracks location, an item history location will be created during replication. Use Stock Location to define the initial item stock location to be used in the location history. Refer to The Big Picture Of Asset Inventory for more information.

Use Badge Prefix to define the prefix of the badge numbers assigned to the items. Use Start From to define the suffix of the badge number assigned to the first copy of the item. Use Increment by to define the value to increment successive badge numbers by. The first and last badge numbers to be created by the replicator are displayed adjacent.

For example, if the first badge number you want to create is E99-1021 and the last badge number is E99-1077 you'd enter the following parameters:

Number of Items would be 57

Badge Prefix would be E99-10

Start From would be 21

Increment by would be 1

Use Serial Prefix to define the prefix of the serial number assigned to the items. Use Start From to define the suffix of the serial number assigned to the first copy of the item. Use Increment by to define the value to increment successive serial numbers by. The first and last serial numbers to be created by the replicator are displayed adjacent.

For example, if the first serial number you want to create is GE9101-1000-001 and the last serial number is GE9101-1000-057 you'd enter the following parameters:

Number of Items would be 9

Serial prefix would be GE9101-1000-0

Start From would be 1

Increment by would be 1

After entering the parameters, click Replicate to generate your new items. You can use the frames at the bottom of the page to view the items that will be created when you click save. The left frame will show how Badge and Serial Numbers will look on the first 10 items. If you are creating more than 10 items, the right frame will show how Badge and Serial Numbers will look on the last 10 items. If everything looks clean, click the save button.

Item Replicator - Item

The Item page is a display-only page provided to let you confirm that the item you selected is the one to be used as the template by the replicator. Use Meter, Item Replicator, Item to open this page.

Note:

Some equipment may not be copied. Equipment that is linked to the template item will NOT be replicated on the replicated items if the equipment references an item type that does NOT permit multiple equipment assignments. Refer to The Big Picture of Meters, Items and Equipment for more information about equipment linked to items.

Description of Page

This is a display-only page that displays information about the registers linked to the item identified in the add dialog. Refer to Item - Main Information for a description of the fields.

Usage Requests

Note:

The information in this section applies to the integration with Oracle Utilities Meter Data Management.

Usage records are created when bill determinants are requested from Oracle Utilities Meter Data Management during billing. The consumption information is then used to create a bill segment for the associated service agreement.

The topics in this section describe how to search for and maintain usage records.

Contents

Usage Query

Usage - Main

Usage - Log

Usage Query

The Usage Query page is a standard query portal used to search for an existing usage record. Use Main Menu > Usage > Usage Search to open this page. When you select a usage record, the maintenance portal opens and displays the associated information for the usage record.

Usage - Main

This portal appears when a usage record is selected from the Usage Query portal or the Bill Segment - Usage page.

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

Contents

Actions

Usage

Actions

This is a standard actions zone.

Usage

The Usage zone displays information for the selected billing segment. Please see the zone's help text for information about this zone's fields.

Usage - Log

The usage log page contains an entry for every recorded event during the lifecycle of the usage request. There are two general types of log entries:

- Automatic entries. The system automatically creates an entry in the log when usage is requested 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.

Meter Reading

In this section, we describe how to manage the cyclical reading of your metered service points and how to add and change ad hoc meter reads.

Fastpath: For more information about meters, refer to Meter Management.

Contents

Background Topics

Meter Read Maintenance

Setting Up Trends

Renumber Service Route Sequences

Service Route Transfer

Read History

Downloading Meter Reads

Uploading Meter Reads

TD-HILO - To Do for Meter Read High/Low Errors

Review High / Low

Background Topics

The topics in this section provide background information about a variety of meter reading issues.

Contents

The Cyclical Meter Read Process

Managing Metered Service Routes

High / Low Checks

Meter Reads and Billing

The Cyclical Meter Read Process

Most meter reads are recorded in the field by meter readers using handheld devices. These meter reads are uploaded into the system for use by billing. In this section, we provide an overview of how this cyclical process works:

- Every metered service point references a service cycle, route, and sequence within the route.

- The service cycle controls WHEN the service point's meter is read.

- A service cycle typically contains many routes. A route is a logical group of service points whose meters can be read by a meter reader on a given day.

- A service point's sequence defines the order within a route that the service point is read.

- Every service cycle has a service cycle schedule that defines the dates on which the routes within a cycle are read.

- Shortly before the scheduled meter read date, the system creates a download file containing information to be sent to your handheld software. This download file contains information about every register on every meter in every route in the cycle being downloaded.
Note: Overriding a route within a specific schedule. Rather than downloading all routes within a cycle, you can set up the system so that only specific routes are downloaded on any given date. This is a very powerful feature. You can use it, for example, to estimate specific cycles every other month or indicate the customer reads the meter every third month. Refer to Designing Service Cycles, Routes, And Schedules for more information.

- Your handheld software distributes this information to the handheld devices and then your meter readers do their job. When they finish, the resultant meter reads are uploaded into the system.

Note: Billing recalculates consumption. While the system calculates consumption when a read is added to the system in order to compare it to high / low values, this consumption is not used by billing. Rather, billing recalculates consumption in case something changes between the time the read is stored and the customer is billed for the consumption (e.g., the register's constant is changed, the dial reading is changed due to digit transposition in the field, etc.)

Fastpath: For more information about the how to control when a cycle is read, refer to Setting Up Service Cycle Schedules.

Managing Metered Service Routes

Every metered service point references a service cycle, route, and sequence within the route.

- The service cycle controls WHEN the service point's meter is read.

- A service cycle typically contains many routes. A route is a logical group of service points whose meters can be read by a meter reader on a given day.

- A service point's sequence defines the order within a route that the service point is read.

Fastpath: Refer to Renumber Service Route Sequences and Service Route Transfer for more information about changing the service points in a route. Refer to Service Point - Main Information for more information about how to change a specific service point's cycle, route, and sequence.

High / Low Checks

Regardless of the source (upload or online), whenever a meter read is added, the system checks that the meter read's consumption is reasonable. This check is performed by comparing the actual read to high and low read values. The actual high and low read values are calculated by the Meter Read High Low Limits algorithm specified on the installation options.

The base package is supplied with a sample algorithm type ( HILO-FACTBL) that uses the High Low Factor table to derive the high and low limits for a register read as follows:

- Estimate consumption using the estimation algorithm specified for the trend area .

- Calculate the high and low usage amounts using the high and low usage factors for the unit of measure and read type:

- The low usage amount is calculated by multiplying estimated consumption by the low usage factor.

- The high usage amount is calculated by multiplying estimated consumption by the high usage factor.

- Determine the high and low read values using the high and low usage amounts and the previous read value.

When a meter reading's consumption is outside of the high / low boundaries, it is flagged accordingly. However, billing still uses the reading unless an operator explicitly disallows the reading.

Fastpath: Refer to Review High / Low for more information about reviewing readings that failed high / low checks.

Note: Disallowing Readings. You can disallow billing from using a read by unchecking Use On Bill on the Meter Read page.

Meter Reads and Billing

When it's time to create a bill for a customer, the system looks for an appropriate meter read for each metered service point on or around the scheduled meter read date. If a single read is found, billing uses it to calculate consumption. However, challenges exist if either of the following two situations occurs:

- When multiple meter reads exist on or around the scheduled meter read date.

- When no reads exist.

Sorting out multiple reads is easy. Every read contains a read type. Each read type has an associated priority code. If multiple reads exist, billing uses the read with the highest priority. If multiple reads of the highest priority exist, one is selected at random.

Fastpath: For more information about read types and their billing selection priority, refer to the Description of Page under Meter Read - Main.

Sorting out the situation when no reads exist isn't so easy. When no reads exist, billing generates an estimated read (derived by estimating consumption) if all of the following conditions are true:

- The initiator of the bill allows estimation.

- If a bill is created as a result of a bill cycle schedule, the bill cycle schedule must have an estimation date on or after the current date.

- If a bill is created real time from one of the bill pages, the requesting operator must specifically allow estimation.

- The service agreement allows estimation.

If estimation is allowed, the billing process estimates consumption as of the scheduled meter read date using the same algorithm used for the purpose of high / low checks.

Whenever billing estimates consumption, it creates a meter read to represent the estimated consumption. You can see this meter read on the meter read queries.

Fastpath: For more information about estimated consumption, refer to The Theory Behind Consumption Estimation.

Meter Read Maintenance

The topics in this section describe how to add or update a Meter read.

Contents

Meter Read - Main

Meter Read - Characteristics

Correcting Reads Versus Entering New Reads

Meter Read Remark Exceptions

Meter Read - Main

To add or update a meter read, open Meter Read, Meter Read, Main.

Note: There are 4 ways to add meter reads. You can add meter reads using any of the following methods: A) open Meter Read, Meter Read, Main, B) add the read using the Meter Read Upload Staging page, C) populate the Meter Read Upload Staging using SQL, and D) you can add a reading using Field Activity Upload Staging. Both options B and C rely on the subsequent execution of the Meter Read Upload Background Processes to create the reads in the system.

Description of Page

Meter Read is a concatenation of summary information about the meter read.

Meter Read ID is the system-generated unique identifier for the meter read.

Enter the Meter Configuration ID of the meter that was read. Adjacent to the ID is summary information about the configuration. This field is protected if the meter read is used on an SP/Meter Installation history record.

Premise is a display-only field that shows the information about the premise at which the meter configuration was installed when it was read.

Enter the Read Date/Time. This field is protected if the meter read is used on an SP/Meter Installation history record.

Turn off Use On Bill if the meter read should not be used by billing. You'd typically turn this off if a meter failed high / low checks and you don't want billing to use it to calculate a customer's consumption.

Use Meter Read Source to define the source (e.g., the reader, the reading agency, etc.) of the read. If the read was uploaded with the reader id, Meter Reader is displayed.

The Reread Meter button can be pressed to create a field activity to reread the meter (note, the field activity type is defined on the field activity type profile associated with the service point at which the meter configuration is currently installed). This button is disabled if the meter configuration is not currently installed at a service point. If there is a Pending reread field activity for the service point, information about the field activity is displayed adjacent. If multiple such field activities exist, information about the earliest activity is displayed.

The scroll that follows contains one row for every register linked to the meter configuration. You cannot insert or remove entries in this scroll because a reading must be entered for every one of the configuration's registers.

Note: Register reads may not be entered for interval registers. Refer to The Big Picture of Raw Data Collection and Aggregation for more information.

The remaining fields are entered for each register.

Sequence is a display-only field that controls the order in which a register is read.

Register Information consists of the unit of measure, time of day (if any), the format of the register, and the register's constant.

Use Read Type to define WHO made the read and HOW the read was made. The value of this field is important because it affects which meter read will be used by billing if multiple reads exist during a billing period. The following table lists the read types and describes how a read with this value typically enters the system.

Read Type

Description

Billing Force

Meter reads with this value are entered by a billing administrator who wants to force billing to bill a customer for a given amount of consumption.

Verified

Meter reads with this value are recorded by a meter reader using a handheld device. The handheld device deems a read as "verified" if the meter reader typed the same dial reading in twice. Some organizations have their handhelds programmed to require the double entry of dial readings when the entered value is outside normative values (i.e., the resultant consumption fails high / low checks).

Regular

Meter reads with this value are recorded by a meter reader using a handheld device. See the description for "verified" above for the difference between a "regular" and a "verified" reading.

Customer Read

Meter reads with this value are made by a customer.

System Prorate

Meter reads with this value are created by the system automatically when prorating normal cycle-based reads for use with an off-cycle start service or stop service.

Office Estimate

Meter reads with this value are informed guesses of consumption. These would be used when there was no real reading (i.e., a regular or verified reading), and the system was not allowed to estimate consumption (for whatever reason). This value is rarely used.

Service Provider Estimate

Meter reads with this value are estimates of consumption made by a 3 rd party service provider, such as an MDMA, the distribution company, or an energy supply company.

System Estimate

Meter reads with this value are created by the billing process when a reading cannot be found and the service agreement allows estimation.

No Read

Meter reads with this value are entered to indicate that a read was purposefully not performed (for whatever reason - mad dog, nasty rose bush, deep snow, etc.). A read with this value is not a read at all, it's just an audit trail.

Note: Default note. If the meter configuration has multiple registers, the read type defined for the first register will be defaulted on the remaining registers when you add a new meter read. You can always override this defaulting.

The Message column highlights the following:

- The resultant usage. For subtractive registers, this is the difference between this read and the prior read. For consumptive registers, this is the register reading.

- The valid usage. This is the range of usage that won't trigger a high / low failure. These values are not shown if the read was not subject to high / low checks when it was added.

- The valid readings. This is the range of readings that won't trigger a high / low failure. These values are not shown if the read was not subject to high / low checks when it was added. Note, these values are only calculated for subtractive registers as the valid usage is the same as the valid readings for consumptive registers.

The message column is red for those readings that have failed high / low checks.

Fastpath: Refer to High / Low Checks for more information.

Register Reading contains the dial reading.

The Previous Reading Information column contains information about the read that precedes this read (note, meter reads where Use on Bill is turned off are ignored). The reading's read type, read date, and register reading are displayed.

The Review High / Low switch indicates if this register read has been flagged for consideration by the high / low review background process ( TD-HILO). If a register read has been checked, you may reset the switch so that the register read is no longer considered for the high / low review background process.

Note: Marking a Read for High / Low Review. Only the system can mark a register read for high / low review. Refer to High / Low Checks for more information.

Register ID is the unique identifier of the register. This information is shown for informational purposes.

Register Reading Id is the unique identifier of the register read. This information is shown for informational purposes.

The Meter Reader Remark grid is used to define anomalies associated with the reading. For example, you can indicate if a read wasn't possible because there was a dangerous situation at the premise.

The Meter Read Remark Status is only relevant if a Meter Read Remark code has algorithms associated with it. Algorithms are associated with meter read remarks if additional activities should occur after a meter read with such a remark is added. For example, you could create a field activity if a "seals broken" remark is specified on a meter read. The execution of the algorithm is performed by a background process called MRRA (meter read remark algorithm activator). The Meter Read Remark Status indicates whether the algorithm has been executed:

- When you add a remark that has an algorithm, the status will be Pending . It will remain in this state until the MRRA process next runs.

- When the MRRA process next runs, if the system is successful in executing the algorithm, the status of the meter read remark will become Complete . If the system is not successful in executing the algorithm, the status becomes Error .
Note: Remarks that are in error. Meter reads that contain meter read remarks whose algorithms could not be successfully executed by the MRRA background process are written to the Meter Read Remark Exception table. To correct errors, you may have to delete and re-add the meter read's remark code if the error is impossible to fix (e.g., if the remark causes a customer contact to be generated and there is no customer at the meter's premise).

Fastpath: Refer to Meter Reader Remarks for more information.

Meter Read - Characteristics

To update meter read characteristics, open Meter Read, Meter Read and navigate to the Characteristics tab.

Description of Page

The Characteristics collection contains information that describes miscellaneous information about the meter read.

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.

Meter Read - Meter Read Portal

Select Main Menu > Meter Read > Meter Read and navigate to the Meter Read Portal tab to view additional information associated with a Meter Read.

General Information

Meter Read ID, Meter ReadInfo are displayed.

Depending on your implementations requirements, you may define additional zones to appear on this Portal.

Refer to The Big Picture of Portals and Zones in the Oracle Utilities Application Framework Administration Guide for a description of portal and zone functionality.

Correcting Reads Versus Entering New Reads

Assume that a read was performed in the field and the dial reading was entered incorrectly (e.g., digit transposition). You have two choices, you can modify the uploaded read, or you can enter a new read with a higher priority read code. We prefer the latter approach so that a proper audit exists, but both options work; it's up to you.

Meter Read Remark Exceptions

If a meter read has a remark code that has algorithms associated with it, the system activates the algorithms each time the MRRA (meter read remark algorithm activator) background process is executed. If errors occur during the activation of the algorithms, a record is written to the meter read remark exception table with a message indicating the nature of the severe error.

To view the messages associated with the exception records, schedule the TD-MRRER background process. This process generates a To Do entry for every record in the meter read remark exception table.

After correcting the cause of the error, drill into the meter read page. Then change the status of the remark from Error to Pending . When the MRRA process next runs, it will attempt to execute the remark's algorithm again.

Note: You may have to delete or change the meter read's remark code if the error is impossible to fix (e.g., if the remark causes a customer contact to be generated and there is no customer at the meter's premise).

Setting Up Trends

CAUTION:

You must thoroughly understand the information discussed in Estimating Using Trends before you can understand trends.

Trend information is used to estimate consumption. A separate trend is maintained for every combination of trend area, trend class, unit of measure and time of use code. Each trend maintains a separate record for each day on which consumption was measured. This section deals with the issues associated with the maintenance of trend information.

Contents

Trends Are Updated Behind-The-Scenes

Maintaining Trends

No Trends At Startup

Trends Are Updated Behind-The-Scenes

The consumption associated with certain register reads is updated on a trend record by the TREND background process when the following conditions are true:

- The register's read type must be Customer , Regular or Verified .

- If the register is subtractive, the reading's resultant consumption can't exceed the threshold capacity of the register. Note, a register's threshold capacity equals X times the register's maximum capacity (where X is the rollover threshold factor defined on Installation Options - Billing).

- If the register read was entered online, the resultant consumption can't be outside of the high / low boundaries.

- If the register read was uploaded by the MUP2 background process and the reading was marked for high / low checks, the resultant consumption can't be outside of the high / low boundaries

Warning:

The above points mean that if you do not subject your uploaded meter reads to high / low checks AND the resultant consumption does not exceed the threshold capacity of the register AND the read type is Customer , Regular or Verified , then the trend table will be updated with the register read's consumption.

The specific trend affected by a register read is identified by the following:

- The register's meter's service point's premise defines the trend area.

- The register's meter's service point's SP type defines the trend class.

- The register defines the unit of measure and time of use codes.

- The meter read date defines the trend date.

Important: The system only updates trends with a read type of Customer , Regular or Verified . The system ignores other types of reads when it builds trend information. Refer to Meter Read - Main for more information about read type.

In addition to updating the trend data, the trend process can create To Do entries for any service point without an active service agreement where significant usage is detected. Refer to the Trend Process for more information.

Maintaining Trends

All trend data is updated by the system and should not require modification. However, if you need to view or change this information, open Meter Read, Trend.

Description of Page

A separate trend is maintained for every combination of Trend Area, Trend Class, Unit of Measure and Time of Use code. The Unit of Measure's Measures Peak Qty is displayed adjacent. Each trend contains a separate record for each day on which consumption was measured.

Note: Load functionality. If you enter this page in "add mode" (i.e., you do not select a trend using the search dialog) and you enter a combination of Trend Area, Trend Class, Unit of Measure and Time of Use code that already has trend information, a button will appear adjacent to Trend Area. This button is called " Load" and, if clicked, will cause the information in the following grid to become populated with the respective trend information.

Use the Read Date to indicate the starting point for the display of the trend data. Keep in mind that the data is displayed in reverse chronological order.

The following fields display:

Read Date The date on which the consumption information was recorded in the system.

Thread Nbr The system-generated identifier for a group of trend consumption records (rows) used to calculate a trend estimate. Simply enter a value of 1 if you are entering a trend.

Total Service Quantity The total amount of consumption recorded on the read date.

Number of Units For non-peak units of measure (e.g., CCF, therm, kWh), this contains the number of days in which the total service quantity was consumed. For peak units of measure (e.g., KW, KVAR), this contains the number of meter reads.

Number of Reads The total number of reads whose consumption was recorded on the trend.

Average Consumption This equals the total service quantity divided by the number of units.

No Trends At Startup

Once you've been in production for about one billing period, there should be enough system-generated trend data (depending on the estimation algorithm and how the trend areas/classes are configured) to generate statistically accurate consumption estimates. However, before this time, you will have little or no trend data and therefore the system will not be able to accurately estimate consumption (and therefore high / low validation will not operate).

If you can live with this, then you don't have to set up trends because the system will automatically build them as meter reads are recorded in the system. However, if you opt for this approach, you must turn off high / low validation on your uploaded register reads during the first few months of production. If you fail to do this, every register read will fail high / low validation and reads that fail high / low checks are not trended. To turn off high / low validation populate the uploaded register read's REVIEW_HILO_SW with a value of N .

If you can't live with this, then you'll have to populate the trend data manually. To do this, create trend records for every combination of trend area, trend class, unit of measure and time of use code. For each trend, enter the following:

Thread Nbr Enter 1 .

Read Date Set this to the day preceding your production date.

Total Service Quantity For peak units of measure (e.g., KW, KVAR), this will be the average peak amount of consumption associated with registers belonging to this trend. For non-peak units of measure (e.g., CCF, kWh), this will be the average daily consumption associated with registers belonging to this trend.

Number of Units Enter 1 .

Number of Reads Enter 1 .

Note: You do not have to change the trend classes to indicate only one read is needed. This is because, if the system cannot find enough trends to satisfy the number of reads required by the trend class, it will use as many as exist. For example, consider a trend class that needs 10,000 reads to form a statistically significant sample for estimation, but at estimation time there is only one trend and this trend contains the results from only one read. In this situation, the system will use the consumption information on the single trend to calculate estimated consumption.

Note: Make sure that your manually entered trend information is accurate and well tested. The quality of the trend information impacts your estimation results (depending on your estimation algorithm) and this in turn impacts the bills you send your customers.

Renumber Service Route Sequences

All metered service points reference the service cycle and route in which they are read. Besides referencing the specific cycle and route, every service point has a meter read sequence that defines its relative position in the route (where sequence 5 is read before sequence 10). If you need to insert a service point between two existing service points but there's no gap between the service points' sequences, open Meter Read, Renumber Service Route Sequences to renumber the sequences in a given cycle and route.

Fastpath: Refer to The Cyclical Meter Read Process for more information about cycles and routes.

Description of Page

Use the search button to select the Service Cycle and Service Route whose service points are to be resequenced. When the page opens, you are shown all of the service points in the cycle and route, ordered by current sequence number.

Use the Sequence Range From and To fields to display service points in the grid within a sequence range.

Use the Sequence column in the grid to manually change a service point's sequence number. You can manually change sequence numbers of up to 150 service points at a time. Click the save button to apply your changes. Service points with duplicate sequence numbers are highlighted in the Remarks column.

To resequence all service points within the route, enter the value from which the system should Start Sequencing From and the amount to Increment Sequences by and then click Renumber. Good values to enter would be 5 and 5 respectively. If you specified values in the Sequence Range From fields, only the service points whose sequences fall within the specified range are renumbered.

Service Route Transfer

The topics in this section describe how to transfer a group of service points from one route to another.

Contents

Service Route Transfer - Main

Service Route Transfer - Transfer To

Service Route Transfer - Main

If you need to transfer a group of service points from one route to another, open Meter Read, Service Route Transfer, Main.

Fastpath: Refer to The Cyclical Meter Read Process for more information about service cycles and routes.

Description of Page

This page's dialog is idiosyncratic. Follow the instructions below to transfer service points from one route to another:

- Use the search button to select the Service Cycle and Service Route that contains the service points to be transferred. Upon return from the search, you are shown all of the service points in the input cycle and route in the Transfer From grid.

- In the Transfer From section at the top of the page, enter the sequence number of the first service point to be transferred in Sequence From. Enter the sequence number of the last service point to be transferred in Sequence To.

- In the Transfer To area that follows, enter the Service Cycle and Service Route into which the service points are to be transferred. Enter the sequence number to be assigned to the first service point when it is transferred to the new route using Start Sequencing From. Enter the value by which to increment the sequence number of successive service points using Increment by.

- Click the save button to re-sequence the service points. The re-sequenced service points are shown on the Transfer To tab.

Note: When there's no room. If the "transfer to" route doesn't have enough space between its sequences to insert the desired service points, navigate to Renumber Service Route Sequences and renumber the route by a value large enough to make space. Then, return to this page and transfer the service points into the route.

When a service point's service cycle is updated using this transaction, and the account's bill cycle is not protected, the system automatically updates the account's bill cycle to be in sync with the service cycle.

Service Route Transfer - Transfer To

The Transfer To tab is only populated after you have transferred service points from one cycle/route to another. It shows all service points in the "transfer to" cycle and route specified on the Main tab.

Description of Page

No information on this page may be modified. The grid only contains information after you have transferred service points from one cycle/route to another. Refer to Meter Read Route Transfer - Main for instructions describing how to transfer service points from one route to another.

Read History

This page shows the history of a register's reads. Open this page using Meter Read, Read History.

Description of Page

Register ID identifies the register whose reads are shown in the grid.

Note: How to scroll through a meter's registers. If a Meter has multiple registers, use the meter's context menu and choose Go to Read History to be presented with a list of all of the meter's registers. Then select the first register. You can then use the Next (Alt-N) and Previous (Alt-P) buttons to scroll through the meter's registers.

Filter by controls the reads that appear in the grid:

- If you want to restrict the history to reads that are eligible to appear on a bill, choose Billable Reads Only . This is the default value.

- If you want to see all reads linked to the register, choose All .

- If you want to restrict the history to reads that are NOT eligible to appear on a bill, choose Non-Billable Reads Only .

The remaining points describe the columns in the grid.

Read Date/Time is the date and time of the meter read.

The Read Difference column shows the difference between this read and the previous read.

CAUTION:

The value of Read Difference does NOT take into account constants; it is purely the difference between the respective read and the previous read. Refer to Bill History for a query that shows the history of billed consumption.

The Message column highlights the following:

- The resultant usage. For subtractive registers, this is the difference between this read and the prior read. For consumptive registers, this is the register reading.

- The valid usage. This is the range of usage that won't trigger a high / low failure. These values are not shown if the read was not subject to high / low checks when it was added.

- The valid readings. This is the range of readings that won't trigger a high / low failure. These values are not shown if the read was not subject to high / low checks when it was added. Note, these values are only calculated for subtractive registers as the valid usage is the same as the valid readings for consumptive registers.

The Message column is red for those readings that have failed high / low checks.

Fastpath: Refer to High / Low Checks for more information.

The High/Low Failed column is checked if the read was not within the boundaries of the estimated high and low read values calculated by the system at the time the read was validated.

Refer to Meter Read - Main for the definition of all other columns.

Downloading Meter Reads

Every metered service point references a service cycle, route, and sequence within the route.

- The service cycle controls WHEN the service point's meter is read.

- A service cycle typically contains many routes. A route is a logical group of service points whose meters can be read by a meter reader on a given day.

- A service point's sequence defines the order within a route that the service point is read.

CAUTION:

If your company supplies electric service and uses MV90s, you will need to take advantage of "notional" routes. A "notional" route's service points are never actually read by a human. Rather, the service points' consumption is fed to the system by a sophisticated device (e.g., an MV90). These service points still need to be linked to a route because billing is dependent on the route's cycle to determine the expected meter read date. You would assign a "notional" route a route type that is not processed by the service cycle. Refer to Setting Up Service Route Types for more information.

A Service cycle has a schedule indicating when its service point should be read. Each entry in the schedule contains two dates:

- Scheduled selection date. This is the date the system selects the service points in the cycle for download to your handheld software.

- Scheduled work date. This is the date the meter is expected to be read.

On the scheduled selection date, the system creates a download file containing information to be sent to your handheld software. This download file contains information about every register on every meter in the routes being downloaded.

Your handheld software distributes this information to the handheld devices and then your meter readers do their job. When they finish, the resultant meter reads are uploaded into the system for subsequent use by billing.

Note: Rather than downloading all routes within a cycle, you can set up the system so that only specific routes are downloaded on any given date. This is a very powerful feature. You can use it, for example, to estimate specific cycles every other month or indicate the customer reads the meter every third month. Refer to Designing Service Cycles, Routes, And Schedules for more information.

Meter Read Download Processes

The following diagram illustrates the processes involved in the creation of the flat file that is interfaced to your meter reading software.

Contents

MSR - Create Service Schedule Routes

MDS - Create Download Staging

MDL - Create Download Flat File

MSR - Create Service Schedule Routes

This process looks for all service cycle schedules with a scheduled selection date on or before the supplied business date whose routes haven't been generated. For each record found, the process creates MR schedule route records for every route in the cycle.

MDS - Create Download Staging

This process looks for all MR schedule route records with a schedule type of Download and a status of Pending . For each record found, the system creates a MR download staging record for the meter linked to every service point in the route.

Download staging records get marked with a batch control ID & run number when they're created by the MDS process.

- The batch control ID comes from the service point's route's route type. This ID corresponds with a specific meter read download method. The system comes with a single meter read download program ( MDL - Create Download Flat File). If you require different flat file formats or different routing methods, you will need to create additional programs. Refer to Setting Up Meter Read Extracts for instructions describing how to add another process.

- The run number is the batch control ID's current run number.

MDL - Create Download Flat File

This process reads all download staging records marked with a given batch control ID & run number and creates the flat file that's passed to the meter read software.

Note: This process is rerunnable. You can reproduce the flat file at any time. Simply request this job and specify the run number associated with the historic run.

If you require different flat file formats or different routing methods, you will need to create additional versions of this program. Refer to Setting Up Meter Read Extracts for instructions describing how to add another process.

Uploading Meter Reads

This section describes how the system uploads meter reads from an external source.

Contents

Meter Read Upload Background Processes

MRUP-PRG - Purge Meter Read Upload Objects

MR Upload Staging

MR Upload Exception

Meter Read Upload Background Processes

The following diagram illustrates the processes involved in the uploading of meter reads into the system.

The topics in this section describe how these processes work.

Contents

Process X - Populate MR Upload Staging

MUP1 - Populate Meter Configuration

MUP2 - Create Meter Read

Process X - Populate MR 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.

Contents

Meter Read Upload Staging

Upload Register Read

Upload Read Remark

Upload Read Characteristics

Meter Read Upload Staging

You must create an upload staging record for each meter that was read. The name of this table is CI_MR_STAGE_UP . The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

MR_STAGE_UP_ID

12

Y

A/N

This is the unique identifier of the meter read upload staging record. This key is a sequential number so you can use a database function to assign the value when populating the table.

BADGE_NBR

30

N

A/N

If specified, this must correspond with a badge number on one of your meters. See the MTR_CONFIG_ID note below for how this field can be used. Also see the note under MTR_ID_NBR if you plan to use the meter's alternate ID's rather than the badge number to identify the meter being read.

MTR_CONFIG_ID

10

See note

A/N

This must correspond with a meter configuration number on one of your meters. You may leave this column blank if BADGE_NBR or MTR_ID_TYPE_CD / MTR_ID_NBR is populated.

READ_DTTM

15

Y

DateTime

The date and time of the meter read.

MR_UP_STATUS_FLG

2

Y

A/N

This must be set to P for Pending .

MR_ID

12

N

N

Leave this column blank. It will be assigned by the system when it creates a meter read record.

MR_SOURCE_CD

12

N

A/N

The source of the meter read.

GEO_TYPE_CD

8

N

A/N

See the description of the GEO_VAL field.

GEO_VAL

50

N

A/N

This field along with GEO_TYPE_CD are used to uniquely identify the service point at which the meter read takes places. These fields are only necessary if you have duplicate BADGE_NBR's and you have uniquely identified your service points (with a unique GEO_TYPE_CD and GEO-VAL - e.g., a universal id). It's important to note that you must also specify the BADGE_NBR along with the GEO_TYPE_CD and GEO_VAL.

MTR_ID_TYPE_CD

5

N

A/N

See the description of the MTR_ID_NBR field.

MTR_ID_NBR

30

N

A/N

This field along with MTR_ID_TYPE_CD are used to uniquely identify the meter being read. These fields are only necessary if you do not use the meter's BADGE_NBR's or the meter's MTR_CONFIG_ID to identify the meter.

If specified, this must correspond with a meter ID type / value associated with one of your meters.

USE_ON_BILL_SW

1

Y

A/N

Indicates if the read can be used on a bill. Valid values are Y or N . Note, if the register read's REVIEW_HILO_SW is Y and if the register read fails high/low review, the USE_ON_BILL_SW may be set to N if the Use High/Low Failures on Bill is turned on in the installation record.

MTR_READER_ID

20

N

A/N

The ID of the meter reader identified by the Meter Read Source, if supplied.

Upload Register Read

You must create an upload register read record for each meter that was read. The name of this table is CI_RR_STAGE_UP . The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

MR_STAGE_UP_ID

12

Y

A/N

This must correspond with the prime key of the related CI_MR_STAGE_UP record.

READ_SEQ

2

Y

N

This must correspond with a sequence number on the meter configuration's register.

READ_TYPE_FLG

2

Y

A/N

Set this to 20 if the meter was not read.

Set this to 60 if the meter read was performed, but not verified.

Set this to 70 if the meter read was performed and verified.

UOM_CD

4

Y

A/N

This must correspond with the unit of measure code on the register associated with this READ_SEQ. Refer to Setting Up Unit Of Measure Codes for more information.

TOU_CD

8

See note

A/N

If specified, this must correspond with the time of use code on the register associated with this READ_SEQ. Refer to Setting Up Time Of Use Codes for more information.

REG_READING

9.6

Y

N

This is the register's reading.

REVIEW_HILO_SW

1

Y

A/N

Indicates if the register reading should be subject to high / low review. Valid values are Y or N .

Upload Read Remark

You must create a meter read remark upload staging record for each remark that you would like to link to the meter read. The name of this table is CI_MRR_STAGE_UP . The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

MR_STAGE_UP_ID

12

Y

A/N

This must correspond with the prime key of the related CI_MR_STAGE_UP record.

READER_REM_CD

4

Y

A/N

This must correspond with a meter read remark code. Refer to Setting Up Meter Read Remarks for more information.

Upload Read Characteristics

You must create a meter read characteristic upload staging record for each characteristic that you want to link to the meter read. The name of this table is CI_MR_STGUP_CHAR . The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

MR_STAGE_UP_ID

12

Y

A/N

This must correspond with the prime key of the related CI_MR_STAGE_UP record.

CHAR_TYPE_CD

8

Y

A/N

This must correspond with a characteristic type that is defined as valid for meter read upload staging . Refer to Setting Up Characteristic Types & Their Values for more information

SEQ_NUM

3

Y

N

This should be set to 1 unless you have multiple values for a given meter read upload staging and characteristic type.

ADHOC_CHAR_VAL

254

N

A/N

Populate this field if your characteristic type is ad-hoc or file location .

CHAR_VAL

16

N

A/N

Populate this field if your characteristic type is predefined

CHAR_VAL_FK1 -

CHAR_VAL_FK5

50 (each)

N

A/N

Populate these fields if your characteristic type is a foreign key reference . Up to five columns of 50 bytes each are provided to accommodate compound keys.

MUP1 - Populate Meter Configuration

This process populates the meter configuration ID on all MR upload staging records that don't have a meter configuration ID.

Note: You don't have to know the meter configuration in order to interface a read into the system. Rather, you can specify a SP Geo Type and Value and/or a Meter Id Type and Value and/or the meter's badge number on the Upload Register Read record. MUP1 will search the system for each (in that order) until a unique match is found.

Any errors detected during this process are written to the MR Upload Exception table. You can fix errors using MR Upload Staging page (don't forget to change the record's status back to Pending ).

MUP2 - Create Meter Read

This process creates a meter read and register read for all MR upload records in the Pending state.

Any errors detected during this process are written to the MR Upload Exception table. You can fix errors using MR Upload Staging page (don't forget to change the record's status back to Pending ).

If a meter read fails high / low checks, the meter read will still be created, but it will be marked for review by the review meter reads for high / low background process ( TD-HILO).

In addition, whether a meter read that fails high / low is marked as usable on a bill is controlled by a switch on the installation record.

MRUP-PRG - Purge Meter Read Upload Objects

Completed meter read upload staging objects should be periodically purged from the system by executing the MRUP-PRG background process. This background process allows you to purge all Completed meter read 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 meter read upload objects that may exist. You can retain these objects for as long as you desire. However we recommend that you periodically purge Completed meter read upload objects as they exist only to satisfy auditing and reporting needs.

MR Upload Staging

The Meter Read Upload Staging page has three purposes:

- You can view historical meter read upload records.

- You can correct meter read upload records that are in error.

- You can add new meter read upload records to be uploaded by the meter read upload process.

Contents

MR Upload Staging - Main

MR Upload Staging - Remarks

MR Upload Staging - Characteristics

MR Upload Staging - Main

To view the details of a meter read upload record, open Meter Read, MR Upload Staging.

Description of Page

MR Upload Staging ID is the system-generated unique identifier of the staging record.

The Meter ID Type Code identifies what type of Meter ID is listed in the upload record. This along with the Meter ID Number will help the system to identify the correct meter.

The Badge Number is the meter's badge number.

The Meter ID Number acts as an alternative identifier for the meter in case the badge number is not known or not unique. This along with the Meter ID Type Code will help the system to identify the correct meter.

Read Date / Time are just that.

Use on Bill is used to indicate whether or not the uploaded meter read may be used by billing.

Upload Status shows the state of the meter read upload record. Potential values are: Pending , Complete , Error . Set the value to Pending for any record that should be processed the next time the meter read upload process runs.

Meter Read ID is the system-assigned, unique identifier of the related meter read. This value is populated after the meter read upload process creates a meter read for the meter read upload record.

Use Meter Read Source to define the source (e.g., the reader, the reading agency, etc.) of the read.

Meter Configuration ID is the meter configuration that was read. If this field is left blank, it will be populated by MUP1 - Populate Meter Configuration during the meter read upload process (the system uses the Badge Number to do this).

Use Meter Reader for the ID of the person that read the meter.

If the read is interfaced from an external meter read agency, you can use Geographic Type and Geographic Value to identify the service point at which the read took place. If this value is specified, the system will look for a service point with the given type and value that has a meter currently installed at it with the specified Badge Nbr. This facility is useful if you have duplicate badge numbers but have uniquely identified your service points (e.g., with a universal ID).

The scroll that follows contains the register reading(s). The following information is displayed.

Read Sequence This must correspond with a sequence number on the meter configuration's register.

Read Type Use this field to define WHO made the read and HOW the read was made. The value of this field is important because it affects which meter read will be used by billing if multiple reads exist during a billing period. Refer to the Description of Page under Meter Read - Main for the list of valid values.

Unit Of Measure This must correspond with the unit of measure code on the register. Refer to Meter Configuration Maintenance for more information.

Time of Use If specified, this must correspond with the time of use code on the register. Refer to Meter Configuration Maintenance for more information.

Register Reading This is the register's reading.

Hi/Low Review Indicates if the register reading should be subject to high / low review.

MR Upload Staging - Remarks

To view remarks associated with a meter read upload record, open Meter Read, MR Upload Staging, Remarks.

Description of Page

The Meter Reader Remark grid is used to record anomalies associated with the reading.

MR Upload Staging - Characteristics

To maintain meter upload characteristics, open Meter Read, MR Upload Staging, Characteristics.

Description of Page

MR Upload Staging ID is the system-generated unique identifier of the staging record.

The Characteristics collection contains information that describes miscellaneous information about meter upload staging.

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.

MR Upload Exception

If errors are detected during the meter read upload process, a record is written to the MR 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-MRUPL background process. This process generates a To Do entry for every record in the MR upload exception table.

You can fix this error using the MR Upload Staging page and change the status of the remark from Error to Pending . When the meter read upload process next runs, it attempts to upload this record again.

TD-HILO - To Do for Meter Read High/Low Errors

This process creates To Do entries for each meter read that has at least one register read that failed high / low using the To Do Type TD-HILO .

The process first attempts to complete old To Do entries. If the NO-OF-DAYS parameter is populated, all Open entries of this To Do Type whose create date is before the business date minus this input parameter value are completed.

For each register read linked to the meter read that has review high / low set to Y, the process attempts to classify the reading as "very low", "low", "high" or "very high".

Determine the reading's consumption

- If the register is subtractive, retrieve the previous reading and calculate the difference between the register reading and the previous reading (taking into account rollover).

- Otherwise, the reading is the consumption.

Calculate the following

- Low limit consumption = the difference between the previous reading and the low limit on the current reading.

- High limit consumption = the difference between the previous reading and the high limit on the current reading.

Contents

Low / Very Low

High / Very High

Set Use On Bill

Multiple Register Priority

Create ToDo Entry

Low / Very Low

If the reading's consumption is less than the low limit consumption, compute the low percentage =

((Low limit consumption - Reading's consumption) / Low limit consumption) * 100, round to the nearest integer.

If the low percentage is less than or equal to the input VERY-LOW-PERCENTAGE-CUTOFF, the reading is considered "very low", otherwise it is considered "low".

High / Very High

If the reading's consumption is greater than the high limit consumption, compute the high percentage =

((Reading's consumption - High limit consumption) / High limit consumption) * 100, round to the nearest integer

If the high percentage is greater than or equal to the input VERY-HIGH-PERCENTAGE-CUTOFF, the reading is considered "very high", otherwise it is considered "high".

Set Use On Bill

The parameters USE-ON-BILL-VERY-LOW-READS, USE-ON-BILL-LOW-READS, USE-ON-BILL-VERY-HIGH-READS and USE-ON-BILL-HIGH-READS indicate how to set the Use On Bill flag for the meter read based on the classification of the register readings.

If ANY of the register reads that failed high / low should not be used on bill according to the appropriate input parameter flag, then the meter read's Use On Bill flag is set to N . It is only set to Y if all register reads can be used on a bill based on the input parameters.

Multiple Register Priority

If there are multiple register readings for the meter read that failed high low and the readings have different classifications of "very low", "low", "high" or "very high", determine the "worst" register read based on the value of MULTIPLE-REGISTERS-PRIORITY. The register read considered the "worst" is the one used to create the To Do entry.

The value of this parameter indicates how to prioritize multiple registers with different classifications. The first byte indicates the priority of "very low" reads, the second byte indicates the priority of "low" reads, the third byte indicates the priority of "high" reads and the fourth byte indicates the priority of "very high" reads. Use the numbers 1, 2, 3 and 4, where 1 is the worst type of reading (i.e., the one that needs the most attention). For example, if you would like to review reads in the following order

- Very low

- Very high

- Low

- High

Set the value of MULTIPLE-REGISTERS-PRIORITY to 1342.

Create ToDo Entry

Create a To Do entry for the "worst" register read linked to the meter read (determined in the previous section). The To Do type is set to TD-HILO. This section describes the sort fields because they are a bit unusual.

- If the reading is less than the low limit:

- If the low percentage is <= VERY-LOW-PERCENTAGE-CUTOFF, create a sort field where:

- Sort sequence number = 1 (associated with the "very low percentage" sort field)

- Sort key value = low percentage (calculated above)

- If the low percentage is > VERY-LOW-PERCENTAGE-CUTOFF, create a sort field where:

- Sort sequence number = 2 (associated with the "between low and very low percentage" sort field)

- Sort key value = low percentage

- Calculate the low amount. This value is a positive number and equals the low limit's consumption - read's consumption

- Sort sequence number = 3 (associated with "low amount" sort field)

- Sort key value = low amount

- If the reading is greater than the high limit:

- If the high percentage is >= VERY-HIGH-PERCENTAGE-CUTOFF, create a sort field where:

- Sort sequence number = 4 (associated with the "very high percentage" sort field)

- Sort key value = high percentage (calculated above)

- If the high percentage is < VERY-HIGH-PERCENTAGE-CUTOFF, create a sort field where:

- Sort sequence number = 5 (associated with the "between high and very high percentage" sort field)

- Sort key value = high percentage

- Calculate the high amount. This value is a positive number and equals the read's consumption -high limit's consumption

- Sort sequence number = 6 (associated with "high amount" sort field)

- Sort key value = high amount

- Sort sequence 7 equals the low or high amount

- Sort sequence 8 equals the bill date on/after the current date that linked to a bill cycle associated with accounts linked to the reading's meter configuration's non-abolished service points' non-canceled / non-closed service agreements.

Note: Conditional Sort Fields. The creation of certain sort fields for the entry is conditional. This is unusual, as we have never suppressed a sort field before (i.e., every To Do entry of a given type has referenced every sort field). However, this allows the user to only view certain To Do entries on To Do List when choosing certain sort fields.

Review High / Low

In order to review register reads that failed high / low checks when they were uploaded to the system, you must run an appropriate background process that creates To Do entries. The system supplies the background process TD-HILO. If this process doesn't satisfy your implementation's business requirements, you may create your own.

CAUTION:

Register reads entered online that fail high / low checks are not marked for high / low review because we assume the user who entered the read was apprised of the failure when the read was initially entered. This means that only reads that failed high / low checks during the meter read upload background process are marked for high / low review.

When reviewing a To Do entry for a register read that has failed high / low, you may choose to do one of the following:

- Update the value of Use on Bill on the meter read page. If a read fails high / low checks during the meter read upload, the system sets the Use On Bill switch as per the value defined on Installation Options. A user investigating a high / low error may choose to override the default value.

- Request that the meter be read again. On the meter read page a Reread Meter button is available if you want to generate a field activity to reread the meter. The field activity type is defined on the meter's service point's SP type's field activity type profile.

- Determine that the reading is ok and nothing else should be done.

In any case, in order to ensure that the register read does not appear on a To Do entry again, update the Review High / Low switch on the meter read page to unchecked when completing your review.

Field Order

In this section, we describe how to manage the fieldwork that takes place at your premise's service points.

Contents

The Big Picture Of Field Orders

Field Order Maintenance

Field Activity Maintenance

Group Premise FAs (Field Activities)

Field Order Search

Dispatch Field Activities

Downloading Field Orders

Uploading Field Order Completion Information

Outage Calls

Outage Information

The Big Picture Of Field Orders

The topics in this section provide background information about a variety of field order issues.

Contents

An Illustration Of A Field Order And Its Field Activities

An Illustration Of The Entities Involved In Field Order Dispatch

Field Activity Type Controls What Is Done In The Field

The Lifecycle Of Field Activities And Field Orders

Dispatch Field Activities Automatically

The Daily Tasks Of A Dispatcher

How To Handle Unusual Situations

Printing Field Orders

An Illustration Of A Field Order And Its Field Activities

Fastpath:

Refer to An Example Of A Field Order for an overview of the field order objects.

An Illustration Of The Entities Involved In Field Order Dispatch

Fastpath:

Refer to An Example Of The Entities Involved In Field Order Dispatch for an overview of the objects involved in the dispatch of field orders.

Field Activity Type Controls What Is Done In The Field

Fastpath:

For information about field activity types, refer to Designing Your Field Activity Profiles & Types. For more information about field activity completion, refer to How Does A Field Order Get Completed?.

The Lifecycle Of Field Activities And Field Orders

The following diagram illustrates the lifecycle of a typical field activity and its field order.

The above diagram is referenced in the following topics.

Contents

How Are Field Activities Created?

How Are Field Orders Created And Dispatched?

How Does A Field Order Get Routed To A Field Crew?

How Does A Field Order Get Completed?

What Happens After A Field Activity Is Completed?

How To Schedule Appointments

How Are Field Activities Created?

Field activities are created as follows:

- Starting or stopping service indirectly causes field activities to be created to perform the fieldwork necessary to connect or disconnect service. Refer to Starting Service & Field Activities for more information about how field activities are created to start and stop service. Note, if you use the Order transaction to start service, field activities will also be created in the same manner described under the Starting Service & Field Activities discussion.

- The activation of a severance event with fieldwork causes field activities to be generated to disconnect or reconnect service. For more information about severance events and field activities, refer to The Big Picture Of Severance Events.

- When an operator indicates that a reread should be done for a meter read that fails high/low, a field activity is created. For more information about this process, refer to Review High / Low.

- An algorithm may be designed to generate a field activity. For example, perhaps the activation algorithm for a workflow event creates a field activity. Or perhaps a field activity is created as a result of a meter read remark algorithm.

- An operator may create a field activity at their discretion. This is done for ad hoc service investigation orders. For more information about creating an ad hoc field activity, refer to Field Activity Maintenance.

In the above diagram, the event that takes place on 13-Dec-98 shows two field activities created to start service for a customer on 15-Dec-98. Notice that the activities are not linked to a field order when they're first created. Why? Because field activities exist in a state of limbo awaiting dispatch. At dispatch time, a field order is created and one or more field activities are linked to it.

Creating a field activity before a field order may seem counter-intuitive to you. If so, consider that a field activity is created to perform work at a service point ON SOME FUTURE DATE. Close to the date, a dispatcher will look at all field activities to be performed by a given dispatch group at a premise and group them together under a field order.

How Are Field Orders Created And Dispatched?

The illustration above shows that on 14-Dec-98, a field order is created using the Dispatch Field Activities transaction. This transaction is one of several ways in which a field order can be created. The following point describe every possible way in which a field order can be created:

- The Dispatch Field Activities page allows a user to create (and dispatch) field orders for pending field activities.

- The Group Premise Field Activities page allows a user to create (and dispatch) field orders for field activities at a premise.

- The Automatic Dispatch background process automatically creates field orders for field activities.

- A user may create a field order and link field activities to it using the Field Order page.

After a field order is created, it's ready to be downloaded to the crew who does the work. Refer to How Does A Field Order Get Routed To A Field Crew for the details.

How Does A Field Order Get Routed To A Field Crew?

Refer to Downloading Field Orders for a description of how field orders are routed to field crews.

How Does A Field Order Get Completed?

When fieldwork is performed at a service point, the system must be told what happened. We refer to the process of telling the system what happened in the field as "field order completion".

Note:

Between dispatched and completed states. If you want, you can indicate a field order's fieldwork is done before you actually complete the field order. You do this by changing the field order's status from dispatched to work done, not recorded . You don't have to do this; it's really a question of whether you care about this intermittent state.

You can't complete a field order until all of its non-optional activities are either Complete or Canceled . To complete a field activity, you update the system to reflect what happened in respect of the activity's steps. After which, you must have each step reference the object that was updated or created. For example, if a step initiated the installation of a meter at a service point, you must add a new SP/Meter Installation History record and the step should then reference the new SP/Meter Installation History record.

You may wonder why a step needs to reference the object that was updated or created. The reason is a little complex, but it's important you understand the following points:

- After you complete a field activity that is linked to a pending start service agreement, the system automatically activates the service agreement. As part of the activation, if the service point is metered, the system extracts any read that was entered to complete the field activity and uses this as the initial read for the service point. The system extracts the meter read by looking for reads linked to the activity's step(s). Reads may be linked directly (via a reference to a meter read), or indirectly (via a reference to SP/Meter History). If the step doesn't reference a meter read, the system cannot automatically activate the related service agreement when the field activity is completed.

- An analogous process occurs for field activities linked to pending stop service agreements. The major difference is that the system uses any read linked to the field activity as the service agreement / service point's final read.

- Steps on field activities that are not linked to pending start or stop service agreements exist purely for audit purposes.

The following diagram may help understand the relationship between an activity's read and the service agreement(s) that use the read to start or stop service.

The next thing you may be wondering about is how to reference the updated or created object on a step? There are three ways to do this:

- You can enter completion details on the field activity page. Refer to Field Activity Maintenance for more information.

- An operator can enter completion details on the field activity upload staging pages. Refer to Field Activity Upload Staging for the page used to do this. This is the easiest way to complete a field activity.

- You can have your interface team insert rows onto the field activity upload staging tables and let the field activity upload background process complete the activities and orders for you. Refer to Uploading Field Order Completion Information for more information about the batch completion process.

Completing most field activities is straightforward because the steps performed in the field correspond to the steps on the field activity. Complications arise if a field crew is unable to perform an activity's steps because of any number of reasons (e.g., a field activity instructs a meter to be installed but there's already a meter at the service point). When what took place in the field differs from what was instructed to take place the operator may either:

- Change the activity type on the activity to reflect what happened.

- Cancel the existing field activity and add a new one with the appropriate activity type.

Warning:

If a field activity is linked to a service agreement or a severance event, and what took place in the field isn't consistent with the field activity's steps, we recommend changing the activity type rather than canceling the field activity and adding a new one. Why? Because the object to which a field activity is linked continually checks if the field activity is complete to see if it can take the next logical step in its lifecycle. If you add a new field activity, you'll need to link it to the same object(s) that the original activity was linked. This is a cumbersome process (but possible). It's much easier to simply change the activity's activity type.

What Happens After A Field Activity Is Completed?

After you complete a field activity that is linked to a pending start service agreement, the system automatically activates the service agreement. As part of the activation, if the service point is metered, the system will extract any read that was entered to complete the field activity and use this as the service agreement / service point's initial read.

An analogous process occurs for field activities linked to pending stop service agreements. The major difference is that we use any read linked to the field activity as the service agreement / service point's final read.

After a field activity that is linked to a severance event is completed, the severance event becomes complete. This, in turn, triggers the activation of the next event.

Fastpath:

For more information about field activities linked to pending starts, refer to Starting Service & Field Activities. For more information about field activities linked to pending stops, refer to Stopping Service & Field Activities . For more informationabout what happens when a field activity that is linked to a pending start or pending stop service agreement is completed , refer to The System Activates Most Service Agreements Behind-The-Scenes and The System Finalizes Most Service Agreements Behind-The-Scenes. For more information about severance events and field activities, refer to The Big Picture Of Severance Events.

How To Schedule Appointments

Refer to The Big Picture of Appointments for information about how appointments can be scheduled for field activities.

Dispatch Field Activities Automatically

For large volumes of field activities, it can be useful for the dispatching and extraction of field activities and field orders to be automated.

Dispatching refers to the processes of grouping field activities into related groups by premise and date, etc. The automatic dispatch job ( FOD ) selects all pending field activities that:

- are not yet connected yet to a FO,

- have a dispatch group,

- are linked to dispatchable FA Type

- have a schedule date <= today's date + a specified dispatch ahead days AND have a priority = a specified priority (if specified).

The selected field activities are grouped by premise, dispatch group (or alternate dispatch group from the dispatch group table), and date. A field order is created and the grouped field activities are linked to it. The field order will be dispatched on the designated date.

For example, imagine the following field activities:

Field Activity

Dispatch Group - Primary

Dispatch Group - Alternate

1

GSR1

TM1

2

GSR2

GSR1

3

TM1

TM2

4

TM2

MT

5

MT

MT

For this set of field activities, the process will group FA 1 and FA 2 based on GSR1, FA 3 and FA 4 based on TM2 and FA 5 will have its own FO.

The rules are:

- Look at the primary dispatch group and try to find a match in the primary or alternate for the other field activities.

- If no match is found, look at the alternate dispatch group and try and match with the primary or alternate for the other field activities.

- If no match is found after step 1 and 2, a separate field order must be created.

Fastpath:

Refer to Process What's Ready Processes for more information on the batch process.

The Daily Tasks Of A Dispatcher

In this section, we describe how a dispatcher performs his/her daily tasks.

Contents

Dispatching Field Activities

Marking Field Orders As Being Worked

Look For Orders That Have Slipped Through The Cracks

Dispatching Field Activities

Late in the day, you should review field activities that are scheduled for the next day. A special query exists, Dispatch Field Activities , that shows you all pending field activities that are not linked to field order. From this query, you can define which field activities should be dispatched. The system then creates and dispatches a field order for each unique combination of premise and dispatch group on the selected field activities.

Fastpath:

Refer to How Are Field Orders Created And Dispatched for other ways to dispatch field activities.

Marking Field Orders As Being Worked

If your organization is told about field orders that have been worked during the day, you can change the status of such field orders to work done, not recorded . You use Field Order - Main Information to do this.

Look For Orders That Have Slipped Through The Cracks

Occasionally, you should use the Field Order Search to check if any field orders have been pended by operator for too long. You see, if a user appends a field order, at some point they need to either cancel it or dispatch it. If they don't, the order will sit in limbo forever.

You should also use this query to check for work done, not recorded orders in case someone forgot to complete them.

How To Handle Unusual Situations

In this section, we describe how to handle unusual situations.

Contents

Tidying Up Field Orders That Were Not Worked

Hold A Field Activity

Canceling A Field Activity

Tidying Up Field Orders That Were Not Worked

Sometimes unforeseen events occur and a crew can't work all of their field orders. When this happens, you have two options:

- You can leave the field order in the state of dispatched and give it to the same crew to do the next day.

- You can change the state of the field order to pended by operator , reassign the field order to another dispatch group or representative, and then change the status back to dispatched . This will cause the field order to be dispatched a second time. You use Field Order - Main Information to do this.

Hold A Field Activity

Sometimes you might want to hold a field activity that was automatically generated by the start/stop/severance processes. Holding an activity prevents it from appearing on the Field Activity Dispatch query (and therefore it shouldn't get dispatched).

At some point in the future, you should either cancel the activity (if you don't want it done) or reset the activity to pending .

Canceling A Field Activity

You should cancel a field activity if it shouldn't be (or wasn't) done.

There are situations when a field activity may be canceled automatically by another process in the system, for example:

- If a field activity is created by start/stop and the start/stop is canceled, the resulting field activity is also canceled

- If a field activity is created by a severance event or cut event and the severance or cut event is canceled, the field activity is also canceled

The processes that attempt to cancel a field activity when a related record is canceled do not continue with the cancel under the following conditions:

- The field activity is already linked to a field order (and is therefore considered dispatched to the field)

- The field activity has been dispatched to an external system and the FA's intermediate status is one that does not allow auto-cancellation.

Printing Field Orders

The contents of this section describe the technical implementation of field order production.

Contents

Dispatch Groups Control The Information Merged Onto Field Orders

Technical Implementation Of Online Field Order Image

Technical Implementation Of Batch Field Order Production

Reproducing The Field Order Print Flat File

How To Reprint A Specific Field Order

Who Gets A Copy Of A Field Order?

The Documaker Records

Dispatch Groups Control The Information Merged Onto Field Orders

Every field order references a dispatch group. The dispatch group controls the following field order print functions:

- It contains an algorithm that is responsible for extracting the information merged onto your field orders. Algorithms of this type are called under the following scenarios:

- The background process that interacts with your field order print software calls these algorithms.

- If your field order print software has the ability to construct a real-time image of a field order, you can plug-in an Online Field Order Image algorithm on the Installation Record. This type of algorithm will call the field order's dispatch group extract algorithm to extract the information that is merged onto the field order. Refer to Technical Implementation Of Online Field order Image for the details.
Refer to The Documaker Records for examples of the record layouts passed to the Documaker print software.

- It contains the ID of the background process responsible for interacting with your field order print software in batch.

Technical Implementation Of Online Field Order Image

Users can view an image of any field order if you setup the following:

- Plug-in an Online Field Order Image construction algorithm on the Installation Record.

- Plug-in the appropriate extract algorithm on each dispatch group.

The system provides algorithms that interact with print software that renders an image of the field order in a PDF. The following points describe what takes place when clicking Display Field Order when these sample algorithms are used.

- The sample Online Field Order Image algorithm C1-FO-DISP is executed.

- This algorithm calls the field order's dispatch group's extract algorithm. The sample field order extract algorithm C1-FOEX-OX constructs the information that's merged onto the field order and returns it to the Online Field Order Image algorithm. This algorithm, in turn, passes it to your field order print software.

- Your field order print software renders an image of the field order in a PDF and returns it to the Online Field Order Image algorithm. Note that the client must have Adobe Acrobat Reader installed to view PDF files.

- And finally, the Online Field Order Image algorithm displays the PDF in a separate Adobe session.

The system provides an algorithm that interacts with BI Publisher to render an online image of your field order. The following points describe what takes place when clicking Display Field Order when these sample algorithms are used.

- The sample Online Field Order Image algorithm C1-ONFD-CR is executed.

- This algorithm calls the field order's dispatch group's extract algorithm. The sample field order extract algorithm C1-FOEX-CR is supplied for displaying field orders via BI Publisher. This is not actually extracting data because when you use BI Publisher reports, the report itself is responsible for extracting and formatting the data. The base product algorithm supplied returns the appropriate report code to the Online Field Order Image algorithm, which in turn returns the report code to the field order page.

- A user exit on the field order page invokes BI Publisher and displays the field order in a separate browser session.

Fastpath:

Refer to Field Order Print in BI Publisher for examples of the data extracted for the report.

Technical Implementation Of Batch Field Order Production

A batch process extracts field order information reads all field orders 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 FODL) simply calls the extract algorithm on the dispatch group to format the information placed onto the flat file. Refer to Dispatch Groups Control The Information On Field Orders for more information on the base processing.

Note:

If your software doesn't support online field order images. The algorithm that formats field order extract records that's plugged in on dispatch group serves two purposes: 1) it interacts with the online field order image algorithm plugged into to the installation record to support online images of a field order, and 2) it interacts with the background process to support printing your field orders in batch. If your field order print software does not support the rendering of field order 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 field order print software to print field orders in batch (and then specify this batch process on your dispatch group).

Reproducing The Field Order Print Flat File

If you use the method of extracting to a flat file, you can reproduce the flat file at any time. Simply request the FODL process and specify the run number associated with the historic run.

How To Reprint A Specific Field Order

If you need to reprint a specific field order, navigate to Field Order - Main Information and change the order's status to Dispatched .

If your implementation has enabled the online creation of field order images, you can also click the Display Field Order button on this page and then print the resultant online image on your local printer.

Who Gets A Copy Of A Field Order?

Fastpath:

Refer to The Lifecycle Of Field Activities And Field Orders for more information.

The Documaker Records

Note:

Alternate print / routing methods. This section describes the format of field order extract records that are constructed by base-package algorithms that are passed to the Documaker software (which actually produces the field orders). If you require different print formats, you must create new extract algorithms and plug them in on your dispatch groups.

Numerous types of records are interfaced to the Documaker software. However, they all share a common structure for field orders:

- The first 4 bytes are called the Printer Key. This field is a record type used by the Documaker field order template.

- The next 187 bytes are called the Sort Key. This field is used to ensure the various records used to construct a printed field order appear in the correct order in the interface file.

- The remaining bytes contain the Field Order Information that appears on the printed field order. The type of information differs for each type of record.

The topics in this section describe each component.

Contents

Printer Keys (Record Types)

Sort Key

Field Order Information

Printer Keys (Record Types)

The following table defines each printer key (i.e., record type) on the field order print flat file.

Record Type

Description

Notes

0010

Global extract information

Required. 1 per flat file.

0100

Field Order record

Required. 1 per field order.

2000

Service Point record

Required. N per FO.

2200

Item record

1 per SP.

2400

Meter record

1 per SP.

2450

Register record

N per SP.

2490

End Meter record

1 per SP (dummy).

2600

SP/Multi-item record

1 per SP.

2620

Multi-item Detail record

N per SP.

2690

End SP/Multi-item record

1 per SP (dummy).

3000

Field Activity record

Required, Occurs N.

3100

Field Activity Credit & Collections record

1 per FA.

3200

Field Activity Step record

Required, Occurs N.

3410

Enter Meter Badge No

1 per FA Step (dummy).

3430

Enter Item Badge No

1 per FA Step (dummy).

3450

Enter Cust. Contact Info

1 per FA Step (dummy).

3470

Enter Reconfig. Register

1 per FA Step (dummy).

3490

Enter Discon. Loc. Info

1 per FA Step (dummy).

3510

Enter Register Read

1 per FA Step (dummy).

3530

Enter Multi Item Info

1 per FA Step (dummy).

3550

Enter TO Statistics Info

1 per FA Step (dummy).

3570

Enter Misc Changes Info

1 per FA Step (dummy).

3999

Generic (placeholder)

1 per FA Step (dummy).

6100

End Field Activity Step record

Required. 1 per FA Step (dummy).

6200

End of Field Activity record

Required. 1 per FA (dummy).

6300

End of Service Point record

Required. 1 per SP (dummy).

9990

End of Field Order record

Required. 1 per FO (dummy).

Sort Key

The field order print records need to be sorted in the right sequence in order for Documaker to process them. The following is a description of the portion of each record that is responsible for performing this task.

Note that the first ten fields in the Sort Key - DISP_GRP_CD through FO_ID - are all from the CIS database records. For each Field Order in an extract run, there will be a "block" of records of indeterminate size in which the values of these first ten fields will be identical. These ten fields see to it that each block is sorted correctly within the extract as a whole. It is the task of the last six fields to make certain that the records in a particular Field Order's block are sorted correctly within the block. Most of these six are artificial, but two are from the CIS database, where they serve a similar function.

The precise mechanics of the Sort Key (in particular the three-in-one Sequence Number field) may be difficult to envision. A look at the Order of Record Types section above may help to make it clearer. Within a given Field Order (FO) block there are several sub-groups. Not only must each sub-group as a whole be in the proper sequence within the FO block, but each record in a sub-group must be in the proper sequence within the sub-group. These sub-groups are Service Point (one or more per FO with one or more Field Activities at each SP), Meter (a Meter and its Registers), Multi-Item (a Multi-Item record and its Detail Lines), and Field Activity (a Field Activity record and its various Steps).

The following table defines the structure of the sort key that appears on each field order print record. Please note that different components are filled in for each printer key.

Field Name

Format

Source/Value/Description

DISP_GRP_CD

A8

CI_FO / Dispatch Group code

REP_CD

A8

CI_FO / Representative code

STATE

A6

CI_PREM / State of the Premise address

CITY

A30

CI_PREM / City of the Premise address

POSTAL

A12

CI_PREM / Postal Code of the Premise address

ADDRESS1

A64

CI_PREM / 1 st line of the Premise street address

PREM_ID

A10

CI_FO / System-assigned identifier for the Premise

SCHED_DT

D10

CI_FO / Scheduled date of the Field Order

SCHED_TM

T15

CI_FO / Scheduled time of the Field Order

FO_ID

A10

CI_FO_STG_DWN / System-assigned identifier of the Field Order

FO Group [Artificial]

N2

This field forces the Service Point record group(s) into a position subordinate to the Field Order. Values:

10 - Field Order

30 - SP

90 - End Field Order

SP Sequence [Artificial]

N2

If there is more than one Service Point on a particular FO, this field forces them into an arbitrary sequence. Each SP is then followed by its device and Field Activity record group(s).

SP Group [Artificial]

N2

This field forces the device (meter, item or multi-item) and Field Activity record groups into a position subordinate to the Service Point. Values :

10 - SP

20 - Item

30 - Meter

35 - End Meter

40 - Multi-Item

45 - End Multi-Item

50 - FA

60 - End SP

Sequence Number

READ_SEQ

[Artificial]

[Artificial]

N3

This field serves the same purpose in three distinct areas:

Register Sequence (within a Meter record) (CI_REG)

Item Sequence (within a Multi-Item record)

FA Sequence (within a Service Point)

In each instance, it forces the subordinate records into the correct order within, respectively, the Meter, Multi-item and Service Point record sub-groups.

STEP_SEQ_NBR

N3

CI_FA_STEP

In addition to the "natural" values from the CIS database, there are two artificial values that serve to force a particular record into its proper place within the FA sub-group:

000 - Credit & Collections record

999 - End FA record

FA Step Group [Artificial]

N2

Each FA Step will have one or more FA Step (action) records. This field is to force these records into an arbitrary sequence within the FA sub-group. Values :

10 - Enter Meter Badge Number

20 - Enter Item Badge Number

30 - Enter Customer Contact

40 - Enter Reconfigure Register

50 - Enter Disconnect Location

60 - Enter Register Reading

70 - Enter Multi-item

80 - Enter Trouble Order Statistics

90 - Enter Changes

98 - Generic (placeholder)

99 - End FA Step

Field Order Information

The topics in this section describe the information that appears on each field order print record.

Contents

Global Information Record

Field Order Record

SP Record

Item Record

Meter Record

Register Record

End Meter Record

SP/Multi-Item Record

Multi-Item Detail Line Record

End SP/Multi-Item Step Record

Field Activity Record

Credit and Collection Record

Field Activity Step Record

Field Activity Step (Enter Meter Badge Number) Record

Field Activity Step (Enter Item Badge Number) Record

Field Activity Step (Enter Customer Contact) Record

Field Activity Step (Enter Reconfigure Register) Record

Field Activity Step (Enter Disconnect Location) Record

Field Activity Step (Enter Register Read) Record

Field Activity Step (Enter Multi-Item) Record

Field Activity Step (Enter TO Stat) Record

Field Activity Step (Enter Changes) Record

Field Activity Step (Generic) Record

End Field Activity Step Record

End Field Activity Record

End SP Record

End Field Order Record

Definition of Address Subrecord (Sbr)

G lobal Information Record

This is a "header" record that contains information about the extract run as a whole.

Note:

Please be aware that if you do not sort your extract file by CIS Sort Key after it is produced, this record will physically be the last record on the extract file.

Field Name

Format

Source/Value/Description

Print Key

A4

"0010"

CIS Sort Key

A187

Note: For the Global Record only, the Sort Key is all blanks.

BATCH_CD

A8

CI_BATCH_INST / The CIS Batch Process that called the FO Extract COBOL routine

BATCH_NBR

N10

CI_BATCH_INST / A sequence number for serial instances of a Batch Process over time

BATCH_RERUN_NBR

N10

CI_BATCH_INST / The number of times a particular batch has been re-run since its initial run

FO Count [Artificial]

N10

Total number of distinct FO record blocks in an extract

Date/Time [Artificial]

A26

System time of extraction.

FO Id Start [Artificial]

A10

The lowest valid FO ID in a particular thread in the extract. If there is only one thread, this will be '0000000000'.

FO Id End [Artificial]

A10

The highest valid FO ID in a particular thread in the extract. If there is only on thread, this will be '9999999999'.

BATCH_THREAD_NBR

N10

CI_BATCH_THD / Identifies a thread distinctly within a group of threads

Thread Count [Artificial]

N10

Total number of threads in the extract run

F ield Order Record

One record is produced for every field order to be printed.

Field Name

Format

Source/Value/Description

Print Key

A4

"0100"

CIS Sort Key

A187

FO_ID

A10

CI_FO_STG_DWN / System-assigned identifier for a Field Order

PREM_ID

A10

CI_FO / System-assigned identifier for the Premise at which the Field Order will be done

SCHED_DT

D10

CI_FO / The scheduled date of the Field Order

SCHED_TM

T15

CI_FO / The scheduled time of the Field Order (optional)

DISP_GRP_CD

A8

CI_FO / The Dispatch Group to which the Field Order has been assigned

REP_CD

A8

CI_FO / The Representative within the Dispatch Group

DESCR254

C254

CI_FO / Free-form notes about the Field Order

ACCT_ID

A10

CI_SA / The Account that is/has been/will be paying for services at the Premise

ENTITY_NAME

A64

CI_PER_NAME / The Primary name of the Main customer on the Account identified above

Multiple Account Message [Artificial]

A10

A message item indicating the existence of more than one active Account associated with a Premise.

ADDRESS_SBR

A361

CI_PREM / A sub-record of address information (Defined in detail later in this section)

MR_WARN_CD

A4

CI_PREM / Meter Read Warning code

DESCRIPTION

A60

CI_MR_WARN / Description of the MR Warning code

MR_INSTR_CD

A4

CI_PREM / Meter Read Instruction code

DESCRIPTION

A60

CI_MR_INSTR / Description of the MR Instruction code

MR_INSTR_DETAILS

A250

CI_PREM / For an expanded version of the Meter Read Instruction above, or for information deemed relevant but for which no code exists.

Telephone Info

Telephone numbers for the Main customer on the Account above. Occurs 3 times per FO Record, consisting of the following three fields:

PHONE_TYPE

A12

CI_PER_PHONE / The type of telephone. Typical values are Home, Business, Dormitory, Cellular, Fax.

PHONE

A24

CI_PER_PHONE / Self-explanatory

EXTENSION

A6

CI_PER_PHONE / Self-explanatory

LS_SL_SW

A1

CI_PER / Life Support or Sensitive Load. Set to "Y" if any Person on any active Account associated with this Premise has this type of information on their record.

LS_SL_DESCR

A254

CI_PER / Description of the Life Support/Sensitive Load

LL_ID

A10

CI_PREM / System-assigned identifier for a Premise's landlord (if one exists)

DESCRIPTION

A60

CI_LANDLORD / Description of the Landlord

ACCT_ID

A10

CI_LANDLORD / The Landlord's account number

Geographic Info

Geographic locator types and their values for the Premise. Occurs 3 times per FO Record, consisting of the following two fields:

DESCR

A60

CI_GEO_TYPE / The description of a geographic locator type

GEO_VAL

A50

CI_PREM_GEO / The actual value of the above locator type at a given Premise

S P Record

One record is produced for every Service Point (SP) that has a field activity on the field order. Up to 15 characteristics and their respective values can be listed for a SP. If there is no Characteristic information for the SP on the database, the fields will be blank.

Field Name

Format

Source/Value/Description

Print Key

A4

"2000"

CIS Sort Key

A187

SP_ID

A10

CI_SP / Unique system-generated identifier for the Service Point

SP_TYPE_CD

A8

CI_SP / The Service Point's type code

DESCR

A60

CI_SP_TYPE / The description of the SP Type

SP_SUBTYPE_FLG

A2

CI_SP_TYPE / The SP Type's sub-type code. Values:

M - Meter

I - Item

U - Unbadged (multi-item)

DESCR

A60

CI_LOOKUP / The description of the sub-type

SP_SRC_STATUS_FLG

A2

CI_SP / The status of the source of the service delivered through a Service Point.

DESCR

A60

CI_LOOKUP / The description of the source status

DISCON_LOC_CD

A4

CI_SP / If the SP has been disconnected, a code for the location of the disconnection

DESCR

A60

CI_LOOKUP / The description of the disconnect location

MTR_LOC_CD

A4

CI_SP / A code for the location at the Premise of the Service Point's Meter

DESCR

A60

CI_MTR_LOC / The description of the location code

MTR_LOC_DETAILS

A250

CI_SP / Detailed information regarding the location of the SP's Meter

SP_MTR_RD_CYCLE

A30

CI_MR_CYC / Description of the SP's Service Cycle

SP_MTR_RD_ROUTE

A30

CI_MR_RTE / Description of the SP's Service Route

SP_FAC_LVL_1

A30

CI_FAC_LVL_1 / Description of the SP's Level 1 Facility

SP_FAC_LVL_2

A30

CI_FAC_LVL_2 / Description of the SP's Level 2 Facility

SP_FAC_LVL_3

A30

CI_FAC_LVL_3 / Description of the SP's Level 3 Facility

Geographic Info

Geographic locator types and their values for a Service Point. Occurs 3 times per record, consisting of the following two fields:

DESCR

A60

CI_GEO_TYPE / The description of a geographic locator type

GEO_VAL

A50

CI_SP_GEO / The actual value of the above locator type at a given Service Point

Characteristic Info

Occurs 15 times per record, consisting of the following two fields:

SP_CHAR

A30

CI_CHAR_TYPE / The description of a Characteristic that the Service Point has been deemed to possess

SP_CHAR_VALUE

A30

CI_CHAR_VAL / The description of the Value of the above Characteristic for this Service Point

MR_WARN_CD

C4

Field Warning code

DESCRIPTION

C30

Description of the Field Warning code

MR_INSTR_CD

C4

Field Instruction code

DESCRIPTION

C30

Description of the Field Instruction code

MR_INSTR_DETAILS

C250

For an expanded version of the Field Instruction above, or for information deemed relevant but for which no code exists

I tem Record

This record is produced if a Service Point is of subtype Item. Because an SP may have at most one badged item installed at any given point in time, there is at most one record for an SP. If there is no Item currently installed, a message is printed to that effect.

Field Name

Format

Source/Value/Description

Print Key

A4

"2200"

CIS Sort Key

A187

ITEM_ID

A10

CI_SP_ITEM_HIST / The system-generated ID of the Item currently installed at the Service Point

BADGE_NBR

A16

CI_ITEM / The Item's badge number

ITEM_TYPE_CD

A8

CI_ITEM / A code specifying the type of the Item

DESCR

A60

CI_ITEM_TYPE / The description of the Item type

MFG_CD

A8

CI_ITEM / A code for the manufacturer of the Item

DESCR

A60

CI_MFG / The actual name of the manufacturer

MODEL_CD

A8

CI_ITEM / The manufacturer's model number for the Item

DESCR

A60

CI_MODEL / The description of the model

SERIAL_NBR

A16

CI_ITEM / Self-explanatory

RECEIVE_DT

D10

CI_ITEM / The date on which the Item was received by the utility from its manufacturer. This is NOT the install date.

DESCR254

A254

CI_ITEM / A detailed description of the Item (optional).

EVENT_DTTM

D26

CI_SP_ITEM_EV_I / The date and time of the installation of the Item at its current location.

M eter Record

This record is produced if a Service Point is of subtype Meter. Because an SP may have at most one meter installed at any given point in time, there is at most one record for an SP. If there is no Meter currently installed, a message is printed to that effect.

Field Name

Format

Source/Value/Description

Print Key

A4

"2400"

CIS Sort Key

A187

MTR_ID

A10

CI_MTR_CONFIG / The system-generated identifier for the Meter currently installed at the Service Point.

BADGE_NBR

A16

CI_MTR / The Meter's badge number

MTR_TYPE_CD

A8

CI_MTR / A code for the type of the Meter

MFG_CD

A8

CI_MTR / A code for the manufacturer of the Meter

DESCR

A60

CI_MFG / The actual name of the manufacturer

MODEL_CD

A8

CI_MTR / The manufacturer's model number for the Meter

DESCR

A60

CI_MODEL / A description of the model

SERIAL_NBR

A16

CI_MTR / Self-explanatory

RECEIVE_DT

D10

CI_MTR / The date on which the Meter was received by the utility from its manufacturer. This is NOT the install date.

DESCR254

A254

CI_MTR / A detailed description of the Meter (optional).

INSTALL_DTTM

D26

CI_CFG_SPMR_VW / The date and time of the installation of the Meter at its current location.

MTR_CONFIG_ID

A10

CI_SP_MTR_HIST / The system-generated identifier for the Meter's current Configuration

EFFDT

D10

CI_MTR_CONFIG / The effective date of the current Configuration

EFF_TM

T15

CI_MTR_CONFIG / The effective time of the current Configuration

R egister Record

One record is produced for every register on the currently effective Meter Configuration.

Field Name

Format

Source/Value/Description

Print Key

A4

"2450"

CIS Sort Key

A187

REG_ID

A10

CI_REG / The system-generated unique identifier for the Register

READ_SEQ

N2

CI_REG / The read sequence of the Register

UOM_CD

A4

CI_REG / The Unit Of Measure in which the Register is calibrated

TOU_CD

A8

CI_REG / The Time Of Use period during which the Register measures consumption

REG_CONST

N6.6

CI_REG / The Register Constant (if any) by which the actual reading is multiplied to calculate consumption

CONSUM_SUB_FLG

A2

CI_REG / A flag that indicates whether the Register is a consumptive or subtractive register

HOW_TO_USE_FLG

A2

CI_REG / A flag that indicates whether the Register's measured consumption is to be added to, subtracted from, or used as a check against the measured consumption of other Registers (if the Register is Subtractive) or measures a peak (maximum) value (if the Register is Consumptive)

NBR_OF_DGTS_LFT

N1

CI_REG / The number of digits to the left of the decimal point on the Register's readout

NBR_OF_DGTS_RGT

N1

CI_REG / The number of digits to the right of the decimal point on the Register's readout

FULL_SCALE

N9.5

CI_REG / The maximum value that can be displayed on the Register's readout before it "turns over" to zero

READ_OUT_TYPE_CD

A8

CI_REG / A code indicating the type of physical readout (dials, digital etc.) employed on the Register

PROTOCOL_CD

A8

CI_REG / A code indicating the means by which the register's consumption information is collected

TOLERANCE

N9.5

CI_REG / Tolerance is used to warn the meter reader that a Register is approaching its maximum permitted value

READ_DTTM

D26

CI_MR / The date and time of the most recent Register reading that is either a Customer Read, Regular read or a Verified read

REG_READING

N9.6

CI_REG_READ / The actual value displayed on the Register's readout when it was most recently read

READ_TYPE_FLG

A2

CI_REG_READ / The type code of the Register reading

E nd Meter Record

A "dummy" record used to signal Documaker that the last Register record for a Meter has been reached.

Field Name

Format

Source/Value/Description

Print Key

A4

"2490"

CIS Sort Key

A187

S P/Multi-Item Record

This record is produced if a Service Point is of subtype Unbadged. The Multi-Item record on the database has only two fields, the Service Point ID and the Effective Date, both of which form a composite Prime Key. Since this record always appears subordinate to the SP in the SP Group, only the date field is needed here. This record is stipulated in the CIS database as the parent to the detail item records that are its children.

Field Name

Format

Source/Value/Description

Print Key

A4

"2600"

CIS Sort Key

A187

EFF_DT

D10

CI_SP_MULT_ITEM

M ulti-Item Detail Line Record

One record is produced for each distinct type of item on the effective multi-item configuration at the time of printing. There may be any number of distinct item types and any number of individual items of a given type.

Field Name

Format

Source/Value/Description

Print Key

A4

"2620"

CIS Sort Key

A187

ITEM_TYPE_CD

A8

CI_MULT_ITEM / A code for the type of Item

DESCR

A60

CI_ITEM_TYPE / The description of the Item type

ITEM_CNT

N9.2

CI_MULT_ITEM / The number of individual Items of a given type

E nd SP/Multi-Item Step Record

A "dummy" record to signal Documaker that the last Item record in a Multi-Item configuration has been reached.

Field Name

Format

Source/Value/Description

Print Key

A4

"2690"

CIS Sort Key

A187

F ield Activity Record

One record is produced for each Pending field activity linked to the field order. Activities in any other Status are ignored.

Field Name

Format

Source/Value/Description

Print Key

A4

"3000"

CIS Sort Key

A187

FA_ID

A10

CI_FA / The unique system-generated identifier for a Field Activity

FA_TYPE_CD

A8

CI_FA / A code specifying the Field Activity's type

DESCR

A60

CI_FA_TYPE / The description of the FA type

FA_PRIORITY_FLG

A2

CI_FA / In the case of several Activities being created for the same SP, the Priority Flag stipulates which should be done first.

FA_CREATED_BY_FLG

A2

CI_FA / A code indicating who or what originated this Field Activity

XLATLONGNAME

A30

CI_LOOKUP / The description of the Created By flag

SCHED_DT

D10

CI_FA / The date on which the Activity is scheduled to be done

SCHED_TM

T15

CI_FA / The time at which the Activity is scheduled to commence (optional).

INSTRUCTIONS

A254

CI_FA / Free form detailed instructions as to exactly what is to be done.

DESCR254

A254

CI_FA / A more detailed description of the FA Type (optional)

C redit and Collection Record

One record is produced for a Field Activity that was created by a Severance Process ( i.e., FA_CREATED_BY_FLG = "SE" (Severance Event)).

Field Name

Format

Source/Value/Description

Print Key

A4

"3100"

CIS Sort Key

A187

SA_ID

A10

CI_SEV_PROC / The Service Agreement for which a Severance Process has issued a Disconnect field activity as a result of a Severance Event

Overdue Amount [Artificial]

N13.2

The program calls another COBOL routine (CIPFFTBN) that calculates this amount based on the Severance Process Arrears Date

Current Amount [Artificial]

N13.2

The program calls another COBOL routine (CIPFFTBN) that calculates this amount using the current date.

Past Severance Processes [Artificial]

N3

The number of Severance Processes issued against this Service Agreement in the past, excluding the one that generated this Activity

ACCT_ID

A10

CI_SA / The Account associated with the Service Agreement above

ENTITY_NAME

A64

CI_PER_NAME / The Primary name of the Main customer on the Account above

BILL_DT

D10

CI_BILL / The date of the most recent bill that is charged to the Account above

CUR_AMT

N13.2

The dollar amount of the most recent bill. Calculated from CI_BILL_SA

PAY_DT

D10

CI_PAY_EVENT / The date of the most recent Frozen payment on the Account of the SA above

PAY_AMT

N13.2

CI_PAY / The amount of the most recent Frozen payment on the Account of the SA above

Credit Rating [Artificial]

N5

Calculated from the Credit Rating Base Score on the Installation Table and CR_RATING_PTS from CI_ACCT_CR_R_VW

Cash-only Switch

[Artificial]

A1

Set to "Y" if the Cash Only score is above the Cash Only Threshold as defined on the Installation Table. Calculated from the Cash Only Base Score on the Installation Table and CASH_ONLY_PTS from CI_ACCT_CR_R_VW

Deposit Amount [Artificial]

N13.2

The program calls another COBOL routine (CIPDFDVN) to calculate this amount

F ield Activity Step Record

One record is produced for each Step within a Field Activity.

Field Name

Format

Source/Value/Description

Print Key

A4

"3200"

CIS Sort Key

A187

STEP_SEQ_NBR

N3

CI_FA_STEP / The sequence of a Step within a Field Activity

FA_STEP_TY_ACT_FLG

A2

CI_FA_STEP / A code indicating the FA Step Type Action.

XLATLONGNAME

A60

CI_LOOKUP / The description of the FA Step Type Action.

FA_STEP_DESCR

A60

CI_FA_STEP_TYPE / Description of the FA Step Type.

OPTIONAL_SW

A1

CI_FA_STEP_TYPE / "Y" indicates that a particular Step is regarded as optional for field activities of this FA Type

The next 14 record types (through End Field Order Record) are all "dummy" records that contain no information and exist only to signal Documaker to print a pre-specified block of text.

F ield Activity Step (Enter Meter Badge Number) Record

This record is produced if the step requires space for the field worker to write a meter's badge number.

Field Name

Format

Source/Value/Description

Print Key

A4

"3410"

CIS Sort Key

A187

F ield Activity Step (Enter Item Badge Number) Record

This record is produced if the step requires space for the field worker to write an item's badge number.

Field Name

Format

Source/Value/Description

Print Key

A4

"3430"

CIS Sort Key

A187

F ield Activity Step (Enter Customer Contact) Record

This record is produced if the step requires space for the field worker to write customer contact information.

Field Name

Format

Source/Value/Description

Print Key

A4

"3450"

CIS Sort Key

A187

F ield Activity Step (Enter Reconfigure Register) Record

This record is produced if the step requires space for the field worker to write register configuration information.

Field Name

Format

Source/Value/Description

Print Key

A4

"3470"

CIS Sort Key

A187

F ield Activity Step (Enter Disconnect Location) Record

This record is produced if the step requires space for the field worker to write disconnect location.

Field Name

Format

Source/Value/Description

Print Key

A4

"3490"

CIS Sort Key

A187

F ield Activity Step (Enter Register Read) Record

This record is produced if the step requires space for the field worker to write register read information.

Field Name

Format

Source/Value/Description

Print Key

A4

"3510"

CIS Sort Key

A187

F ield Activity Step (Enter Multi-Item) Record

This record is produced if the step requires space for the field worker to write multi-item information.

Field Name

Format

Source/Value/Description

Print Key

A4

"3530"

CIS Sort Key

A187

F ield Activity Step (Enter TO Stat) Record

This record is produced if the step requires space for the field worker to write trouble order statistics.

Field Name

Format

Source/Value/Description

Print Key

A4

"3550"

CIS Sort Key

A187

F ield Activity Step (Enter Changes) Record

This record is produced if the step requires space for the field worker to write free format information.

Field Name

Format

Source/Value/Description

Print Key

A4

"3570"

CIS Sort Key

A187

F ield Activity Step (Generic) Record

This record is used for consistency on any FA Type that has no other type of FA Step (action) record associated with it.

Field Name

Format

Source/Value/Description

Print Key

A4

"3999"

CIS Sort Key

A187

E nd Field Activity Step Record

Field Name

Format

Source/Value/Description

Print Key

A4

"6100"

CIS Sort Key

A187

E nd Field Activity Record

Field Name

Format

Source/Value/Description

Print Key

A4

"6200"

CIS Sort Key

A187

E nd SP Record

Field Name

Format

Source/Value/Description

Print Key

A4

"6300"

CIS Sort Key

A187

E nd Field Order Record

Field Name

Format

Source/Value/Description

Print Key

A4

"9990"

CIS Sort Key

A187

D efinition of Address Subrecord (Sbr)

Used in mailing address and service address, total length = 361 bytes

Field Name

Format

Description

COUNTRY

A3

ADDRESS1

A64

ADDRESS2

A64

ADDRESS3

A64

ADDRESS4

A64

CITY

A30

NUM1

A6

NUM2

A4

HOUSE_TYPE

A2

COUNTY

A30

STATE

A6

POSTAL

A12

GEO_CODE

A11

IN_CITY_LIMIT

A1

Field Order Maintenance

A field order contains the field activities that connect, disconnect, and investigate service at a premise. The topics in this section describe the pages on which field order-related information is maintained.

Fastpath:

For more information about field orders, refer to The Big Picture Of Field Orders and How Are Field Orders Created And Dispatched.

Contents

Lifecycle of a Field Order

Field Order - Main Information

Field Order - Field Activities

Lifecycle of a Field Order

The following diagram illustrates the lifecycle of a field order.

Fastpath:

Refer to The Lifecycle Of Field Activities and Field Orders for a more detailed discussion of the lifecycle of a field order. The following diagram merely illustrates the state transition rules.

Dispatched A field order starts its life in the Dispatched state. Please note that when a field order is dispatched, its field activities remain in the Pending state.

Pended by User You Pend a field order when you want to indicate to others that it shouldn't be dispatched (for whatever reason).

Work Done, Not Recorded You may mark a field order as Work Done, Not Recorded if you know the field work is complete, but you lack the details (or time) to actually Complete the field order.

Complete After the related field work has been performed, the system is updated to reflect what happened and the field order becomes complete. No changes may be made to a Complete field order. Refer to How Does A Field Order Get Completed for more information about completion.

Canceled A field order may be Cancelled .

Field Order - Main Information

The Main page contains core field order information. Open this page using Field Order, Field Order.

Description of Page

Field Order is a concatenation of information about the order. It consists of the address of the premise, the status of the field order, the number of field activities linked to the order and, if the order has been completed, the date on which the work was done.

Field Order ID is the unique system-generated identifier for the field order.

Enter the Premise ID of the premise at which the field order will take place.

Use Schedule Date/Time to define when the field order is scheduled to be done.

Enter Reschedule Reason when changing the field order's schedule date/time.

Note:

Reschedule Reason only appears if the Fieldwork Options feature configuration exists with the Reschedule Reason Required option set to Y .

Field Order Status defines the state of the field order. The following values may exist:

Dispatched When the system creates a field order due to the dispatch of field activities, the system creates a field order in the Dispatched state. A field order remains in this state until the work is done. At that time, you can change the state to Work Done, Not Recorded . Alternatively, you can enter the results of the fieldwork (if available) and change the state to Completed . If the field order cannot be done for any reason, you should change the state to Canceled . Refer to How Does A Field Order Get Completed? for more information.

Work Done, Not Recorded You may change a field order to this state if you want to indicate the fieldwork has been done, but you don't have the necessary information to complete the order. After the completion information has been entered, you should change the status to Completed .

Note. You should only use this state if your organization keeps track of the state of dispatched field orders during the workday. If you don't do this, you can transition a field order from Dispatched directly to the Completed state.

Completed A Completed order is one where the fieldwork is done and the results have been entered into the system. An order can only be in this state if all of its field activities are in the state of completed or canceled.

Canceled You cancel an order when, for whatever reason, it cannot be done. You may uncancel an order by changing its status to an appropriate value.

Pended by User It should be rare to find a field order in this state as it is used when you want to hold a field order pending some event. A field order remains in this state until you decide what to do with it (either dispatch or cancel it). At that time, you change its status to an appropriate value.

Fastpath:

To completely understand the significance of a field order's status, refer to The Big Picture Of Field Orders.

Enter Cancel Reason when canceling the order.

Note:

Cancel Reason only appears if the Fieldwork Options feature configuration exists with the Cancel Reason Required option set to Y.

The Display Field Order button displays an online image of the field order when clicked. This button is only available if there is at least one pending field activity linked to the field order. Refer to Online Field Order Image for more information.

Note:

You can only use the Display Field Order 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. The system comes with a configuration to display field order images using Documaker, but can work with other applications.

Data is Not a Snapshot. Unlike other online image displays, such as bill and letters, the data used to produce a field order is not snapshot data. It is always the latest and greatest data from the system. As a result, the Display Field Order button is only available for field orders with pending field work.

Turn on Extract in Next Run if the field order should be extracted (downloaded or interfaced) in the next extraction run. This switch is only selectable when the field order's status is Dispatched .

Note:

Default note. When a field order's status becomes Dispatched , the system automatically turns on Extract in Next Run.

Use Work Date/Time to define when the fieldwork was done. This field is gray when the status is anything other than Completed .

If the field order has been extracted, the Extract Date/ Time are displayed.

Use Dispatch Group to define the logical group of representatives located at an operations area that is responsible for the order.

Note:

Dispatch group comes from field activity. When the system creates a field order from the Dispatch Field Activities query it populates the order's dispatch group using the dispatch group on the field activity(s). After the field order is created, you can change the order's dispatch group as needed.

Dispatch group may be overridden as part of grouping field activities prior to dispatch. When a user creates a field order on the Group Field Activities page, the order's dispatch group is assigned Using Alternate Dispatch Groups To Find The Lowest Common Denominator for more information.

Worked By shows the representative that actually performed the fieldwork. This field is gray when the status is anything other than Completed .

The Representative is the individual (or crew) assigned to the field order and responsible for the actual performance of the field order's activities. Only representatives defined as valid for the field order's dispatch group may be assigned.

Use Schedule End Date/Time if an appointment has been scheduled for this field order. If so, these fields contain the date and time that the fieldwork should be finished.

Enter any Comments about the field order.

Enter a Phone Type, Phone Number, and Extension to record a phone number for the field representatives to use if they need to contact someone while in the field. The Phone Format for the phone number type is also displayed.

At the bottom of this page is a tree that shows the accounts, service agreements, field activities and appointments that are currently linked to the field order's service point(s). 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.

Field Order - Field Activities

The Field Activities page shows the field activities linked to the field order. Open this page using Field Order, Field Order, Activities.

Description of Page

The following information is displayed in the top portion of every page in this page.

Field Order is a concatenation of information about the order. It consists of the address of the premise, the status of the field order, the number of field activities linked to the order and, if the order has been completed, the date on which the work was done.

Field Order ID is the unique system-generated identifier for the field order.

The Field Activity scroll contains the field activities associated with the field order. To modify a field activity, simply move to a field and change its value. To add a new activity, click the + button to insert a row, then fill in the information for each field. The following fields display:

Service Point ID This is the system identifier of the service point at which the activity takes place. Summary information about the service point is displayed adjacent.

Activity Type Indicate the type of field activity. Only those activity types that have been defined as valid for the service point's SP type may be selected. The activity type's description is displayed adjacent.

Field Activity The unique system-generated identifier for this field activity.

Immediately below the Activity Type and Field Activity ID is a message created by the system about the field activity. If an appointment has been made for this field activity, information about the appointment is also displayed.

Field Activity Priority When a field activity is created, the value in this field is a default derived from the field activity's FA type. The operator may override this value so long as the activity is in status Pending or Held .

Field Activity Status A field activity is originally created in the Pending state. It remains in this state until the fieldwork is done and the system is updated with the results. At that time, the activity transitions to the Completed state. If an activity cannot be done, it should be Canceled . Change an activity's status to Held if you want to hold the activity pending some future event.

To completely understand the significance of a field activity's status, refer to The Big Picture Of Field Orders.

Cancel Reason When the field activity is canceled, a reason for the cancellation should be supplied

Instructions Enter any special instructions to be supplied to the field crew.

Comments Use the comments area to describe anything unusual about the activity. For example, if you change the activity's status to Held , it might be a good idea to explain the reason for doing so in the comments.

The Field Activity Step grid contains a summary of the field activity's steps.

Fastpath:

The number and type of steps associated with a field activity are defined by the field activity's type (which is maintained on the previous page). Refer to Designing Field Activity Types for more information.

Field Activity Maintenance

A field activity is a task that takes place at a service point. Examples of field activities include reconnect service, exchange meter and disconnect service.

A field activity contains one or more steps. The steps serve two purposes:

- They provide instructions of the individual units of work to be performed in the field.

- They define what must be done to complete the field activity.

The steps are defined by the field activity's activity type.

The topics in this section describe the pages on which field activity-related information is maintained.

Fastpath:

For more information about field activities, refer to The Lifecycle Of Field Activities And Field Orders.

Contents

Lifecycle of a Field Activity

Field Activity - Main Information

Field Activity - Steps

Field Activity - Characteristics/Remarks

Field Activity - Log

How To Add A Step To A Field Activity

Field Activity Remark Exceptions

Lifecycle of a Field Activity

The following diagram illustrates the lifecycle of a field activity.

Fastpath:

Refer to The Lifecycle Of Field Activities and Field Orders for a more detailed discussion of the lifecycle of a field activity. The following diagram merely illustrates the state transition rules.

Pending A field activity starts its life in the Pending state. A field activity remains in this state until you Cancel , Complete or Hold it. Please note that when a field order is dispatched, its field activities remain in the Pending state.

Held You Hold a field activity when you want to indicate to others that it shouldn't be dispatched (for whatever reason). A Held field activity can be Completed or Canceled .

Complete After the related field work has been performed, the system is updated to reflect what happened and the field activity becomes complete. No changes may be made to a Complete field activity. Refer to How Does A Field Order Get Completed for more information about completion.

Canceled A Pending or Held field activity may be Canceled .

Field Activity - Main Information

The Main page contains core field activity information. Open this page using Field Order, Field Activity.

Description of Page

The following fields are displayed on every tab page.

Field Activity is a concatenation of summary information regarding this field activity. It is composed of the address of the premise of the service point at which the activity will occur, a brief description of the activity, the activity's current status, and the activity's scheduled date.

Field Activity ID is the system-generated unique identifier for the field activity.

The remaining fields are specific to the main tab page.

Indicate the Service Point ID at which the activity takes place. Information about the service point is displayed adjacent.

Use Activity Type to define the type of field activity. Only those activity types defined as valid for the service point's SP type's field activity profile may be selected. The activity type's description is displayed adjacent.

Displayed just below the Activity Type is a system-generated message regarding how the field activity was created. This message includes the date and time the field activity was created and the process that created it. If a user manually creates a field activity the user's ID is concatenated into the message.

Use Schedule Date / Time to define when the field activity is scheduled to be done.

Enter Reschedule Reason when changing the field activity's schedule date/time.

Note:

Note. Reschedule Reason only appears if the Fieldwork Options feature configuration exists with the Reschedule Reason Required option set to Y .

If an appointment is linked to this field activity, the system calls the appointment information algorithm plugged in to the installation options.

Field Activity Status defines the state of the field activity. The following values may exist:

Pending A field activity is originally created in the Pending state.

Completed When an activity's fieldwork is done the system is updated with the results and the activity becomes Completed .

Canceled If an activity cannot be done, it should be Canceled .

Held Change an activity's status to Held if you want to hold the activity pending some future event.

Fastpath:

To completely understand the significance of a field activity's status, refer to The Big Picture Of Field Orders.

To change the status of the field activity, use the FA Actions, described below.

If you cancel a field activity, you must supply a Cancel Reason Code.

Field Activity Priority is a default value from the field activity's field activity type. It is used by the system to establish the order of precedence if there are several field activities pending for the same service point at the same time. The user may override this value.

Eligible for Dispatch controls whether a Dispatch Group can be assigned to the field activity and whether the field activity can be linked to a field order. This field is display-only (it is defined on the activity's activity type)

Use Dispatch Group to define the logical group of representatives located at an operations area that is responsible for the activity. For example, in the South West Operations Area you may have the dispatch groups of SW Service Installers, SW Service Investigators, SW Meter Exchangers, etc. Within each dispatch group are representatives with interchangeable skills (i.e., you can assign a field activity to any representative within a dispatch group). You only define the representative when the field activity is linked to a field order. Refer to Setting Up Dispatch Groups for more information.

Note:

Default note. The type of field activity and the service point's SP type and operations area define the Dispatch group that the system assigns to a field activity. Refer to Designing Who Does Your Field Activities for more information.

A Field Order's dispatch group comes from its field activities. When the system creates a field order from the Dispatch Field Activities query it populates the order's dispatch group using the dispatch group on the field activity(s). After the field order is created, you can change the order's dispatch group as needed. Changing the dispatch group on the order effectively changes the dispatch group on the order's activities.

Dispatch group may be overridden as part of grouping field activities prior to dispatching. When a user creates a field order on the Group Field Activities page, the order's dispatch group is assigned Using Alternate Dispatch Groups To Find The Lowest Common Denominator for more information.

Dispatch group is protected when the field activity is linked to a field order. Once a field order has been created for a field activity, the dispatch group on the field activity cannot be changed. The change to a dispatch group should occur on the field order.

Field Order ID defines the field order to which the activity is linked. This field is gray if the activity type is not eligible for dispatch. This field will be blank when the activity is not linked to a field order. Summary information about the field order appears adjacent.

If the dispatch group for the field activity references an external system feature configuration, the External ID is used to reference the unique identifier of the field activity in the external system. The Intermediate Status field is used to display interim status of a dispatched field activity.

Note:

Integration Required. The external ID and intermediate status fields are only updated if the integration with your external system passes this information to the system.

The values for the intermediate status field are customizable using the Lookup table. This field name is FA_INT_STATUS_FLG. Many values are supplied with the base product to support different sample integrations. To see the values, follow this link to the field activity table definition CI_FA and find the field name. Also refer to the documentation related to out-of-the-box integrations supplied with our other products such as Oracle Utilities Mobile Workforce Management and Oracle Utilities Work and Asset Management to see what values are used for integration with those systems.

Use Instructions to specify any special instructions to be supplied to the field crew.

Use Comments to describe anything unusual about the activity. For example, if you change the activity's status to Held , it might be a good idea to explain why you did so in the comments.

If you have plugged in an FA Additional Information algorithm on the Installation table, Additional Info displays the results of the algorithm, if any.

The FA Actions buttons allow you to change the status of the field activity.

- Click Complete to change the status of the field activity to complete . This button is only enabled if the status is pending or held .

- Click Cancel to change the status of the field activity to canceled . This button is only enabled if the status is pending or held .

- Click Hold to change the status of the field activity to held . This button is only enabled if the status is pending . This button is not enabled if the field activity is linked to a service order from an external system.

- Click Pend to change the status of the field activity to pending . This button is only enabled if the status is held .

At the bottom of this page is a tree that shows the account(s) and service agreement(s) that are currently linked to the field activity's service point. 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.

Field Activity - Steps

Use this page to reference the objects that were created or updated to reflect what took place in the field. Open this page using Field Order, Field Activity, Steps.

Note:

We strongly recommend that you understand the information described in How Does A Field Order Get Completed? before you use this page.

Fastpath:

The number and type of steps associated with a field activity are defined by the field activity's type (which is maintained on the previous page). Refer to Setting Up Field Activity Types for more information.

Description of Page

Summary information about the Service Point at which the activity will occur is displayed, as well as the service point's system-generated Service Point ID.

The Field Activity Status is displayed next. See Field Activity - Main for the valid values of Status and their meanings.

The Field Activity Steps grid displays the step(s) involved in the field activity, as defined by the field activity's field activity type. In order to complete a step, you typically need to add or change something in the system to reflect what happened in the field. For example, you would add a meter read for a step that required a new meter read. Refer to How Does A Field Order Get Completed? for information describing how to enter this information.

If the field activity is linked to an FA upload staging that is in the status pending or error , the FA Completion field displays information about the FA upload staging record.

The FA Actions buttons allow you to change the status of the field activity. Refer to the main tab page for a description of the fields.

Field Activity - Characteristics/Remarks

Use this page to link additional information to the field activity. Open this page using Field Order, Field Activity, Characteristics/Remark.

Description of Page

Summary information about the Service Point at which the activity will occur is displayed, as well as the service point's system-generated Service Point ID.

The Characteristics collection contains information that describes miscellaneous information about the field activity.

To modify a characteristic, simply move to a field and change its value. To add a new characteristic, click the + button to insert a row, then fill in the information for each field. The following fields display:

Characteristic Type Indicate the type of characteristic.

Characteristic Value Indicate the value of the characteristic.

Note:

Default Note. A field activity's characteristics default from the field activity type.

The Remarks grid is used to define anomalies associated with the field activity. For example, you can indicate performing the required task wasn't possible because there was a dangerous situation at the premise.

The Field Activity Remark Status is only relevant if a Field Activity Remark code has algorithms associated with it. Algorithms are associated with field activity remarks if additional activities should occur after a field activity with such a remark is activated. For example, you could generate a customer contact to send a letter to the customer to remove debris from the meter area if a "remove debris" remark is associated with the field activity. The execution of the algorithm is performed by a background process called FACT (field activity remark activation). The Field Activity Remark Status indicates whether the algorithm has been executed:

- When you add a remark that has an algorithm, the status is Pending . It remains in this state until the FACT process next runs.

- When the FACT process next runs, if the system is successful in executing the algorithm, the status of the field activity remark may become Complete . If the system is not successful in executing the algorithm, the status becomes Error .

Note:

Algorithm may control status. By default, the field activity remark activation process assumes that if the algorithm does not detect an error, the status of the FA remark should be complete . However, in some cases, the algorithm may not find an error but may also want the status of the FA remark to remain pending. Refer to FACT-CMPOTG for an example of such an algorithm.

Remarks that are in error. Field activity remarks whose algorithms could not be successfully executed by the FACT background process result in the creation of a Field Activity Remark Exception record. To correct errors, you may have to delete and re-add the field activity's remark code if the error is impossible to fix (e.g., if the remark causes a customer contact to be generated and there is no customer at the field activity's premise).

Fastpath:

Refer to Setting Up Field Activity Remarks for more information.

Field Activity - Field Activity Portal

Select Main Menu > Field Order > Field Activity and navigate to the Field Activity Portal tab to view additional information associated with a Field Activity.

General Information

Field Activity ID, Field Activity Info are displayed.

Depending on your implementations requirements, you may define additional zones to appear on this Portal.

Refer to The Big Picture of Portals and Zones in the Oracle Utilities Application Framework Administration Guide for a description of portal and zone functionality.

Field Activity - Log

Use this page to view and add log records for a field activity. Open this page using Field Order, Field Activity, Log.

Description of Page

The Log grid displays log entries that audit the progress of a field activity. You cannot modify or delete log entries that have been created by the system.

You can manually add a log entry of type User .

The Log grid displays the following information:

Date/Time Displays the date and time when the log entry was created.

Log Type Indicates the entry event for which the log entry was created. The log type for log entries created online is User . Refer to the FA Log Entry Events table below for information about log types provided for log entries that may be created by sample plug-ins.

Note:

The values for the log type are customizable using the Lookup table. This field name is FA_LOG_TYP_FLG.

Details Contains user-specified or system-generated information about the log entry.

User Displays the user who caused the log entry to be created.

Sequence Displays the sequence that makes up part of the unique identifier of this log record (together with the Field Activity ID).

FA Log Entry Events

Log entries are generated either manually by a user or via a "plug-in". The system provides some sample plug-ins that may be configured to populate the table.

- The sample FA integration algorithm may be configured to create log entries for certain conditions.

- The sample FA response application services provided by the system create log entries for positive or negative responses to outgoing messages.

- The sample FA completion application service provide by the system may create log entries under certain conditions.

The table below indicates the log types provided by the system and which sample "plug-ins" may create them.

Log Type

Generated By

Content of Details

Appointment Book - Negative Acknowledgement

FA Response application service for a negative response to Appointment Book NDS message.

Negative Acknowledgment. Message ID (%1) - %2. Error (%3) %4

Where %1 is message ID

%2 is the Notification Download Type description

%3 and %4 are the external message code and its corresponding base message category/number, if the external message code has been specified.

Appointment Booked

FA integration algorithm

Appointment booked for <appointment start date/time > - <appointment end date/time>.

Appointment Canceled

FA integration algorithm

Appointment for <appointment start date/time > - <appointment end date/time> has been canceled.

Appointment Canceled - Negative Acknowledgement

FA Response application service for a negative response to any Appointment Cancellation NDS message.

Negative Acknowledgment. Message ID (%1) - %2. Error (%3) %4

Where %1 is message ID

%2 is the Notification Download Type description

%3 and %4 are the external message code and its corresponding base message category/number, if the external message code has been specified.

External Message Received

FA completion application service if action is Update Log

Message received from %1. Message text: %2

Where %1 is the description of the external system feature configuration

%2 is the message sent from the external system.

FA External ID Change

FA integration algorithm

FA External ID changed from <FA External ID - Before Change> to <FA External ID - After Change>

FA Intermediate Status Change

FA integration algorithm

FA Intermediate Status changed from <Intermediate Status Description - Before Change> to <Intermediate Status Description - After Change>

FA Status Change

FA integration algorithm

FA Status changed from <Status Description - Before Change> to <Status Description - After Change>

Order Cancellation - Negative Acknowledgement

FA Response application service for a negative response to FA Cancellation NDS message.

Negative Acknowledgment. Message ID (%1) - %2. Error (%3) %4

Where %1 is message ID

%2 is the Notification Download Type description

%3 and %4 are the external message code and its corresponding base message category/number, if the external message code has been specified.

Order Cancellation Confirmed

FA Response application service for a positive response to FA Cancellation NDS message

Positive Acknowledgment. Message ID (%1) - %2.

Where %1 is message ID and %2 is the description of the NDS type of the original outgoing message.

Order Change - Negative Acknowledgement

FA Response application service for a negative response to FA Changed NDS message.

Negative Acknowledgment. Message ID (%1) - %2. Error (%3) %4

Where %1 is message ID

%2 is the Notification Download Type description

%3 and %4 are the external message code and its corresponding base message category/number, if the external message code has been specified.

Order Change Confirmed

FA Response application service for a positive response to FA Changed NDS message

Positive Acknowledgment. Message ID (%1) - %2.

Where %1 is message ID and %2 is the description of the NDS type of the original outgoing message.

Order Completion

FA completion application service

FA is completed by External System

Order Creation - Negative Acknowledgement

FA Response application service for a negative response to FA Creation NDS message.

Negative Acknowledgment. Message ID (%1) - %2. Error (%3) %4

Where %1 is message ID

%2 is the Notification Download Type description

%3 and %4 are the external message code and its corresponding base message category/number, if the external message code has been specified.

Order Creation Confirmed

FA Response application service for a positive response to FA Creation NDS message

Positive Acknowledgment. Message ID (%1) - %2.

Where %1 is message ID and %2 is the description of the NDS type of the original outgoing message.

Order Reschedule - Negative Acknowledgement

FA Response application service for a negative response to FA Reschedule NDS message.

Negative Acknowledgment. Message ID (%1) - %2. Error (%3) %4

Where %1 is message ID

%2 is the Notification Download Type description

%3 and %4 are the external message code and its corresponding base message category/number, if the external message code has been specified.

Order Reschedule Confirmed

FA Response application service for a positive response to FA Rescheduled NDS message

Positive Acknowledgment. Message ID (%1) - %2.

Where %1 is message ID and %2 is the description of the NDS type of the original outgoing message.

Outage Call Interfaced

Processing Outage Call NDS message

Outage call has been sent.

How To Add A Step To A Field Activity

You are not allowed to add a step to an activity. If you need to add another step, any of the following approaches will work:

- Add a new activity to the order with an activity type containing the desired step (and cancel the pre-existing activity).

- Change the activity's activity type to be one that includes that desired step.

- Navigate to the appropriate maintenance page and make the change. This won't leave an audit of what took place on the field activity but it will change the system appropriately.

Field Activity Remark Exceptions

If a field activity has a remark code that has algorithms associated with it, the system activates the algorithms each time the FACT (field activity remark activation) background process is executed. If errors occur during the activation of the algorithms, a record is written to the field activity remark exception table with a message indicating the nature of the severe error.

To view the messages associated with the exception records, schedule the TD-FACT background process. This process generates a To Do entry for every record in the field activity remark exception table.

After correcting the cause of the error, drill into the Field Activity - Characteristics/Remarks tab and change the status of the remark from Error to Pending . When the FACT process next runs, it attempts to execute the remark's algorithm again.

Note:

You may have to delete or change the field activity's remark code if the error is impossible to fix (e.g., if the remark causes a customer contact to be generated and there is no customer at the field activity's premise).

Group Premise FAs (Field Activities)

This page is used to view the pending field work at a premise and to create field order(s) for the pending field activities.

Open this page using Field Order, Group Premise FAs.

Description of Page

This page has several purposes:

- It shows a Premise's pending field activities that are not assigned to a field order and are linked to a dispatch group that is eligible for dispatch. These appear in the first grid.

- It shows a Premise's open field orders. These appear in the second grid.

- It allows users to create a new field order(s) and link pending field activities to them (this is done by clicking the Create Field Order button).

The Premise's address and Premise ID are displayed.

Click the Create Field Order button to create a field order for the selected field activities (the activities appear in the following grid). You have two options when you click this button:

- Specify an Override Dispatch Group. If you do this, a field order will be created for this dispatch group and the selected field activities will be linked to it.

- Leave Override Dispatch Group blank. If you do this, the system will look for the "lowest common denominator" dispatch group and assign it to the pending field activities. Refer to Using Alternate Dispatch Groups To Find The Lowest Common Denominator for more information.

Note:

A field order's dispatch group overrides the activity's dispatch group. Be aware that the dispatch group that is assigned to the field order will replace the original dispatch group assigned to the field activities.

After orders have been created, they appear in the grid at the bottom of this page.

Using Alternate Dispatch Groups To Find The Lowest Common Denominator

When you click the Create Field Order button on the Group Field Activities transaction and leave the Override Dispatch Group blank the system attempts to find a "lowest common denominator" dispatch group and assign it to the pending field activities. If it is successful, all of the field activities are grouped under a single field order and dispatched. If it's unsuccessful, a separate field order is created for each activity without a common dispatch group.

The following example will help illustrate how a lowest common denominator dispatch group is assigned to a group of field activities.

FA1: Install Meter

FA2: Read Meter

FA3: Test Meter

Initial dispatch group assigned to field activity

NorthWest - Electric - Install and Remove

NorthWest - Electric - Readers

North - Electric - Testers

Alternate dispatch group

NorthWest - Electric

NorthWest - Electric

North - Electric

The above table illustrates the following example:

- There are 3 field activities at a premise and each of which has a different initial dispatch group (see the first row in the table).

- Each initial dispatch group has an alternate dispatch group.

- Of these field activities, FA1 and FA2 have a common alternate dispatch group: NorthWest - Electric . FA3, however doesn't have a common dispatch group. This means 2 field orders will be created:

- The first field order (associated with the NorthWest - Electric dispatch group) will contain FA1 and FA2.

- The second field order (associated with the North - Electric - Testers dispatch group) will contain FA3.

Fastpath:

Please refer to Automatically dispatching field activities for another example of how the lowest common denominator is selected.

Field Order Search

This query is really two queries:

- The search dialog shows groups of field orders that are:

- Linked to a dispatch group

- With a given status

- Scheduled on or before a date

- The query page shows individual field orders that are:

- Linked to the selected dispatch group

- With a given status

- Scheduled on the selected dispatch date

Open this page using Field Order, Field Order Search.

The topics described in this section describe the search dialog and the query page.

Contents

Field Order Search Dialog

Field Order Query Page

Field Order Search Dialog

This query's search dialog shows groups of field orders that match your search criteria. You can change the displayed information by changing the search criteria.

Note:

Leaving a search field blank. If you leave a search field blank, the system assumes you want to see all groups of field orders. For example, if you leave dispatch group blank, you will see every dispatch group's orders. You may use this facility on any of the search fields.

Description of Page

Enter a Dispatch Group to limit the search to a specific dispatch group. Leave this field blank to view groups of orders linked to all dispatch groups.

Enter a Field Order Status to limit the search to groups of orders in a specific state. Valid values are: Dispatched , Canceled , Completed , Pended By User , Work Done, Not Recorded . Leave this field blank to view groups of orders regardless of status.

Enter a Schedule Date/Time to limit the search to orders that exist on or before the input date and time. Leave this field blank to view groups of orders throughout time.

When you select a row and proceed to the query page, the system displays the individual field orders for the selected dispatch group, status and schedule date.

Field Order Query Page

The query page shows individual field orders for the selected dispatch group, status, and schedule date.

Description of Page

You can use the Field Order Filter to restrict the field orders that appear in the grid. The following options are available:

- All . This option shows all field orders for the selected dispatch group, status, and schedule date.

- Geo Type . This option shows all field orders whose premise has a given Geographic Type and Geographic Value. If you leave Geographic Value blank, all field orders whose premise has a given Geographic Type will be displayed (i.e., all geographic values for the selected Geographic Type are displayed).

Each row in the query shows an individual field order. Clicking the go to button adjacent to the order will transfer you to the Field Order Maintenance page with the selected field order displayed.

Dispatch Field Activities

Fastpath:

Refer to How Are Field Orders Created And Dispatched for other ways to dispatch field activities.

This query is really two queries AND a maintenance transaction:

- The search dialog shows groups of field activities that are:

- Eligible for dispatch

- Not linked to a field order

- Whose service point is serviced by an operations area

- Linked to a dispatch group

- In the Pending state

- Scheduled on or before a date

- The query page shows individual field activities that are:

- Eligible for dispatch

- Not linked to a field order

- Serviced by the selected operations area

- Linked to the selected dispatch group

- In the Pending state

- Scheduled on or before the selected dispatch date

- On the query page, you can create and dispatch field orders.

Open this page using Field Order, Dispatch Field Activities.

The topics described in this section describe the search dialog and the query page.

Contents

Field Activity Search Dialog

Field Activity Query Page

How Do You Link An Activity To An Existing Order?

Field Activity Search Dialog

This query's search dialog shows groups of field activities that match your search criteria. You can change the displayed information by changing the search criteria.

Note:

Leaving a search field blank. If you leave a search field blank, the system assumes you want to see all groups of field orders. For example, if you leave dispatch group blank, you will see every dispatch group's orders. You may use this facility on any of the search fields.

Description of Page

Enter a Dispatch Group to limit the search to a specific dispatch group. Leave this field blank to view groups of activities linked to all dispatch groups.

Enter an Operations Area to limit the search to a service points serviced by a given operations area. Leave this field blank to view groups of activities linked to all operations areas.

Enter a On/Before Date to limit the search to activities that exist on or before the input date. Leave this field blank to view groups of activities throughout time.

When you select a row and proceed to the query page, the system displays the individual field activities for the operations area, dispatch group and schedule date.

Note:

Implied search criteria. In addition to the explicit search criteria shown above, the search is limited to field activities in the Pending state that are eligible for dispatch and that are not already linked to a field order.

Field Activity Query Page

The query page shows individual field activities for the selected operations area, dispatch group and schedule date.

A special facility exists on this page that allows you to create and dispatch field orders for the activities. Refer to the Description of Page information below for the details.

Description of Page

You can use the Field Activity Filter to restrict the field activities that appear in the grid. The following options are available:

- All . This option shows all field activities for the selected dispatch group, operations area, and schedule date.

- Geo Type . This option shows all field activities whose premise has a given Geographic Type and Geographic Value. If you leave Geographic Value blank, all fields activities whose premise has a given Geographic Type will be displayed (i.e., all geographic values are displayed).

Each row in the query shows an individual field activity. Clicking the go to button adjacent to the activity transfers you to the Field Activity Maintenance page with the selected field activity displayed.

When you're ready to dispatch field activities,

- Turn on the Dispatch? switch on every activity to be dispatched.

- If you want to dispatch all activities in the grid, click the Select All button. This causes the Dispatch? switch to be turned on for every field activity in the grid.

- If you want to dispatch specific activities, turn on the Dispatch? switch on the desired activities.

- If you want to turn off the Dispatch? switch on all activities in the grid, click the Clear All button.

- Enter the Representative who will do the work.

- Enter the on Date / Time on which the work will be performed (time is optional).

- Save the page.

When you save the page, the system:

- Creates a new field order for every unique combination of dispatch group and premise on the selected field activities. The new field order(s) are assigned to the selected representative and scheduled on the selected date and time.

- Links the appropriate field activities to each field order

- Sets the status of the field order to Dispatched .

How Do You Link An Activity To An Existing Order?

If a field order already exists and you want to link another field activity to it, simply drill over to the Field Activity Maintenance page (by clicking the button adjacent to the activity) and update the activity to reference the desired field order.

Downloading Field Orders

Your field staff must be apprised of all orders for which they are responsible. This communication can take place in many ways:

- A printed order can be given to the field crew

- An electronic version of the order can be routed to the crew's truck

The communication of field orders to the field crews is handled through the field order download process. The topics in this section describe this process.

The Field Order Download Processes

The following diagram illustrates the processes involved in the creation of the flat file that is interfaced to your field order print / dispatch software.

Contents

FDS - Create Download Staging

FODL - Create Download Flat File

FDS - Create Download Staging

This process looks for all field orders that are marked for extraction (a field order gets marked for extraction when it is first created if its dispatch group is dispatchable). For each record found, the system creates a field order download staging record.

Each download staging record is marked with a batch control ID & run number when it's created.

- The batch control ID comes from the field order's dispatch group. This ID corresponds with a specific extraction method. The system comes with a single field order download program ( FODL - Create Download Flat File). If you require different print formats or different routing methods, you will need to create additional programs. Refer to Technical Implementation of Batch Field Order Production for more information.

- The run number is the batch control ID's current run number.

Note:

Re-downloading. If you need to download a specific field order, navigate to Field Order - Main Information and change the order's status to Dispatched .

FODL - Create Download Flat File

This process reads all download staging records marked with a given batch control ID & run number and creates the flat file that's passed to the field order print / dispatch software.

Note:

This process is rerunnable. You can reproduce the flat file at any time. Simply request this job and specify the run number associated with the historic run.

The format of the flat file is determined based on an extract program linked to the field order's dispatch group. Refer to Dispatch Groups Control The Information Merged Onto Field Orders for more information.

Uploading Field Order Completion Information

This section describes how the system uploads field order completion details.

Warning:

It's important to be aware that only the following types of field activity steps can have their completion details uploaded through this process: Connect Service Point, Disconnect Service Point, Install Meter, Turn On Meter, Turn Off Meter, Read Meter, Remove Meter, Install Item, Turn On Item, Turn Off Item, Remove Item. Field Activity Completion Considerations describes a recommendation to use XAI to upload field activity completion information if any of the other step types are included in the field activity rather than the process described below.

Contents

Field Order Completion Upload Background Processes

FAUP-PRG - Purge Field Activity Upload Objects

Maintaining Field Activity Upload Staging

Field Activity Upload Exception

Field Order Completion Upload Background Processes

The following diagram illustrates the processes involved in the uploading of field order completion details.

The topics in this section describe how these processes work.

Contents

Process X - Populate MR and FA Upload Staging

MUP1 - Populate Meter Configuration

MUP2 - Create Meter Read

FACOMPL - Upload and Complete Field Activities

Process X - Populate MR and FA Upload Staging

Process X refers to the mechanism used by your organization to populate the various staging tables.

The topics in this section describe each of these tables.

Contents

Meter Read Upload Staging Tables

Field Activity Upload Staging

Field Activity Step Upload Staging

Field Activity Characteristic Upload Staging

Field Activity Remark Upload Staging

Meter Read Upload Staging Tables

If the field activity step involved the installation, removal, turning on, turning off, or reading of a meter; a meter read must be provided. Because the standard meter read upload process is used to interface these records into the system, you must create the meter read upload staging records described under Uploading Meter Reads for every read associated with the completion of field activities.

Field Activity Upload Staging

You must create a field activity upload staging record for each field activity whose completion details are being uploaded. The name of this table is CI_FA_STAGE_UP . The following table describes each column on this file.

Column Name

Length

Req'd

Data Type

Comments

FA_ID

10

Y

A/N

This is the ID of the field activity whose completion details are being supplied.

FA_UP_STATUS_FLG

2

Y

A/N

This must be set to P for Pending .

WORK_DTTM

26

Y

Date/Time

The date and time the work was done.

WORKED_BY

8

Y

A/N

The unique ID of the representative who performed the activity.

DESCR254

254

N

A/N

Optional comments about the field activity.

Field Activity Step Upload Staging

You must create a field activity step upload staging record for each step that was completed. The name of this table is CI_FA_STP_STG_UP . The following table describes each column on this file.

Column Name

Length

Req'd

Data Type

Comments

FA_ID

10

Y

A/N

This is the ID of the field activity whose completion details are being supplied.

STEP_SEQ_NBR

3

Y

N

This is the sequence number of the field activity step whose completion details are being supplied.

FA_STP_UP_STAT_FLG

2

Y

A/N

This is the status of the upload record. This must be set to P for Pending .

FA_STEP_TY_ACT_FLG

2

Y

A/N

This is the type of step whose completion details are being supplied. This must be one of the following values:

NS - Connect Service Point, DS - Disconnect Service Point, IM - Install Meter, NM - Turn On Meter, FM - Turn Off Meter, MR - Read Meter, RM - Remove Meter, II - Install Item, NI - Turn On Item, FI - Turn Off Item, RI - Remove Item

BADGE_NBR

30

See note

A/N

Badge Number is the badge number of the meter or item involved with the field activity step. It is required for the following step types: Install Meter, Turn On Meter, Turn Off Meter, Read Meter, Remove Meter, Install Item, Turn On Item, Turn Off Item, Remove Item

READ_DT

10

See note

Date

This must correspond with a read date on one of the meter read upload staging records. It is required for the following step types: Install Meter, Turn On Meter, Turn Off Meter, Read Meter, Remove Meter

READ_TIME

15

See note

Time

This must correspond with a read time on one of the meter read upload staging records. It is required for the following step types: Install Meter, Turn On Meter, Turn Off Meter, Read Meter, Remove Meter

DISCON_LOC_CD

4

See note

A/N

This is the disconnect location code that identifies where a service point has been disconnected. It is required for the Disconnect Service Point step type.

ON_OFF_FLG

2

See note

A/N

Set this to 0 if the meter / item was turned off.

Set this to 1 if the meter / item was turned on.

It is required for the following step types: Install Meter, Install Item.

EVENT_DTTM

26

See note

Date / Time

This the date and time an item was installed, removed, turned on or off. It is required for the following step types: Install Item, Turn On Item, Turn Off Item, Remove Item

STK_LOC_CD

12

See note

A/N

This is the stock location where the meter / item is stored upon removal from a service point. This is required for the following step types if the meter's meter type or the item's item type tracks location: Remove Item, Remove Meter. Refer to The Big Picture Of Asset Inventory for more information.

Field Activity Characteristic Upload Staging

You must create a field activity characteristic upload staging record for each characteristic that you would like to link to the field activity. The name of this table is CI_FA_STGUP_CHAR . The following table describes each column on this file.

Column Name

Length

Req'd

Data Type

Comments

FA_ID

10

Y

A/N

This must correspond with the prime key of the related CI_FA_STAGE_UP record.

CHAR_TYPE_CD

8

Y

A/N

This must correspond with a characteristic type that is defined as valid for the field activity type for this field activity.

SEQ_NUM

3

Y

N

This should be set to 10 unless you have multiple values for a given field activity and characteristic type.

CHAR_VAL

16

See note

A/N

Populate this field if your characteristic type is predefined .

ADHOC_CHAR_VAL

254

See note

A/N

Populate this field if your characteristic type is ad-hoc or file location .

CHAR_VAL_FK1 - CHAR_VAL_FK5

50 each

See note

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.

Field Activity Remark Upload Staging

You must create a field activity remark upload staging record for each remark that you would like to link to the field activity. The name of this table is CI_FA_STGUP_REM . The following table describes each column on this file.

Column Name

Length

Req'd

Data Type

Comments

FA_ID

10

Y

A/N

This is the ID of the field activity whose completion details are being supplied.

FA_REM_CD

12

Y

A/N

This must correspond with a field activity remark code. Refer to Setting Up Field Activity Remarks for more information.

MUP1 - Populate Meter Configuration

Refer to MUP1 - Populate Meter Configuration for information about this process.

MUP2 - Create Meter Read

Refer to MUP2 - Create Meter Read for information about this process.

FACOMPL - Upload and Complete Field Activities

FACOMPL processes Pending Field Activity Upload Staging records. For each such record, it processes the Pending Field Activity Step Upload Staging records as per the following table.

Step Type

What Happens

NS - Connect Service Point

Changes the connection status of the field activity's service point to connected and removes the disconnect location (if any). It then updates the related step to reference the service point.

DS - Disconnect Service Point

Changes the connection status of the field activity's service point to disconnected and populates the disconnect location with the supplied value. It then updates the related step to reference the service point.

IM - Install Meter

Creates a new SP / Meter record and links to it the meter read inferred from the badge number and read date/ time. Note: the meter read upload process creates this meter read. It then updates the related step to reference the SP / Meter record.

NM - Turn On Meter

Creates a new turn on event under an exist SP / Meter record. It links the meter read inferred from the badge number and read date/ time to the turn on event. Note: the meter read upload process creates this meter read. It then updates the related step to reference the SP / Meter record.

FM - Turn Off Meter

Creates a new turn off event under an exist SP / Meter record. It links the meter read inferred from the badge number and read date/ time to the turn off event. Note: the meter read upload process creates this meter read. It then updates the related step to reference the SP / Meter record.

MR - Read Meter

It's important to note that the meter read upload process creates this meter read. When this type of step is uploaded, the system simply updates the related step to reference the previously created meter read.

RM - Remove Meter

Updates an existing SP / Meter record to indicate the meter has been removed. It does this by linking the meter read inferred from the badge number and read date/ time. Note: the meter read upload process creates this meter read. It then updates the related step to reference the SP / Meter record.

II - Install Item

Creates a new SP / Item record using the supplied badge number and event date and time. It then updates the related step to reference the SP / Item record.

NI - Turn On Item

Creates a new turn on event under an exist SP / Item record. It then updates the related step to reference the SP / Item record.

FI - Turn Off Item

Creates a new turn off event under an exist SP / Item record. It then updates the related step to reference the SP / Item record.

RI - Remove Item

Updates an existing SP / Item record to indicate the item has been removed. It then updates the related step to reference the SP / Item record.

After this process updates the related step, it checks if all required steps under the parent field activity reference their appropriate foreign key. If so, it completes the field activity. It then checks if all field activities under the parent field order are complete, if so it completes the field order (note, it will also update the field order with the work done date / time and worked by information on the related Field Activity Upload Staging record).

Any errors detected during this process are written to the Field Activity Upload Exception table. You can fix errors using Field Activity Staging page (don't forget to change the record's status back to Pending ).

FAUP-PRG - Purge Field Activity Upload Objects

Completed field activity upload staging objects should be periodically purged from the system by executing the FAUP-PRG background process. This background process allows you to purge all Completed field activity 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 field activity upload objects that may exist. You can retain these objects for as long as you desire. However we recommend that you periodically purge Completed field activity upload objects as they exist only to satisfy auditing and reporting needs.

Maintaining Field Activity Upload Staging

The Field Activity Upload Staging page has three purposes:

- You can view historical field activity upload records.

- You can correct field activity upload records that are in error.

- You can add new field activity upload records to be uploaded by the field activity upload background process (or you can click the Complete button to upload and complete the activity (and order) real time).

Fastpath:

This page's dialog is idiosyncratic. Refer to How To for instructions describing how to perform common maintenance tasks.

The following topics describe this transaction in detail.

Contents

FA Upload Staging - Main

FA Upload Staging - Steps

FA Upload Staging - Characteristics/Remarks

How To

FA Upload Staging - Main

The Main page contains core field activity completion information. Open this page using Field Order, FA Upload Staging.

Description of Page

FA Upload Staging ID is the system-generated unique identifier for the field activity upload staging record (note: this will be the same as the unique ID of the associated field activity).

The Field Activity ID is the field activity being completed.

The Service Point ID and its information are displayed beneath.

Upload Status shows the state of the field activity upload record. Potential values are: Pending , Complete , Error .

If a record is in Error , the error message will be displayed adjacent. You can correct an Error by

- Correcting whatever is wrong,

- Change the Upload Status back to Pending

- Click the Complete button. Clicking the Complete button calls the routine that attempts to update the completion information.

Enter the Work Date/ Time when the field work was performed. These values will be populated on the field activity's field order when it is completed.

Worked By is the individual (or crew) who actually performed the work. Only representatives defined as valid for the field order's dispatch group may be assigned.

Comments is appended to the field activity's Comments.

The FA Upload Staging Steps scroll contains a summary of the field activity's steps.

Click the Complete button to complete the associated field activity. This button is only enabled when the field activity upload staging record has been saved on the database and is in the Pending state.

Click the Delete button to delete the field activity upload staging record. This button is only enabled when the field activity upload staging record has been saved on the database and is in the Pending or Error states.

FA Upload Staging - Steps

The Steps page contains completion information related to the field activity's steps. Open this page using Field Order, FA Upload Staging, Steps.

Description of Page

FA Upload Staging ID is the system-generated unique identifier for the field activity upload staging record (note: this will be the same as the unique ID of the associated field activity).

The Steps scroll contains the field activity's steps. To complete a field activity, you must enter the relevant information for each required step. The type of information that should be entered differs depending on the step type.

Step Type

What Fields Are Displayed

Contact Customer

No fields related to customer contact are displayed. Customer Contact must be created separately.

Change Service Point

No generic fields related to updating a service point are displayed. Service Point must be updated separately.

Connect Service Point

None

Disconnect Service Point

Disconnect location

Install Meter

Badge number, read date, read time, on/off status

Change Meter

No generic fields related to updating a meter are displayed. Meter must be updated separately.

Change Meter's Configuration

No generic fields related to updating a meter configuration are displayed. Meter Configuration must be updated separately.

Turn On Meter

Badge number, read date, read time

Turn Off Meter

Badge number, read date, read time

Read Meter

Badge number, read date, read time

Remove Meter

Badge number, read date, read time, stock location* (see below)

Install Item

Badge number, event date, event time, on/off status

Change Item

No generic fields related to updating an item are displayed. Item must be updated separately.

Turn On Item

Badge number, event date, event time

Turn Off Item

Badge number, event date, event time

Reconfigure Multi-Item

No generic fields related to multi-item configuration are displayed. Item configuration must be updated separately.

Remove Item

Badge number, event date, event time, stock location* (see below)

Test Device

No fields related to device testing are displayed. Device Test must be created separately.

For step types Remove Meter and Remove Item , enter the Stock Location where the meter / item is stored upon removal if the meter's meter type or the item's item type tracks location. Refer to The Big Picture Of Asset Inventory for more information.

The Add Meter Read section can be used to add a meter read for those step types that require a meter read.

The Add Meter Read button becomes enabled after you enter a Badge Number and Read Date/Time. For required steps, the system populates Read Date/Time with the values entered for Work Date/Time but you can change these values if necessary.

When you click the button, the Register Readings grid is populated with one row for each of the meter's registers. At this point, enter each register's reading by specifying a Read Type and Reading. When you save the field activity upload staging record, the read is added to the database, but the read information disappears. This information is not actually linked to the Field Activity Upload Staging. When you complete a field activity, the system looks for a meter read to link to the FA. It should find the one you just created.

Fastpath:

Refer to Meter Read - Main for more information about meter reads.

Note:

High/low validation. It's important to note that the read will not be subject to high/low validation. If you require high/low validation, add the read using Meter Read - Main and then simply reference the read's badge number and date/time on the step.

Click the Complete button to complete the associated field activity. This button is only enabled when the field activity upload staging record and is in the Pending state.

Click the Delete button to delete the field activity upload staging record. This button is only enabled when the field activity upload staging record has been saved on the database and is in the Pending or Error states.

FA Upload Staging - Characteristics/Remarks

The Characteristics/Remarks page contains additional information related to the field activity. Open this page using Field Order, FA Upload Staging, Characteristics/Remarks.

Description of Page

FA Upload Staging ID is the system-generated unique identifier for the field activity upload staging record (note: this will be the same as the unique ID of the associated field activity).

The Characteristics grid is used to link additional information to the field activity.

The Remarks grid is used to define anomalies associated with the field activity.

How To

The topics in this section describe how to perform common maintenance functions.

How To Complete A Simple Field Activity That Requires A Read

The following steps describe how to complete a simple field activity that requires a meter read.

You navigate through the pages as follows:

- Navigate to Field Activity Upload Staging.

- Enter the ID of the field activity being completed.

- Use Work Date/Time to define when the field activity was completed.

- Navigate to the Steps tab and enter the Badge Number and Read Date/Time. For required steps, the system populates Read Date/Time with the values entered for Work Date/Time but you can change these vales if necessary. After entering this information, the Add Meter Read button becomes enabled. Click it to open the Register Reading grid.

- Specify the Read Type and Register Reading for each register on the meter. Then click the Complete button. When the Complete button is clicked, the following events take place:

- The field activity upload staging record is saved.

- A meter read is added.

- The system attempts to complete the field activity using the information on the field activity upload staging record and on the meter read.

- If the system is not successful in completing the activity due to incomplete information on the field activity upload staging record, the upload staging step's status will be changed to Error and a corresponding error message will be displayed. To complete the activity, fix the cause of the problem and change the step's status back to Pending and then click the Complete button again.

- If the system is successful in completing the activity, the field activity upload staging record's upload status is changed to Complete , the step's upload status is changed to Complete , the field activity's status is changed to Complete , and, if all field activity's linked to the field order are Complete , the field order's status is changed to Complete .

Note:

If after specifying the Read Type and Register Reading for each register on the meter the Save hyperlink is clicked instead of the Complete button, the field activity upload staging record is saved without adding a meter read. The field activity upload staging record remains in the Pending state.

Field Activity Upload Exception

If errors are detected during the field activity upload process, a record is written to the field activity 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-FAUPL background process. This process generates a To Do entry for every record in the field activity upload exception table.

You can fix this error using the FA Upload Staging page and change the status of the remark from Error to Pending. When the field activity upload process next runs, it attempts to upload this record again.

Outage Calls

Note:

The information in this section applies to the integration with the Oracle Utilities Network Management System (NMS).

You can use the Outage Call page to view trouble calls and outage information, and to send outage call reports to NMS for a specific service point. You can also use this page to schedule job site appointments. Open this page using Main Menu, Field Order, Outage Call.

Description of Page

The Outage Call Search zone is a standard multi-query portal used to search for and list existing Outage Call records. In the search results list, click the Outage Call link to view and maintain the information about the outage call.

The following zones are displayed for the selected outage call:

Contents

Outage Call Actions

Outage Call Zone

Outage Call Log

Outage Call Actions

This is a standard actions zone.

If the outage call is in a state that has valid next states, buttons to transition to each appropriate next state are displayed. If the record is in at state in which it can be edited, select Edit to change details regarding the record, such as scheduling or rescheduling a callback or meeting.

Outage Call Zone

The outage call zone contains display-only information about the record.

Outage Call Log

This is a standard log zone.

Outage Information

Note:

The information in this section applies to the integration with Oracle Utilities Network Management System (NMS).

The Outage Information portals provide a real-time interface with NMS to search for the following network management items:

- Job history

- Call history

- Planned outages.

Contents

Job History

Call History

Planned Outages

Job History

You can use the Job History portal to retrieve current and historical outage and non-outage jobs from NMS by a customer service point or account ID, or proximity to a street intersection or street segmentor, or other identifiers such as a 911 incident identifier, caller name, or call phone number.

Use Field Order, Outage Information, Job History to search for and view these records.

Description of Page

The Job History zone can be used to search for an existing Job History record. If the search results list contains records for a single service point, the service information for that service point and the job history results will be displayed. If the list contains multiple service point's records, a list of service points are displayed and the service information and job history results will be displayed for one of these service points. You can click on the Show History button to display the service information and job history results for any other service point record.

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

Call History

You can use the Call History portal to retrieve trouble call history from NMS by a customer service point, or account id, or proximity to a street intersection or street segmentor, or other identifiers such as a 911 incident identifier, caller name or call phone number.

Use Field Order, Outage Information, Call History to search for and view these records.

Description of Page

The Call History zone can be used to search for an existing Call History record. If the search results list contains records for a single service point, the service information for that service point and the call history results will be displayed. If the list contains multiple service point's records, a list of service points are displayed and the service information and call history results will be displayed for one of these service points. You can click on the Show History button to display the service information and call history results for any other service point record.

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

Planned Outages

You can use the Planned Outages portal to retrieve planned outage information from NMS.

Use Field Order, Outage Information, Planned Outages to search for and view these records.

Description of Page

The Planned Outages zone can be used to search for current, future and past planned outage status and details from NMS for a particular service point. Planned outage information will only be available once a planned outage has been scheduled and the list of impacted customers for that planned outage has been generated.

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

Billing

In this section, we describe how to manage your customer's bills.

Contents

The Big Picture of Billing

Maintaining Bills

Financial Transactions On A Bill

Maintaining Bill Segments

Off Cycle Bill Generator

Multi Cancel/Rebill

SA Billing History

Bill Exception

Bill Segment Exception

Maintaining Billable Charges

Uploading Billable Charges

Budget Review

The Big Picture of Billing

A bill is used to communicate changes in an account's financial obligations to the customer. Over time, a customer receives many bills. The topics in this section provide background information about a variety of billing topics.

Warning:

Some organizations are responsible for presenting 3 rd party charges on their bills. Others are responsible for sending their charges to a 3 rd party for presentation on their bills. If this describes your organization, refer The Big Picture of SA Relationships for a description of how this functionality is implemented.

Contents

An Illustration Of A Simple Bill

A High Level Overview Of The Bill Creation Process

Bill Errors

Cancel / Rebill Incorrect Bill Segments

Credit Notes - Presenting Cancellation Details on a Separate Bill

Correction Notes - Presenting Correction Details on a Separate Bill

How The System Determines How Much Was Consumed

How To Override The Commodity Amount In A Bill Segment

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 Customer Balances

Budget Billing

Using Billable Charges For Pass Through / Convergent Billing

Printing Bills

Sequential Bill Numbers

Document Numbers

Writing Off 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 service agreement 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 customer'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 service agreement linked to the account. Whether or not a service agreement contributes bill segment(s) to a bill is a complicated subject as the system supports a wide variety of bill segment creation methods. For example, a service agreement that charges for metered service is produced as follows:

- The system first calculates the amount consumed (e.g., the number of lamps, the number of gallons of water, the peak kW, etc.). For more information, refer to How The System Determines How Much Was Consumed.

- Next, the system applies the service agreement's rate to the amount consumed in order to calculate how much the customer owes. A bill segment and a financial transaction are generated to reflect the results of this calculation. 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 & Price Proration for information about how the system prorates changes to rates and prices during a bill period.

Note:

There are many bill segment creation algorithms. The above points explain how a bill segment is produced for a metered service agreement. It's important to be aware that the system has other bill segment creation algorithms. For example, if the service agreement charges for a deposit, the system neither amalgamates consumption nor does it apply a rate. You may be wondering how the system knows which method to use. It uses the bill segment type on the service agreement's SA type. Refer to Designing and Defining Bill Segment Types for a description of the various bill segment creation algorithms that are supported in the system.

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 service agreement. 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.

Note:

Interdependent service agreements. Your organization may have some service agreements whose charges must be calculated in a specific order. For example, you might have a service agreement whose bill segments are calculated using charges from a different bill segment. If this describes your organization, be aware that the system creates the bill segments in the order of the billing processing sequence on each service agreement's SA type.

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. Refer to Financial Transactions Created Between Bills for information about how payments, adjustments and bill corrections appear on a bill.

- 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 customer.

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 Service Agreements 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.

Contents

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 meter reads. For example, if the system cannot find a relevant read (and it's not allowed to estimate) for a metered service point, it generates an error.

- 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 customer specific charge and there is no value defined on the customer's service agreement, 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 customer).

If the bill segment in error was created as part of the 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 customer.

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 each night during the account's bill window. 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 dial reading on the meter read is incorrect due to slipped fingers, or the sales tax percent was entered incorrectly on a bill 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 customer. 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.

Using the cancel or cancel/rebill functionality will cause the cancel and rebill details to be swept on to the customer's next bill. If your organization requires cancellation details to be presented to the customer separately from the new bill, then you will need to use Credit Notes. Refer to Credit Notes - Presenting Cancellation Details on a Separate Bill for more information. If your organization requires cancellation and rebill details to be presented to the customer separately from the new bill, then you will need to use Correction Notes. Refer to Correction Notes - Presenting Correction Details on a Separate Bill for more information.

Credit Notes - Presenting Cancellation Details on a Separate Bill

The system's Cancel / Rebill functionality will include cancellation and rebilling details on the customer's next bill. Some organizations are required to present cancellation details to the customer separately and not to commingle them with a new bill. This separate statement containing only the cancellation information is referred to as a Credit Note.

Credit Notes may be created for an individual bill segment or for all the bill segments linked to a bill. To create a credit note, a Credit Note button is available on the Bill Segment page and on the Bill page.

Fastpath:

Refer to How To Create A Credit Note for more information about how to create credit notes for a bill or bill segment.

The topics in this section provide describe the impact of this functionality.

Contents

Credit Notes Are Only Possible if the Installation Option Is Turned On

Credit / Correction Notes and Auto Pay

Adjustments On Credit Notes

Credit Note Routing Suppression

Credit Notes Are Only Possible if the Installation Option Is Turned On

The Credit Notes button on the bill segment and bill pages will only be available if you have selected the Credit Note Bill Correction option on the Installation record.

Credit / Correction Notes and Auto Pay

If a credit or correction note is being created for a customer who is enrolled in Auto Pay, note the following functionality:

When creating a credit or correction note for a bill (and all its bill segments):

- The system will cancel an automatic payment behind-the-scenes if a credit or correction note is issued 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). This is standard auto pay logic. Refer to How Are Automatic Payments Cancelled? for more information.

- If the customer has automatic payments that have already been interfaced to the financial institution, the creation of the credit or correction note will have no affect on any automatic payment. A warning will be issued in this case.

When creating a credit or correction note for a bill segment:

- Because automatic payments are for an entire bill, creating a credit or correction note at the bill segment level will not affect any automatic payments. A warning is issued in this case.

Fastpath:

For more information about correction notes, see Correction Notes - Presenting Correction Details on a Separate Bill.

Adjustments On Credit Notes

Above, we described how a credit note is a separate document that contains the cancellation details of the various bill segments that appeared on a given bill. Some implementations also want the adjustments that appeared on the original bill to be cancelled when a credit note is produced. Then, when the next bill is produced for the customer, they want these same adjustments reproduced. The following points describe how to implement this functionality:

- Plug in a Bill Completion algorithm on the applicable Customer Classes. A base-package algorithm ( C1-CN-RADJ) will reverse a bill's adjustments when a credit note is completed.

- Plug in a Post Bill Completion algorithm on the applicable Customer Classes. A base-package algorithm ( C1-CN-ADNB) will recreate the adjustments on the original bill after the credit note is completed. These adjustments will be swept onto the next bill produced for the account.

You can restrict the above functionality to specific adjustment types (for whatever reason). You do this by putting a given char type / char value on the adjustment types that should be reversed and recreated when a credit note is created. You define this char type / char value combination as parameters of the two algorithms described above.

Note:

When the original bill contains adjustment cancellations. The above discussion explained how adjustments can be canceled on a credit note and then recreated on the next bill. These same algorithms also do the opposite, i.e., if the original bill contains an adjustment cancellation, the credit note will contain the recreated adjustment, and the next bill will contain its cancellation. Without this, the credit note would not be the reversal of the bill (and this is how some organizations operate).

Credit Note Routing Suppression

Some implementations do not send credit notes to their customers. To implement this functionality, plug in a Bill Completion algorithm on the applicable Customer Classes. A base-package algorithm ( C1-CN-BRT) will cause the routing information to be suppressed when a credit note is completed.

Correction Notes - Presenting Correction Details on a Separate Bill

The system's Cancel / Rebill functionality will include cancellation and rebilling details on the customer's next bill. Some organizations are required to present cancellation and rebilling details to the customer separately and not to commingle them with a new bill. This separate statement containing the cancellation and rebill information is referred to as a Correction Note.

Correction notes may be created for an individual bill segment or for all the bill segments linked to a bill. To create a correction note, a Correction Note button is available on the Bill Segment and Bill pages.

Fastpath:

Refer to How To Create A Correction Note for more information about how to create correction notes for a bill or bill segment.

The topics in this section describe correction notes.

Contents

Correction Notes Are Only Possible if the Installation Option Is Turned On

Correction Notes Versus Credit Notes

Correction Notes and Auto Pay

Correction Notes Are Only Possible if the Installation Option Is Turned On

The Correction Note button on the bill segment and bill pages will only be available if you have selected the Correction Note Bill Correction option on the Installation record.

Fastpath:

If your implementation uses Correction Notes , it is recommended to also use the Freeze At Bill Completion installation option. For more information, see Installation Options - Billing.

Correction Notes Versus Credit Notes

Correction notes are a mixture of Credit Note and Cancel / Rebill functionality. However, unlike credit notes, correction notes are like regular bills and are subject to payment.

When you issue a correction note for a bill, the system cancels and rebills the bill segments for that bill. The new bill (the correction note) contains both the cancelled bill segments and the rebilled bill segments.

Similar to credit notes, the new bill (or correction note) is stamped with the ID of the original bill. After you review the bill segments, you can complete the correction note. During completion, the rebilled bill segments and the cancelled financial transactions (of the original bill's bill segments) are swept onto the correction note.

Correction Notes and Auto Pay

Fastpath:

Refer to Credit / Correction Notes and Auto Pay for a description of how the system handles correction notes for customers using auto pay.

How The System Determines How Much Was Consumed

There are two types of service agreements:

- Those that charge for some commodity (e.g., electricity, water, garbage, street lighting).

- Those that charge for something intangible (e.g., deposit, charitable contribution, payment arrangement).

For service agreements that charge for something intangible, there is no notion of determining how much was consumed and therefore the topics in this section are not relevant. For service agreements that charge for a commodity, the first step in the creation of a bill segment is the determination of how much was consumed. For example,

- If the service agreement bills for electricity, the system must determine how much electricity was consumed.

- If the service agreement bills for lamp service, the system must determine how many lamps the customer uses.

After the system determines how much was consumed during the bill period, it saves the consumption on the bill segment in the following snapshots:

- The meter read snapshot contains information about the meter reads that were used to determine consumption for metered service points.

- The item snapshot contains information about the items that existed at the service points.

- The service quantity snapshot contains the billable service quantities that were derived using the meter read and item snapshots.

The topics in this section describe how each of the above snapshots is built.

Note:

This logic is in a plug-in. The logic described below resides in algorithms that are plugged-in on the bill segment type referenced on a service agreement's SA type. If you need different logic, you should develop the appropriate algorithm and plug it in on your bill segment types.

Contents

Meter Read Snapshot

Item Snapshot

Service Quantity Snapshot

Calculation / Audit Read Details

Meter Read Snapshot

To understand this section, you have to come to grips with the concept of a "perfect" end meter read. Our definition of perfection is a meter read that results in a number of days of usage that is in sync with the prices on the service agreement's rate. You see, many prices in a rate are expressed in respect of some period of time, e.g., a monthly flat charge of $10 is expressed in respect of 30 days. If the number of days on a bill segment is not in sync with the days of the prices, the bill segment must be prorated and proration is not desirable because it confuses the customer.

When selecting the perfect read, not only are we trying to prevent the current bill segment from prorating, we're also trying to prevent future bills from prorating. Remember, it's the end read on the current bill segment that serves as the start read on the next bill segment. So, if we don't pick the right read, the next bill will prorate (ad infinitum).

The topics in this section describe how the system selects the perfect reads while it assembles the meter read snapshot.

Contents

Determine The Bill Period For Metered Service

Determine The Consumption Period For Metered Service

Determine The Service Agreement's Billable Service Points

Determine The Service Points' Meters

Determine The Meters' Start And Stop Meter Reads

Determine The Bill Period For Metered Service

First, the system determines a start date and temporary end date for the bill segment. These dates form the boundary of the meter reads to be included on the bill segment.

- If this is the first bill segment for the service agreement, the billing segment start date is set to the start date of the service agreement. If this is not the first bill segment, the start date is the previous bill segment's end date.

- As for the end date, it can only be estimated at this point (the end read determines the actual end date and this read is only selected a few steps later). The temporary end date is either the end date of bill cycle schedule window, the service agreement's end date, or, in the case of on-line billing, determined by the user.

Fastpath:

Refer to Service Agreement - Main Information for more information about a service agreement's start and end dates.

Determine The Consumption Period For Metered Service

The consumption period is the inclusive period passed in to the rate application. It is used for calculating the charges for the bill segment. The consumption period is visible on the bill calculation header that groups together the bill calculation lines.

- Consider a bill segment that covers June 1 st through July 1 st and a subsequent bill segment that covers July 1 st through August 1 st. The charges for July 1 st are included on the first bill segment, so the second bill segment should not actually bill July 1 st. In this scenario, the inclusive consumption period provided to rate application for the second bill segment will be July 2 nd through August 1 st.

- Consider a bill segment that must include bill factor value proration .

- Assume the bill segment dates are July 1 st - August 1 st and that a new rate version is effective on July 20 th and that the charges should be prorated. The rate application process will be called twice, with the following inclusive dates:

- Period for charges calculated by old rate version: July 2 - July 19

- Period for charges calculated by new rate version: July 20 - August 1

Two bill calculation headers will be created in this case, each with the appropriate dates and the collection of bill calculation lines that represent the charges for the bill.

- Consider what should occur for the very first bill segment for a service agreement.

- It is possible that the start date of the new customer's service agreement matches the end date of the previous customer's service agreement. In this case, the stop/start date is billed to the old customer and the new customer should not be billed for it.

- It is possible that no other service agreement has been billed for the start date. Perhaps this is new service that has never been billed. Perhaps there is a gap in time between when the previous customer stopped service and when the new customer starts service.

You configure your SA types to tell the system what to do for the initial consumption period . You may instruct the system to calculate the start of the consumption period from the day after SA start date, to always include the SA start date, or include the SA start date only if no previous customer was billed for that day (i.e., a 'back-to-back' situation).

Determine The Service Agreement's Billable Service Points

The system looks at every service point linked to the service agreement. The system ignores service points that:

- Are not billable (e.g., check meters).

- Were disconnected before the bill period started.

- Have yet to be connected as at the bill end date.

Fastpath:

Refer to Service Agreement - SA / SP for more information about a service agreement's service points.

Determine The Service Points' Meters

The system retrieves each meter linked to each service point during the bill period (a service point has multiple meters when a meter exchange has occurred during the bill period).

Fastpath:

Refer to Installing / Removing A Meter for more information about a service agreement's service points.

Determine The Meters' Start And Stop Meter Reads

The system retrieves a start and stop meter read for each meter linked to the service agreement during the bill period.

Note:

Subtractive versus Consumptive meters. The system only looks for both start and stop reads when it has to subtract the start read from the stop read to derive consumption. There are some types of registers that are reset every time the meter is read and therefore each reading contains the total amount consumed. For this latter type of register, the system just looks for a single read. For more information, refer to Meter Configuration Maintenance for information about the Consumptive / Subtractive indicator.

The start read can come from any of the following sources:

- If this is the first bill segment for a service point, the start read is defined on the service agreement / service point relationship.

- If the meter was installed at an existing service point during the bill period, the start read is defined on the service point installation history. This happens when a meter is exchanged for another meter during a bill period.

- Otherwise, the start read is the same as the end read on the customer's previous bill segment.
The stop read can come from any of the following sources:

- If this is the final bill segment for a service point, the stop read is defined on the service agreement / service point relationship. Refer to Service Agreement - SA / SP for more information about the start and stop reads.

- If the meter was removed from an existing service point, the stop read is defined on the service point installation history. This happens when a meter is exchanged during a bill period. Refer to SP / Meter Installation for more information about installing and removing meters while a service agreement is in effect.

- Otherwise, the system looks for the next scheduled meter read date. Not just any date can be used, the system attempts to find a read that meets the following criteria:

- Is after the end date of the last bill segment plus the rate's frequency's minimum offset days, and

- Is on/before the cutoff date of the bill

If no such meter read date could be found, the service agreement is skipped. Otherwise, the system then looks for a read that exists in the time period that starts X days before the service point's next scheduled meter read date, and ends Y days after the scheduled meter read date (where X and Y are the rate's frequency's minimum and maximum offset days, respectively).

If more than one such read exists, the selection is based on the priority of read types (the read with the highest priority read type is selected). For example, verified reads are preferred to regular reads. Refer to the Description of Page section under Meter Read - Main for more information about read types and their billing selection priority.

- If no read can be found, the system estimates consumption and generates a corresponding estimated meter read if:

- The service agreement allows estimation.

- The user allows estimation (if the bill is produced as a result of an ad hoc request);

- The bill cycle schedule (if one is being used) allows estimation.

- The register is not a peak register (this is an artificial constraint, but most organizations do not estimate peak consumption).

- The rate schedule allows estimation;

- The register is subtractive. This is because only subtractive registers are self-correcting. For example, assume we estimate a reading of 100 and the next real read is 102, the customer will only be charged for 2 units. However, consider what would happen if we estimated a consumptive register - the consumption associated with the next real read would be billed in its entirety.

- The register does not measure peak consumption.

- Negative consumption is not allowed for the SP/meter combination.

Fastpath:

Refer to Estimation and Negative Consumption for more information about negative consumption.

The number of days in the bill period is then computed (this equals the start date of the bill segment through the date of the end read). If this is less than the SA type's minimum number of days on a bill, the service agreement is skipped.

Item Snapshot

The steps the system follows to build the item snapshot are the same as those used to build the meter read snapshot. The major differences are as follows:

- Items (e.g., lamps, hydrants, traffic lights) are not read so there are no meter reads to access.

- There are two sources of items:

- Item-based service points have a single, badged item that may be installed at any instant in time. These types of service points are used, for example, when your organization keeps track of the installation history of specific lamps. If an item is installed at an item-based service point during the bill period, it will be included in the item snapshot.

- All types of service points (metered, item-based, and non-badged) may contain one or more unbadged items. Multiple items exist at a service point, for example, when your organization chooses to record multiple lamps on a single service point rather than creating a separate service point for each lamp (this might be useful for a parking lot at a shopping mall). Each item referenced in the service point's collection of unbadged items is included in the snapshot.

Fastpath:

Refer to Service Points With Multiple Items for more information about service points with multiple items. Refer to SP / Item Installation for more information about installing and removing badged items at a service point. Refer to Service Point - Multiple Items for more information about the collection of items that may exist at both meter and item-based service points.

Service Quantity Snapshot

For service agreements where the meter reads are maintained in Oracle Utilities Customer Care and Billing, the service quantity (SQ) snapshot is the total amount consumed for each unit of measure referenced on the bill segment's meter read snapshot. For service agreements where the meter reads are not maintained in Oracle Utilities Customer Care and Billing and bill determinants are requested from a meter data management system via a usage request, the service quantity (SQ) snapshot is the total amount consumed (or peak amount) for each unit of measure referenced on the bill segment's usage request

Note:

Register Rules and SQ Rules. If the service agreement's rate has register rules or SQ rules, they may alter the amount of measured consumption or add additional units of measure to the SQ snapshot. Refer to Defining Measured Quantity Manipulation Rules for more information.

Lamps and estimated consumption. If any of the items linked to the service agreement's service points indicate the system should estimate consumption (e.g., lamps), additional entries will be added to the SQ snapshot for each such item. Refer to Setting Up Estimated Consumption For Items for more information.

Meter read details used for interim calculations are ignored when producing the service quantity snapshot.

Calculation / Audit Read Details

We use the term "calculation / audit read" to describe a meter read that appears on a bill segment but for which no "real" meter read exists. The following points provide examples of when calculation / audit reads may be required:

- Some retail companies upload meter read details when they upload pass through charges. They do this in order to print the read details that were used to calculate the pass-through charges. It should be stressed that these reads are not used to derive billable consumption (because the charges have already been calculated). These reads are only uploaded for printing purposes and therefore "real" meter reads are not created. We categorize these reads as "calculation / audit reads". Refer to Billable Charge Upload - Read Details for more information about uploading meter reads with pass-through charges.

- You may have interval billing rates where you're required to print the intervals that contain, for example, the intervals with the three highest peak charges. To do this, you setup a "calculation only" rate component to find these intervals and create a "calculation / audit read" for each such interval. Refer to RCCL-CVTOSC for an example of such an algorithm that would be plugged-in on a "calculation only" rate component.

- You may have interval billing rates that map interval consumption into time-of-use consumption. If you use a base-package algorithm to do this (refer to RCTMPS and RCTMS for examples), a "calculation / audit read" is created for each resultant time-of-use quantity. These algorithms do this in case you need this information for bill print purposes or in case you have multiple bill lines that need to use the same mapped consumption.

- You may have situations where a meter has been temporarily removed from a service point but the business practice dictates that usage for the service point should be calculated during billing.

- When integrating with an MDM, meter reads are stored outside of CCB and usage calculation requests are sent to MDM during billing. Reads used in the MDM usage calculation might be returned to CCB as part of the usage response. These reads are used for printing purposes and therefore "real" meter reads are not created in CCB. Instead these reads a re captured as "calculation / audit reads". Refer to Usage Requests for more information.

Both real and calculation / audit reads are stored in a bill segment's read details (the name of the table is CI_BSEG_READ ). The following points describe the differences between these two types of rows on this table:

- Calculation / audit reads may or may not reference a service point.

- Calculation / audit reads do not reference the prime key of a real read.

- Calculation / audit reads have a usage flag with a value of Calculation .

- Calculation / audit reads do not require a UOM code. If a UOM is not supplied, an SQI must be supplied.

If you encounter other scenarios during your implementation that necessitate calculation / audit reads, you can develop bill segment type and rate component algorithms to add additional calculation / audit reads to a bill segment's read details.

In order to avoid confusing end-users, we do not show calculation / audit reads on Bill Segment - Read Details (this page only shows "real" reads). Rather, calculation / audit reads are shown in a separate section on Bill Segment - SQ Details.

Calculation / Audit Usage Details

We use the term "calculation / audit usage" to describe service quantities retrieved from the bill segment's usage request. An example of when calculation / audit usage may be required:

- You may have situations where meter reads are not maintained in Oracle Utilities Customer Care and Billing and bill determinants are requested from a meter data management system via a usage request. MDM might return both bill determinants and meter reads to print on the bill.

Usage service quantities are also stored in a bill segment's read details (the name of the table is CI_BSEG_READ ). The following points describe the differences between these types of rows on this table:

- Calculation / audit usage may or may not reference a service point.

- Calculation / audit usage does not reference the prime key of a real read.

- Calculation / audit usage has a usage flag with a value of Service Quantity .

- Calculation / audit usage does not require a UOM code. If a UOM is not supplied, an SQI must be supplied.

If you encounter other scenarios during your implementation that necessitate calculation / audit usage, you can develop bill segment type and rate component algorithms to add additional calculation / audit usage to a bill segment's read details.

In order to avoid confusing end-users, we do not show calculation / audit reads on Bill Segment - Read Details (this page only shows "real" reads). Rather, calculation / audit usage is shown in a separate section on Bill Segment - SQ Details.

How To Override The Commodity Amount In A Bill Segment

As described earlier, the calculation of the amount consumed is one of the first steps that takes place when a bill segment is created. 99.9% of the time, the system does a perfect job in this effort. However, there are rare circumstances when, due to missing or incorrect data, the quantity calculated by the system is not what you want to charge the customer for (consider what the consumption should be if the meter is broken?).

To help you deal with these rare situations, a "back door" exists that allows a bill segment's billable quantities to be overridden. This truly is a "back door" because the proper way to fix the amount of a commodity is to correct the cause of the error and then cancel / rebill the bill segment.

Fastpath:

Refer to How To Override Service Quantities On A Specific Bill Segment for more information.

How Rates Affect The Information On Bill Segments

After consumption has been compiled, the system applies the service agreement's rate to the consumption to determine how much to charge the customer. We refer to this process as "rate application". Refer to Rates for detailed information about rates.

Note:

Not all service agreements use a rate! There are a small number of service agreements that don't use a rate to calculate the charges that appear on their bill segments. For example, a service agreement used to levy a customer's payment arrangement amount doesn't need a rate because the amount to charge is defined on the service agreement. Whether or not a service agreement needs a rate is defined by the service agreement's SA type. Whether or not the system calls the service agreement's rate to calculate charges is controlled by the bill calculation algorithm plugged-in on the bill segment type that's referenced on the service agreement's SA type. Refer to Designing and Defining Bill Segment Types for a description of the various bill segment creation algorithms that are supported in the system.

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 & Price 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 read details that were amassed earlier are passed into rate application.

- First, the rate schedule's register rules (if any) are executed. Register rules are used to manipulate the amount consumed on each read detail. For example, gas rates typically use one or more register rules to convert a cubic foot / meter into a thermal unit. Each affected read detail is updated to show the before and after quantities.

- Next, the total amount of each unique unit of measure / time-of-use code that's referenced on every read detail is summarized in the bill segment's "service quantity (SQ) details". For example, if a service agreement has 3 meters and each meter has one register that measures kWh, there will be three read details (assuming there are not meter exchanges during the bill period). In this step, the total amount from all three read details is summarized in one entry in the bill segment's SQ details.

- Next, the rate schedule's service quantity rules (if any) are executed. Service quantity rules are used to calculate service quantities (SQ) referenced in the rate that cannot be derived from the read details. For example, if you have a rate that has a charge based on the number of days in the bill period, a service quantity rule would be necessary to calculate the number of days in the bill period.

- Next, 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:

- Both online and batch billing use 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 consumption that's passed into rate application and then rate application shows you the calculation details that result.

- Plug-ins exist that call rate application to estimate bill segments when adequate billing history doesn't exist. For example, the BUDCALC-PH budget recommendation algorithm calls rate application to calculate a budget amount for a customer without adequate history. Another example is the DEPRECOM-MBT deposit recommendation algorithm. This plug-in calls rate application to calculate a recommended deposit amount for a customer without adequate history.

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 service agreements. The word "attempt" is stressed because a service agreement 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 service agreements. However, this is not sensible. Why? Because the system would attempt to create a bill every month for the account's service agreements, but only twice during the year would it succeed (because the service agreements 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 service agreements. In this scenario, every two weeks the system would create a bill that contains at least one bill segment (for the biweekly service agreement). However, 12 times a year, the bill will contain an additional bill segment for the monthly service agreement. And 4 times a year, the bill will contain one more bill segment (for a total of 3) for the quarterly service agreement.

In sum, the account's bill cycle controls when the system attempts to create a bill for the account's service agreements. Whether a service agreement 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 a service agreement.

Important:

An account's bill cycle should attempt to create bill segments at least as often as the shortest service agreement duration. For example, if an account has both monthly and quarterly service agreements, the account should be placed on a monthly bill cycle. Refer to How Does An Account Get Its Bill Cycle? for more information.

Fastpath:

For more information about bill cycles, refer to Defining Bill & Service Cycles.

Contents

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 a service agreement 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 consumption period. The consumption period defines the period of time used to calculate the number of days for daily charges.

The consumption period almost always starts one day after the bill segment period. The consumption 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 consumption 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 consumption period and we don't want to count it twice).

The only time when the previous paragraph isn't true is the first bill segment that's produced for a new service agreement. This is because different companies count the first day of a new service agreement differently than others. Refer to Initial Consumption Period Considerations for examples and an explanation of how you can control the start date of the consumption period.

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 a service agreement's bill segments:

- Meter Read Date. For service agreements with metered consumption (excluding real time meters), the end date is the date of the meter read used on the last day of the bill segment. This is a deceptively disingenuous statement because the algorithm used to select this end read is complex (and it relies on the service cycle schedule - hence the name of this option).

- Bill Period Schedule. Non-metered service agreements 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, non-metered service agreements may have their bill segment end date based on the first day of service. For example, if service started on the 16 th of some month, the ongoing bill segments will start on roughly the 16 th of each month. This option is frequently used to bill for garbage or cable service.

- ASAP. For non-meter service agreements that use neither the Bill Period Calendar nor Anniversary methods, the system assumes the end date of a bill segment is the current date. This option is frequently used for service agreements that deal with items (e.g., street lamps, phone booths).

- Billable Charge. For non-metered service agreements 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.

Contents

Using The Meter Read Date Method

Using The Bill Period Schedule Method

Using The Anniversary Method

Using Billable Charges

Using The Meter Read Date Method

A metered service agreement's SA type does not contain a specific indication that the service agreement is used to charge for metered service. Rather, if the system finds metered service points linked to the service agreement, it knows to use a meter read date as the end date of the bill segment. The trick is finding the perfect read amongst many possible reads. Refer to Meter Read Snapshot for a description of how the system finds the perfect end read.

Note:

If the next read date is in the future. The system will not create a bill segment for a metered service agreement if the next expected read date is in the future. The system determines the next expected read date using the service cycle schedule linked to the service agreement's service points.

Multiple scheduled read during a bill period. A base-package Get Consumption algorithm let's you control what happens when a service agreement's service point(s) have multiple scheduled meter readings during a bill period. You have two choices: 1) create a single bill segment using the latest scheduled meter read for the bill period, or 2) create a separate bill segment for every scheduled meter read during the bill period. The choice is yours. Refer to BSGC-SP for a description of the base-package algorithm type.

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 service agreement's SA type indicates if the service agreement uses this method, and if so, the specific 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.

Fastpath:

For more information about bill periods, refer to Designing Bill Periods.

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 a service agreement started on the 16 th of some month, the ongoing bill segments will start on roughly the 16 th of each month. This method is frequently used to bill for garbage or cable service. 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 a service agreement'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 service agreement's SA type indicates if the service agreement uses this method, and if so, the billing frequency.

Fastpath:

For more information about the SA Type attributes that control this method, refer to Setting Up SA Types.

Using Billable Charges

Bill segments for billable charge service agreements 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 A One-Time Invoice . 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 service agreement's SA type indicates if the service agreement uses this method, and if so, the billing frequency.

Fastpath:

For more information about the SA Type attributes that control this method, refer to Setting Up SA Types.

Preventing Short Bill Segments

Every SA 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 & Price Proration for more information about how charges are prorated during rate application.

Batch Billing

99.9% of all bills are 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 customer. The other 0.1% are created by users on-line / real time. This section discusses several important concepts associated with batch billing.

Contents

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 customer 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, 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 Cycle Schedules 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 customers.

Reopening A Batch Of Bills After They're Complete

If you need to reopen an entire batch of bills because they were completed prematurely (e.g., payments did not get posted before billing ran, so recent payments were not reflected in the account balances), 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 each night 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 customer.

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.

Contents

Billing - Current Balance versus Payoff Balance

The Source Of GL Accounts On A Bill Segment's Financial Transaction

Determining the Statistical Quantity

Billing - Current Balance versus Payoff Balance

A bill segment's financial transaction affects a service agreement's payoff balance and/or current balance. In this section, we describe these two balances.

Warning:

If you do not understand the difference between payoff balance and current balance, refer to Current Amount versus Payoff Amount.

Contents

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 service agreements, payoff balance and current balance are always the same (or in colloquial speech - the amount the customer 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 service agreements, payoff balance and current balance differ (or in colloquial speech - the amount the customer thinks they owe differs from what they would owe if they wanted to pay off their account).

Let's run through an example of a customer on a budget to illustrate a classic service agreement where these two balances are not the same. The values in the payoff balance and current balance columns reflect the amount due after the financial transaction has been applied:

Date

Financial Transaction

Payoff Balance

Current Balance

1-Jan-99

Bill: $125, Budget $150

125

150

15-Jan-99

Payment: $150

-25

0

2-Feb-99

Bill: $175, Budget $150

150

150

14-Feb-99

Payment: $150

0

0

3-Mar-99

Bill: $200, Budget $150

200

150

15-Mar-99

Payment: $150

50

0

The following table describes the various types of service agreements where these balances may differ.

Type Of Service Agreement

What Payoff Balance Holds

What Current Balance Holds

Deposit

Payoff balance holds the amount of deposit you are holding on behalf of the customer's debt. This amount is showed as a credit (with a negative sign) because you truly owe the customer this money.

Current balance holds the amount the customer owes for a deposit.

Charitable contribution

N/A - charitable contribution service agreements never have a payoff balance.

Current balance holds the amount the customer owes for a charitable contribution.

Payment arrangements

Payoff balance holds the total amount of delinquent debt that remains unpaid. When a payment arrangement is started, you transfer the payoff balance from the utility service agreement to the payment arrangement service agreement. Each billing period, the customer pays down this balance.

Current balance holds the amount the customer owes in respect of the billed payment arrangement amounts.

Service agreements on a budget plan

Payoff balance holds the actual amount owed (actual bills minus payments).

Current balance holds the amount the customer owes in respect of the billed budget amount.

Bill Segment Type Controls Which Balance(s) Are Affected

Every bill segment references a bill segment type (the bill segment type comes from its service agreement's SA 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 Designing and 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.

Determining the Statistical Quantity

The statistical quantity for each general entry line in the financial transaction is populated by adding together the statistical quantity for all bill calculation lines for the same distribution code. The bill calculation line indicates a statistical quantity if its corresponding rate component has marked the GL statistical quantity setting.

The statistical quantity for a bill calculation line is the prorated billable quantity for that line.

- If the corresponding rate component for the bill calculation line is not marked measures peak, then the statistical quantity corresponds to the billable quantity for the bill line. This is because billable quantities for SQs that do not represent a peak quantity are prorated when applying the rate.

- If the corresponding rate component for the bill calculation line is marked measures peak, then the statistical quantity may not correspond to the billable quantity for the bill calculation line. SQs that measure peak are not prorated when applying the rate. However, when determining the statistical amount to send to the general ledger, the quantity is prorated in the same manner as quantities that do not measure peak amounts.

Note:

Bill Calc Line Statistical Quantity. The statistical quantity for each bill calculation line is calculated when generating the bill segment and used to populate the statistical quantity for the FT GL entry. The calculated value is not saved in the bill calc line record.

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.

Contents

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 its bill segments depending on the source of the bill message code. In other words, messages associated with a service agreement (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 customer class 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 Customer Class Bill Messages.

- All permanent and temporary bill messages linked to service agreements that contributed bill segments to the bill are linked to their respective bill segment when the bill is completed. Refer to Service Agreement - Miscellaneous for more information. Note well that all temporary bill messages are removed from the service agreement when they are swept onto a bill segment (a temporary message is swept onto the next bill segment produced for the service agreement).

- 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 .

- The system checks if the service provider associated with each sub bill segment 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 Service Provider - Bill Messages.

- The system checks if the meter read remarks referenced on meter reads used on a bill segment have 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 Meter Read Remark - 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, service agreements, 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 Thank you for your charitable contributions in 2000 for $123.12, please keep this bill for tax purposes . 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 - Thank you for your charitable contributions in %1 for %2, please keep this bill for tax purposes .

- 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).

Please see the background process identified by the process ID REACH for an example of a background process that performs this type of function. Please see the algorithm identified by DEP PIF MSG for an example of an algorithm that performs this type of function.

- 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 Customer Balances

The topics in this section provide information about obscure things that may happen when a bill is created, frozen, or canceled.

Contents

Auto Cancel / Rebill If A Service Agreement Is Stopped Retroactively

Cancel Historical, Estimated Bill Segments When A Real Read Is Found

Deposits May Be Refunded

FT Freeze Repercussions

Auto Cancel / Rebill If A Service Agreement Is Stopped Retroactively

If the system detects a bill segment with a bill date after the stop date of the service agreement (because the service agreement was retroactively stopped), the system automatically cancels the bill segment and creates a new one with an end date equal to the service agreement's stop date.

Cancel Historical, Estimated Bill Segments When A Real Read Is Found

A special plug-in spot exists on bill segment type that can be used to automatically cancel historical, estimated bill segments when a "real" read is used on the current bill. Refer to BSAXERLIM for more information about this algorithm. This algorithm would typically be specified on bill segment types that calculate bills using meter reads.

Note:

This algorithm is called by the system when creating bills in batch. It does not get called when a user creates bills online.

Deposits May Be Refunded

Fastpath:

Refer to Refunding Deposits for how deposits may be refunded when a deposit service agreement is "final billed".

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).

Budget Billing

The topics in this section provide background information about a variety of budget billing issues.

Fastpath:

We strongly recommend familiarizing yourself with the topics described in Designing and Defining Budget Plans to fully appreciate how budgets fit into the system's financial architecture.

Contents

Account versus Service Agreement

How To Set Up A Customer To Participate In A Budget Plan

The Financial Impact Of Budget Plans

Budget Billing Background Processes

Canceling A Budget

Account versus Service Agreement

Customers who pay on a budget plan tend to believe that there is one budget amount applied to their account's bill each month. This is not true. Rather, each service agreement has an individual budget amount (stored in the recurring charge array). The sum of an account's service agreements' budget amount is the account's budget amount.

Why does each service agreement have a unique budget amount? Because all financial accounting in the system is performed at the service agreement level, not for an entire account.

While a unique budget amount is defined for each service agreement, a user can use a simple page to view and change the budget amount for all eligible service agreements linked to an account.

It's important to be aware that some service agreements linked to an account may not be eligible for budget plans. For example, assume you have a customer with a deposit service agreement and one or more utility service agreements. This customer will be billed for their deposit regardless of the utility service agreements' budget amounts. You define whether a service agreement may participate in a budget plan on the service agreement's SA type.

How To Set Up A Customer To Participate In A Budget Plan

If a customer wants to participate in a budget billing plan, simply transfer to Account - Budget and generate a new budget for the customer.

The Financial Impact Of Budget Plans

The only difference between a customer who participates in budget billing and one who doesn't is that budget billing customer have bill segments where payoff amount differs from current amount. Why? Because the payoff amount is the actual amount of the bill. The current amount is the amount the customer is expected to pay (i.e., their budget amount).

Let's run through an example of a customer on a budget to illustrate a service agreement where these two balances are not the same. The values in the payoff balance and current balance columns reflect the amount due after the financial transaction has been applied:

Date

Financial Transaction

Payoff Balance

Current Balance

1-Jan-99

Bill: $125, Budget $150

125

150

15-Jan-99

Payment: $150

-25

0

2-Feb-99

Bill: $175, Budget $150

150

150

14-Feb-99

Payment: $150

0

0

3-Mar-99

Bill: $200, Budget $150

200

150

15-Mar-99

Payment: $150

50

0

Fastpath:

For more information about current and payoff amounts, refer to Current Balance versus Payoff Balance.

Budget Billing Background Processes

The topics in this section describe the background processes that automate management of customer who participate in budget billing plans.

Note:

Budget Processing. The budget background processes only calculate budget amounts for pending start, active and pending stop SAs whose start and end date (if any) includes the budget date. Additionally, the budget date is used to select the rate schedule that is in effect for an SA if estimating consumption is necessary.

Contents

Budget True Up

Budget Monitor

Budget True Up

The Budget True Up background process (referred to by the batch control ID of BUDTRUP ) examines all accounts who participate in budget billing plans. If enough time has passed since the customer's budget was last trued up, the system will calculate the account's recommended budget amount. If the recommended amount differs from their existing budget amount by more than a given tolerance percentage, the customer's budget amount (actually, the recurring charge amount on the account's service agreements) will be changed.

Fastpath:

The amount of time between true ups and the true up method used to true up is defined on the account's budget plan. The tolerance percentages are defined as parameters of the true-up algorithm that is plugged in on the account's budget plan. Refer to Designing and Defining Budget Plans for all the details.

Budget Monitor

The Budget Monitor background process (referred to by the batch control ID of BUDMON ) examines all accounts that participate in budget billing plans. If the account's existing budget amount is out-of-sync with predefined tolerance percentages, the system will highlight the account on the Budget Review page.

Fastpath:

The tolerance percentages are defined as parameters of the budget monitor algorithm that is plugged in on the account's budget plan. Refer to Designing and Defining Budget Plans for all the details.

Canceling A Budget

The following points describe when a budget is cancelled:

- A user can cancel a budget at any time by using the Cancel Budget action on the Account - Budget page.

- The system may cancel a budget during a collection process (if the collection process contains a Cancel Budget collection event). Refer to Types Of Collection Events for more information.

- When a service agreement is stopped, the system automatically cancels the budget.

When a customer's budget is cancelled, the following events transpire:

- Any recurring charge entry whose effective date is after the cancel date is deleted. This is possible if you are entering a back-dated stop date for the service agreement. For example, perhaps you run the Budget True Up process, which adds a new budget amount to the service agreement (effective today). Then imagine that the customer calls you and informs you that they moved out last week. If you stop the customer's service as of last week, the recurring charge effective today is deleted when the stop is finalized.

- A new recurring charge amount of zero is created for each of the customer's service agreement.

- Each service agreement's current balance is synchronized with its payoff balance (using the sync adjustment code defined on the service agreement's SA type).

Net Energy Metering

The topics in this section provide background information on net energy metering.

What Is Net Energy Metering?

Customers in a distributed generation energy market may have renewable energy devices such as solar panels or wind turbines connected to their meters. The energy generated at this service point, as well as any energy used, could possibly be measured by a single meter, with the energy generated being netted against the energy used. This is called net energy metering (NEM). The meter records a positive number when customers use more energy than they generate, and a negative number when they generate more than they consume. These customers may owe a minimum charge each month. Their actual energy charges and generation credits are accrued until the account is adjusted at the end of a specified period, called the true up period. When the account is trued up, the consumption charges and generation credits for the period are combined to determine if the customer owes money to the utility.

Net Energy Metering Service Agreements

As mentioned in the previous section, net energy metering (NEM) customers typically owe a minimum charge each month while their actual energy charges and generation credits are accrued until true up time. This is accomplished by setting up a master service agreement (SA) to hold the monthly minimum charge and a sub service agreement to hold the customer’s actual energy charges and generation credits.

For more information about service agreement relationships, refer to Defining SA Relationship Options.

Net Energy Metering True Up

To facilitate the true up process, each true up period will be represented by a sub service agreement. Each sub service agreement will be monitored by a true up monitor (TUM), a service task which is responsible for: performing the true up process at the end of the true up period; reversing true up transactions when cancel/rebills affect a period that has been trued up; synchronizing itself with any changes on its master service agreement or service agreement relationship (e.g., if the service agreement relationship is deleted, the true up monitor will cancel itself); and creating the service agreement relationship and sub service agreement for the next true up period.

A service agreement creation algorithm on the master service agreement type is responsible for creating the initial sub service agreement and service agreement relationship. Subsequent sub service agreements are created in the true up monitor lifecycle. A service agreement creation algorithm on the sub service agreement type is responsible for creating the true up monitor. A link to the true up monitor service task is available from the characteristics page of the sub service agreement. It is important to note that the true up monitor is not a user-maintained object. End-users will not normally need to access the true up monitor. All that is visible on the true up monitor is its type, status, related sub service agreement and account. As always, relevant financial history will be accessible from the sub service agreement.

The Lifecycle of a True Up Monitor

The following diagram shows the lifecycle of the True Up Monitor business object:

Active State: The true up monitor starts out in the Active state. Here the true up monitor is evaluated for true up processing or possible cancellation. The system will perform a true up if either the true up period has come to an end, or the service agreement is final billed.

The amount of time between true ups is defined on the true up task type. See Setting Up the System for Net Energy Metering for a description of how true up task types are configured.

Canceled State: The true up monitor is transitioned to the Canceled state if its service agreement is canceled or deleted. Because the service agreement associated with a true up monitor is a sub service agreement, it is possible that the stop date on the sub service agreement is backdated to a point prior to the start of its associated service agreement relationship. In this case, the true up monitor is also canceled.

Trued Up State: If it is time for true up, the true up monitor is transitioned to the Trued Up state. True up processing involves summing the sub service agreement’s bill segments to see if the customer owes any debt (i.e., the energy they generated was not enough to cover the energy they consumed). If the sum is positive, the amount is transferred to the master service agreement for the customer to pay off. If the sum is negative, the sub service agreement balance is brought to zero (the utility keeps the credit). If your implementation wants to issue refunds to customers who generate more energy than they consume, you will need to design your own algorithm for the true up process.

The adjustment types used to transfer or zero out the sub service agreement balance are defined on the true up monitor type. See Setting Up the System for Net Energy Metering for a description of how true up monitor types are configured.

Reverse True Up State: Once the financial true up is done, a new service agreement relationship and sub service agreement are created for the subsequent true up period. If cancel/rebillls occur after the true up process has been performed, the true up monitor is transitioned to the Reverse True Up state. Any adjustments that were previously created are canceled as part of this processing. Thereafter the true up monitor is transitioned back to the Active state, where it waits until bill completion attempts another true up.

Setting Up the System for Net Energy Metering

This section summarizes the various tasks required for setting up your system for net energy metering.

Adjustment Types

The following adjustment types are used at true up time:

- Current Balance True Up. This is the adjustment type used in syncing the payoff and current amounts on the sub service agreement associated with the true up period. This adjustment type should reference an FT algorithm of Payoff Amount = 0 / Current Amount = Adj Amount (no GL).

- Transfer To Master. This is the adjustment type used to transfer the customer’s balance from sub service agreement to master service agreement if a positive payoff balance exists on the sub service agreement after true up.

- Write Down. This is the adjustment type used to bring the payoff balance of the sub service agreement to zero if a negative payoff balance exists after true up.

Adjustment Type Profile

Create an adjustment type profile that references the adjustment types used in net energy metering billing.

True Up Task Type

To enable billing for net energy metering, your implementation must configure a True Up Task Type. This service task type captures the various configuration options that are used by the true up monitor’s algorithms:

- Minimum Days In True Up Period defines the minimum number of days covered by the bill segments within a true up period before true up processing can occur

- The task type captures the adjustment types used at true up time

- Reversal Adjustment Cancel Reason is used on true up adjustments that are canceled as a result of cancel/rebill activity occurring after a true up

Algorithms

Add the following algorithms:

- The sub service agreement and service agreement relationship are initially created by an SA Creation algorithm on the master service agreement type. The base package provides algorithm type C1-SAT-SARL for this purpose. An algorithm should be configured with the service agreement relationship type to use.

- Creation of the true up monitor is handled by an SA Creation algorithm on the sub service agreement type. The base provides algorithm type C1-SAT-TUM for this purpose. The true up monitor service task type is defined as an algorithm parameter.

- Whenever a net energy metering sub service agreement is canceled, its associated true up monitor should also be canceled. The base provides algorithm C1-CNC-TUM to be plugged in as an SA Cancel algorithm on the sub service agreement type to accomplish this.

- The true up monitor is transitioned out of the Active or Reverse True Up state by the billing process. To that end, a Bill Completion algorithm needs to be configured on the master service agreement type. This algorithm is responsible for transitioning any true up monitor that is in an Active or Reverse True Up state that is related to the master service agreement. The base provides the algorithm C1-TRN-TUM for this purpose.

- When cancel/rebills occur, financial transactions related to the true up need to be reversed. To accomplish this, an FT Freeze algorithm must be plugged in on the sub service agreement type. The base provides algorithm C1-RV-TRUP for this purpose.

For more information on setting up service agreement Relationships, refer to Defining SA Relationship Options. For more information on service agreement type algorithms, refer to SA Type - Algorithms.

Your implementation must also decide if the sub service agreement’s bill segment financial transactions should impact the general ledger or not. This is controlled by the Financial Algorithm on the bill segment type defined for the sub service agreement type. The base provides algorithms C1-C0-GL and C1-C0-NOGL for this purpose. For more information on configuring Bill Segment Types, refer to Designing and Defining Bill Segment Types.

Net Energy Metering Billing Examples

This section contains billing examples for net energy metering. The examples assume the following:

- The customer is billed quarterly using the following tariff:

- Customer charge of $3/day (billed on master service agreement)

- $0.10 per kWh (billed on sub service agreement and trued up after 12 month period)

- The GL Accounting distribution codes used in the following tables, such as A/R-NEM and NEM-Liability, are for example only. Your implementation will specify its own distribution codes.

- A True Up Task Type that references the base product NEM business objects with the following configuration:

- Minimum Days In True Up Period: 365

- Sync Current Adjustment Type: NEM SYNC
This is the adjustment type used to synchronize (make equal) the sub service agreement’s current amount with the payoff amount at true up time.

- Transfer Adjustment Type: NEM XFER
This is the adjustment type used to transfer debt from the sub service agreement to the master service agreement at true up time.

- Write Down Adjustment Type: NEM WDWN
This is the adjustment type used to write down any remaining amount on the sub service agreement after we attempt to transfer debt to the master service agreement at true up time.

Example 1: Customer Consumes More Than They Generate

The following table outlines the customer’s master service agreement financial transactions in 2010. Adjustments created in the true up period are in bold. In this example the customer’s net energy results in an outstanding balance of $330 which is transferred from the sub service agreement to the master service agreement, leaving the sub service agreement for that true up period with a zero balance.

Event

GL Accounting

Effect On Payoff Amount

Effect On Current Amount

Payoff Balance

Current Balance

Bill Segment (1/1–3/31)

(90 days * $3/day = $270)

A/R-NEM 270

NEM-Liability <270>

270

270

270

270

Payment

Cash 270

NEM-A/R <270>

-270

-270

0

0

Bill Segment (4/1–6/30)

(91 days * $3/day = $273)

A/R-NEM 273

NEM-Liability <273>

273

273

273

273

Bill Segment (7/1–9/30)

(92 days * $3/day = $276)

A/R-NEM 276

NEM-Liability <276>

276

276

549

549

Payment

Cash 549

A/R-NEM <549>

-549

-549

0

0

Bill Segment (10/1–12/31)

(92 days * $3/day = $276)

A/R-NEM 276

NEM-Liability <276>

276

276

276

276

NEM XFER true up adjustment (transfer from sub service agreement)

A/R-NEM 330

XFER <330>

330

330

606

606

The following table outlines the customer’s sub service agreement financial transactions (FTs). Note that bill segment financial transactions affect the customer’s pay off balance only. Adjustments created in the true up period are in bold below and reflect the following:

- First, the current balance to the payoff balance is set using the sync adjustment type (NEM SYNC) on the service task type.

- Second, any debt from the sub is transferred to the master service agreement using sync adjustment type on the service task type (NEM XFER).

Event

GL Accounting

Effect On Payoff Amount

Effect On Current Amount

Payoff Balance

Current Balance

Bill Segment (1/1–3/31)

(1200kWh * $0.10 = $120)

A/R-NEM 120

NEM-Liability <120>

120

0

120

0

Bill Segment (4/1–6/30)

(500kWh * $0.10 = $50)

A/R-NEM 50

NEM-Liability <50>

50

0

170

0

Bill Segment (7/1–9/30)

(600kWh * $0.10 = $60)

A/R-NEM 60

NEM-Liability <60>

60

0

230

0

Bill Segment (10/1–12/31)

(1000kWh * $0.10 = $100)

A/R-NEM 100

NEM-Liability <100>

100

0

330

0

NEM SYNC adjustment (sync current to payoff)

n/a

0

330

330

330

NEM XFER adjustment (transfer to master service agreement)

XFER 330

A/R-NEM <330>

-330

-330

0

0

Example 2: Customer Generates More Than They Consume

The following table outlines the customer’s master service agreement financial transactions (bill and payment segments are exactly the same as in example 1 above). In this example the customer’s net energy results in a credit balance on the NEM sub service agreement which is written off, leaving the sub service agreement for that true up period with a zero balance (credits are not transferred to the master service agreement).

Event

GL Accounting

Effect On Payoff Amount

Effect On Current Amount

Payoff Balance

Current Balance

Bill Segment (1/1–3/31)

(90 days * $3/day = $270)

A/R-NEM 270

NEM-Liability <270>

270

270

270

270

Payment

Cash 270

A/R-NEM <270>

-270

-270

0

0

Bill Segment (4/1–6/30)

(91 days * $3/day = $273)

A/R-NEM 273

NEM-Liability <273>

273

273

273

273

Bill Segment (7/1–9/30)

(92 days * $3/day = $276)

A/R-NEM 276

NEM-Liability <276>

276

276

549

549

Payment

Cash 549

A/R-NEM <549>

-549

-549

0

0

Bill Segment (10/1–12/31)

(92 days * $3/day = $276)

A/R-NEM 276

NEM-Liability <276>

276

276

276

276

The following table outlines the customer’s sub service agreement financial transactions (FTs). Note that bill segment financial transactions affect the customer’s pay off balance only. Adjustments created in the true up period are in bold below and reflect the following:

- First, the current balance is set to the payoff balance using the sync adjustment type (NEM SYNC) on the service task type.

- Because a credit remains on the sub service agreement, this amount will be written off using the write down adjustment type on the service task type (NEM WDWN).

Event

GL Accounting

Effect On Payoff Amount

Effect On Current Amount

Payoff Balance

Current Balance

Bill Segment (1/1–3/31)

(80kWh * $0.10 = $8)

A/R-NEM 8

NEM-Liability <8>

8

0

8

0

Bill Segment (4/1–6/30)

(-120kWh * $0.10 = $-12)

A/R-NEM <12>

NEM-Liability 12

-12

0

-4

0

Bill Segment (7/1–9/30)

(-80kWh * $0.10 = $-8)

A/R-NEM <8>

NEM-Liability 8

-8

0

-12

0

Bill Segment (10/1–12/31)

(100kWh * $0.10 = $10)

A/R-NEM 10

NEM-Liability <10>

10

0

-2

0

NEM SYNC true up adjustment (sync current to payoff)

n/a

0

-2

-2

-2

NEM WDWN true up adjustment (write down credit)

NEM A/R 2

E - W/O <2>

2

2

0

0

For more information about current and payoff amounts, refer to Billing - Current Balance versus Payoff Balance.

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 customer'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:

- Customers with pass through charges will need a separate service agreement to hold the pass through charges. We refer to this type of service agreement as a "billable charge" service agreement.

Note:

A service agreement's SA type controls whether a service agreement can have billable charges linked to it. Specifically, the SA type must have a "special role" of Billable Charge .

- A billable charge service agreement holds the billable charges until the customer is next billed. At that time, a separate bill segment will be created for each unbilled billable charge linked to the billable charge service agreement.

- While it is not required, we recommend creating a separate billable charge service agreement for each type of pass through charge. For example, if you can receive "pass through" charges from the local water company and the local cable company, we'd recommend having two billable charge service agreements for each customer.

- As described under We Bill For Them, you can setup the system to automatically create billable charge service agreements when you start regular service for your customers. If you take this approach, you can also have the system create the payable transaction to pay the 3 rd party. Refer to Pay At Bill Time vs. Pay At Pay Time for more information.

- 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 customer.

- Service quantities that are used by the system to calculate the charges on behalf of the third party. For example, the 3 rd party may pass through the number of kilowatt hours and you calculate the bill lines for them. Refer to Uploading Consumption Rather Than Bill Lines for more information.

- Meter read details that you want printed on the bill. Note, the base package bill segment creation algorithm simply sweeps billable charge read details onto the related bill segment's read detail. This algorithm does NOT use these reads to derive service quantities. This is intentional as most implementations that import reads also import service quantities and therefore deriving service quantities is unnecessary (and also error prone). If your implementation needs to derive service quantities from these reads, you can develop your own bill segment creation algorithm to do just this.

- All of the above. You might interface both bill lines and service quantities if the third party calculated the charges but did not calculate the taxes. The dollar amount for which taxes will be calculated would be defined using a service quantity. Refer to Calculating Taxes On Uploaded Charges for more information.

Note:

You cannot interface interval data via the billable charge interface. Rather, you would need to interface the interval data using the standard interval data set interface and then let the system calculate the charges for you.

- 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 contain information that is purely informational. For example, the 3 rd party might pass the start and end meter reads that they used to calculate the charges. You can use memo-only bill lines to show this information on the customer's bill. If a bill line is not memo-only (i.e., it affect the general ledger), a distribution code must also be specified to define how the lines affects the general ledger.

- Show on the customer bill. It is possible to create bill lines that affect the general ledger, but are not shown on the customer'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 service quantities are specified on a billable charge, they are saved on the bill segment created when the billable charge is billed. This means that they system can support creation of a graph of historical usage on the bill, as well as other queries on customer usage. In addition, it might be possible to event estimate consumption based on these service quantities (but such a plug-in is not supplied with the base package).

Note:

The system does not support passing in items (e.g., street lamps). This could be a problem if you need to perform ratable calculations for the 3 rd party based on, say, the number of street lights. However, if you require ratable, street light pass through billing, you can calculate a service quantity for each type of street light and save this information on the billable charge. The associated rate would then have a price per service quantity rather than a price per item type.

The system does not support sending in raw meter reads with billable charges. This consumption needs to be passed in as a service quantity. However, you can pass in meter read details to be printed on the bill segment.

- 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 customer. 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 combined on a single billable charge.

- In terms of the customer information setup, while a service agreement that holds billable charges does not need a service point, there are advantages to having this information in the system. For one thing, if jurisdictional taxes are being calculated by the system, the definition of the jurisdiction(s) is held on the service point or premise. Also, the link to the service point defines the service address, facilitates customer lookup, causes information to appear in Control Central's trees, etc.

- For most other functionality, the billable charge service agreement supports the same functionality as normal service agreements. This includes budget billing, payment distribution, credit & collection tracking and events, current & payoff balances, movement of old debt onto payment arrangements, etc.
Fastpath:

For more information about billing billable charges, refer to How To Create A One-Time Invoice. For more information about creating a billable charge, refer to Maintaining Billable Charges. For more information about creating sub service agreements to hold billable charges, refer to We Bill For Them. 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.

Contents

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

The Documaker Records

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 for interacting with bill print software, such as Documaker:

- 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 Image algorithm on the Installation Record. This type of algorithm will call the bill 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.

The bill route type controls the following for interacting with a reporting engine, such as BI Publisher:

- It contains an algorithm that is responsible for returning the appropriate report code and other information in order to extract the information to be merged onto your bills. Typically, the reporting engine itself is responsible for extracting and formatting the data. Algorithms of this type are called under the following scenarios:

- The background process that interacts with your reporting engine calls these algorithms.

- If your reporting engine has the ability to construct a real-time image of a bill, you can plug-in an Online Bill Image algorithm on the Installation Record. This type of algorithm will call the bill extract algorithm for an appropriate bill route type to return the appropriate report code. Refer to Technical Implementation Of Online Bill Image for the details.

- It contains the ID of the background process responsible for interacting with your reporting engine in batch.

Technical Implementation Of Online Bill Images

Users can view an image of any bill that is sent to a customer 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 can interact with either bill print software (such as Documaker) or a reporting engine (such as BI Publisher).

The system provides an Installation – Online Bill Display algorithm type (C1-BL-DISP) that interacts with Documaker to render an online image of your bill. The following points describe what takes place when clicking Display Bill.

- The algorithm based on this algorithm type calls the bill extract algorithm for an appropriate bill route type (as determined by the algorithm).

- The bill extract algorithm will construct the information that appears on the bill (refer to algorithm type C1-BLEX-XML for further details).

- The constructed information is passed to Documaker that will reconstruct the bill’s image in a PDF format.

- The system displays the PDF in a separate browser session. Note that the client must have Adobe Acrobat Reader installed to view PDF files.

Note:

Refer to The Documaker Records for examples of the record layouts passed to the Documaker print software.

The system also provides an Installation – Online Bill Display algorithm type (C1-ONLN-CR) that interacts with BI Publisher to render an online image of your bill. The following points describe what takes place when clicking Display Bill:

- The algorithm based on this algorithm type calls the bill extract algorithm for an appropriate bill route type (as determined by the algorithm).

- The bill extract algorithm returns the appropriate report code to the Online Bill Display algorithm, which in turn returns the report code to the bill page (refer to algorithm typeC1-BLEX-BIP for further details). This algorithm is not actually extracting data because when you use BI Publisher reports, the report itself is responsible for extracting and formatting the data.

- A user exit on the bill page invokes BI Publisher and displays the bill in a separate browser session.

Note:

Refer to Bill Print in BI Publisher for examples of the data extracted for the report.

Technical Implementation Of Printing Bills In Batch

The batch process that extracts bill related 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 bill extract algorithm on the routing record's route type. The algorithm formats the information to be passed to the bill print software or reporting engine. 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 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 accounts SA's are stopped , closed or cancelled ; the bill is flagged as being the final bill on the flat file produced by the postal routing process (refer to Bill Record - 0100 for the details of this switch).

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.

The Documaker Records

Numerous different types of records are interfaced to the Documaker software. However, they all share a common structure for bills:

- The first 4 bytes are called the Printer Key. This field is a record type used by the Documaker bill template.

- The next 184 bytes are called the Sort Key. This field is used to ensure the various records used to construct a printed bill appear in the correct order in the interface file.

- The next 12 bytes are called the Mailing Key. This field is used to control the order in which the formatted bills are printed.

- The next 3 bytes are a filler that is available for future use.

- The remaining bytes contain the Bill Information that appears on the printed bill. The type of information differs for each type of record.

The topics in this section describe each component.

Contents

Printer Keys (Record Types)

Sort Key

Mailing Key

Bill Information

Printer Keys (Record Types)

The following table defines each printer key (i.e., record type) on the bill print flat file.

Record Type

Description

Notes

0010

Global extract information

Required. 1 per flat file.

0100

Bill record

Required. 1 per bill.

0300

Current charge record

1 per current charge.

0600

Payment record

1 per payment.

0900

Premise record

1 per premise.

1100

Service agreement record

1 per SA linked to the premise.

1300

Bill segment record

1 per bill segment linked to the SA.

1500

Bill calculation header

1 per bill calculation header linked to the bill segment.

1700

Bill calc line

1 per bill calculation line linked to the bill calculation header

1900

End of record type 1500

1 for each bill calculation header

2100

Read detail

1 for each meter read detail linked to the bill segment

2400

Service quantity detail

1 for each service quantity detail linked to the bill segment

2700

Item detail

1 for each item detail linked to the bill segment

2840

Bill segment messages

1 for each message detail linked to the bill segment

2900

End of record type 1300

1 for each bill segment

3100

Consumption history (for graph)

1 for each historical consumption period that appears on the graph

3400

Adjustment detail

1 for each adjustment

3600

End of record type 1100

1 for each service agreement

3700

End of record type 0900

1 for each premise

3900

Bill message detail

1 for each message

9999

End of record type 0100

1 for each bill

Sort Key

The following table defines the structure of the sort key that appears on each bill print record. Please note that different components are filled in for each printer key.

Field Name

Format

Source/Value/Description

Bill Print Intercept

A8

This is the user ID, if any, who reviews the bill (as specified on the account record)

Bill ID

A12

Sequence Number

N2

The sequence number of the account / person information associated with this bill routing information.

Copy Number

N1

The number of copies desired by the account / person associated with this bill routing information.

Bill record group

A2

10 Bill

20 Payment

30 Current charge

40 Message

50 Non-Premise

55 Non-Premise end

60 Premise

70 Bill end

Filler

A2

Premise State

A6

Only applicable for Premise based records.

Premise City

A30

Only applicable for Premise based records.

Premise Address 1

A64

Only applicable for Premise based records.

Premise Id

A10

Only applicable for Premise based records.

Premise record group

A2

10 Premise record

20 SA level record

30 Premise end record

SA Print Priority

A2

SA Id

A10

SA Group

A2

For Premise based records:

10 SA

20 Histogram

30 Current charge

40 Adjustment

50 SA end record

For Non-Premise based records:

10 SA

20 Current Charge

30 Adjustment

40 SA end record

Bill Segment End Date

A10

If the record is related to an adjustment, this is the adjustment creation date.

If the record is for histogram detail, this contains the histogram detail number.

Bill Segment Id

A12

If the record is related to an adjustment, this is the adjustment ID.

Bill Segment Group

A2

10 Bill segment

20 Bill segment calculation group

30 Bill segment read detail

40 Bill segment SQ detail

50 Bill segment item detail

55 Bill segment message

60 Bill segment end

Bill Calc Header Sequence

N2

For records related to read detail, SQ detail, item detail or bill message detail, this field contains the related sequence number for that record.

Bill Calc Header Group

A2

10 Bill calculation header

20 Bill calculation line

30 Bill calculation end

Line Seq

N3

Defines order of rows for similar record types

Filler

65

Only applicable for non-premise based records. (This makes up for the premise address related fields that are not applicable above).

Mailing Key

The following table defines the structure of the mailing key that appears on each bill print record.

Field Name

Format

Source/Value/Description

Postal code

A12

This is the postal code on the bill routing record.

Bill Information

The topics in this section describe the information that appears on each on each bill print record.

Contents

Global Extract Information Record (0010)

Bill Record (0100)

Current Charge Record (0300)

Payment Record (0600)

Premise Record (0900)

Service Agreement Record (1100)

Bill Segment Record (1300)

Bill Calc Header Record (1500)

Bill Calc line Record (1700)

End Bill Calc Header Record (1900)

Bill Segment Read Record (2100)

Bill Segment SQ Record (2400)

Bill Segment Item Record (2700)

Bill Segment Message Record (2840)

End Bill Segment Record (2900)

Histogram Record (3100)

Adjustment Record (3400)

End Service Agreement Record (3600)

End Premise Record (3700)

Message Record (3900)

End Bill Record (9999)

Address Sub-record

Global Extract Information Record (0010)

This is a "header" record that contains information about the extract run as a whole.

Note:

Please be aware that if you do not sort your extract file by CIS Sort Key after it is produced, this record will physically be the last record on the extract file.

Field Name

Format

Source/Value/Description

BATCH_CD

A8

Batch Control Code of the extract process.

BATCH_NBR

N10

Batch Number of the extract process

BATCH_RERUN_NBR

N10

Batch Rerun number of the extract process.

BILL_CNT

N10

Count of bills on this extract. Multiple copies of a bill are counted multiple as well.

EXTRACT_DTTM

A26

System time of extraction. Also updated in bill routing table.

BILL_ID_START

A12

This is only used when a bill is produced as a result of an online request (from Bill - Main). It contains the Bill Id to extract.

BILL_ID_END

A12

This is only used when a bill is produced as a result of an online request (from Bill - Main). It contains the Bill Id to extract.

THREAD_NBR

N10

This field is only used if bills are extracted in batch. It contains the thread number in which the bill was extracted.

THREAD_CNT

N10

This field is only used if bills are extracted in batch. It contains the total number of threads that were extracted.

Bill Record (0100)

Field Name

Format

Source/Value/Description

BILL_ID

A12

CI_BILL

ACCT_ID

A10

CI_BILL

BILL_DT

D

CI_BILL

DUE_DT

D

CI_BILL

COPY_NBR

N1

NBR_BILL_COPIES

N1

CI_BILL_RTG

BILL_PRT_INTERCEPT

A8

CI_BILL_RTG

BILL_FORMAT_FLG

A2

CI_BILL_RTG

REPRINT_SW

A1

CI_BILL_RTG

CASH_ONLY_SW

A1

CUR_BAL

S13.2

CI_BILL_SA

CUR_CHG_AMT

S13.2

CI_FT

CUR_CORR_AMT

S13.2

CI_FT

CUR_ADJ_AMT

S13.2

CI_FT

CUR_PAY_AMT

S13.2

CI_FT

CUR_PREV_BAL

S13.2

CI_FT

TOT_BAL

S13.2

CI_BILL_SA

TOT_CHG_AMT

S13.2

CI_FT

TOT_CORR_AMT

S13.2

CI_FT

TOT_ADJ_AMT

S13.2

CI_FT

TOT_PAY_AMT

S13.2

CI_FT

TOT_PREV_BAL

S13.2

Computed during extract.

CURRENCY_CD

A3

CI_BILL_SA

DELINQUENT_AMT

S13.2

Computed during extract.

CUST_PO_ID

A20

CI_BILL_RTG

ACCT_ENTITY_NAME

A64

CI_PER_NAME. Account Entity Name. Might include prefix/suffix from Account/Person if available.

ENTITY_NAME

A64

CI_BILL_RTG. Mailing Entity Name.

ADDRESS_SBR

A361

CI_BILL_RTG. Refer to its components in a later section.

FINAL_BILL_SW

A1

Computed during extract. Contains a value of Y if this bill is considered to be a "final" bill.

SCHED_EXTRACT_DT

D

CI_APAY_CLR_STG. This is the date that the automatic payment will be downloaded.

ENTITY_NAME1

A64

CI_BILL_RTG. Mailing Entity Name1.

ENTITY_NAME2

A64

CI_BILL_RTG. Mailing Entity Name2.

ENTITY_NAME3

A64

CI_BILL_RTG. Mailing Entity Name3.

ACCT-CUR-SYMBOL

A4

Currency symbol for the account's currency code.

Current Charge Record (0300)

Field Name

Format

Source/Value/Description

DEBT-CLASS-CD

A4

Debt Class of SA Type

DEBT-CLASS-DESCR

A30

Debt Class Description

CUR-CHARGE-AMT

S13.2

Derived from CI_FT (Only the current charge bill segments.)

TOT-CHARGE-AMT

S13.2

Derived from CI_FT (Only the current charge bill segments.)

Payment Record (0600)

Field Name

Format

Source/Value/Description

FT TYPE

A2

Pay or Pay Cancel ('PS' or 'PX')

PAY-DT

D

Derived from CI_FT

CAN_RSN_CD

A4

Derived from CI_PAY, Only for cancellation

CAN-RSN-DESCR

A30

Derived form CI_PAY_CAN_RSN

CUR-PAY-AMT

S13.2

Derived from CI_FT.

TOT-PAY-AMT

S13.2

Derived from CI_FT.

Premise Record (0900)

Field Name

Format

Source/Value/Description

NON_PREM_SW

A1

Y/N switch to indicate (Y) special (non-premise) premise record. This is for non-premise service agreements such as charity or payment arrangement.

PREM_ID

A10

From CI_SA or CI_BSEG

ADDRESS_SBR

A361

Service Address (Address of Char Premise) from CI_PREM. Refer to its components in a later section.

Service Agreement Record (1100)

Field Name

Format

Source/Value/Description

SA_ID

A10

CI_SA

OLD_ACCT_ID

A15

CI_SA

CUST_READ_FLG

A2

CI_SA

SIC_CD

A4

CI_SA

SIC_DESCR

A30

CI_SIC

BUSINESS_UNIT

A10

CI_SA

SA_TYPE_CD

A8

CI_SA

SA_TYPE_DESCR

A30

CI_SA_TYPE

SA_TYPE_DFLT_DESCR

A80

CI_SA_TYPE

SVC_TYPE_CD

A2

CI_SA_TYPE

SVC_TYPE_DESCR

A30

CI_SVC_TYPE

REV_CL_CD

A8

CI_SA_TYPE

CHAR_PREM_ID

A10

CI_SA

SA_REL_ID

A10

CI_SA_REL

SA_REL_TYPE_CD

A8

CI_SA_REL

SA_REL_TYPE_DESCR

A30

CI_SA_REL_TYPE

SPR_CD

A12

CI_SA_REL

SPR_DESCR

A50

CI_SPR

SPR_ENTITY_NAME

A64

CI_PER_NAME (this is the service provider's person's name)

Bill Segment Record (1300)

Field Name

Format

Source/Value/Description

START_DT

D

CI_BSEG

END_DT

D

CI_BSEG

CLOSING_BSEG_SW

A1

CI_BSEG

EST_SW

A1

CI_BSEG

BILL_CYC_CD

A4

CI_BSEG

SQ_OVERRIDE_SW

A1

CI_BSEG

ITEM_OVERRIDE_SW

A1

CI_BSEG

BSEG_STAT_FLG

A2

CI_BSEG

CAN_RSN_CD

A4

CI_BSEG

CAN_RSN_DESCR

A30

CI_BILL_CAN_RSN

CUR_AMT

S13.2

CI_FT

TOT_AMT

S13.2

CI_FT

Bill Calc Header Record (1500)

Field Name

Format

Source/Value/Description

START_DT

D

CI_BSEG_CALC

END_DT

D

CI_BSEG_CALC

SETID

A10

CI_BSEG_CALC

RS_CD

A8

CI_BSEG_CALC

CALC_AMT

S13.2

CI_BSEG_CALC

DESCR_ON_BILL

A80

CI_BSEG_CALC

Bill Calc line Record (1700)

Field Name

Format

Source/Value/Description

APP_IN_SUMM_SW

A1

CI_BSEG_CALC_LN

CALC_AMT

S13.2

CI_BSEG_CALC_LN

EXEMPT_AMT

S13.2

CI_BSEG_CALC_LN

UOM_CD

A4

CI_BSEG_CALC_LN

TOU_CD

A8

CI_BSEG_CALC_LN

SQI_CD

A8

CI_BSEG_CALC_LN

BILL_SQ

S12.6

CI_BSEG_CALC_LN

DESCR_ON_BILL

A80

CI_BSEG_CALC_LN

End Bill Calc Header Record (1900)

Field Name

Format

Source/Value/Description

Dummy field

Bill Segment Read Record (2100)

Field Name

Format

Source/Value/Description

SP_ID

A10

CI_BSEG_READ

BADGE_NBR

A16

CI_MTR

UOM_CD

A4

CI_BSEG_READ

TOU_CD

A8

CI_BSEG_READ

RDG_DEC_POS

N1

CI_REG. Decimal positions of the reads.

START_REG_READING

S9.6

CI_BSEG_READ

START_READ_DTTM

T

CI_BSEG_READ

START_ESTIMATE_SW

A1

CI_REG_READ

END_REG_READING

S9.6

CI_BSEG_READ

END_READ_DTTM

T

CI_BSEG_READ

END_ESTIMATE_SW

A1

CI_REG_READ

MSR_QTY

S12.6

CI_BSEG_READ

USAGE_FLG

A2

CI_BSEG_READ

USE_PCT

N3

CI_BSEG_READ

HOW_TO_USE_FLG

A2

CI_BSEG_READ

CONSUM_SUB_FLG

A2

CI_REG

MSR_PEAK_QTY_SW

A1

CI_BSEG_READ

REGISTER_CONST

S6.6

CI_BSEG_READ

QTY_DEC_POS

N1

CI_UOM. Decimal positions of the final quantity.

FINAL_UOM

A4

CI_BSEG_READ

FINAL_TOU

A8

CI_BSEG_READ

FINAL_REG_QTY

S12.6

CI_BSEG_READ

SQI_CD

A8

CI_BSEG_READ

FINAL_SQI_CD

A8

CI_BSEG_READ

Bill Segment SQ Record (2400)

Field Name

Format

Source/Value/Description

UOM_CD

A4

CI_BSEG_SQ

TOU_CD

A8

CI_BSEG_SQ

SQI_CD

A8

CI_BSEG_SQ

SQ_DEC_POS

N1

CI_BSEG_SQ

BILL_SQ

S12.6

CI_BSEG_SQ

Bill Segment Item Record (2700)

Field Name

Format

Source/Value/Description

START_DT

D

CI_BSEG_ITEM

END_DT

D

CI_BSEG_ITEM

ITEM_CNT

S9.2

CI_BSEG_ITEM

ITEM_DESCR

A30

CI_ITEM_TYPE

Bill Segment Message Record (2840)

Field Name

Format

Source/Value/Description

BILL_MSG_CD

A4

CI_BSEG_MSG

MSG_ON_BILL

A254

CI_BILL_MSG_L

End Bill Segment Record (2900)

Field Name

Format

Source/Value/Description

Dummy field

Histogram Record (3100)

Field Name

Format

Source/Value/Description

UOM_CD

A4

CI_SA_TYPE

TOU_CD

A8

SQI_CD

A8

SQ_DEC_POS

N1

CI_UOM. Decimal positions of SQ.

SQ_CNT

N2

Count of SQ (maximum of 13.)

MAX_BILL_SQ

S12.6

Maximum Bill SQ from list. This is derived from CI_BSEG_READ.

SQ_DT (1:13)

D

Date (for label of the SQ). This is derived from CI_BSEG.

BILL_SQ (1:13)

S12.6 (1:13)

13 occurrences of QTY, one for each period ending on the SQ_DT. This is derived from CI_BSEG_READ.

Adjustment Record (3400)

Field Name

Format

Source/Value/Description

ADJ_DT

D

CI_FT

FT_TYPE_FLG

A2

CI_FT

CUR_AMT

S13.2

CI_FT

TOT_AMT

S13.2

CI_FT

ADJ_TYPE_CD

A8

CI_ADJ

ADJ_TYPE_DESCR

A30

CI_ADJ_TYPE

DESCR_ON_BILL

A80

CI_ADJ_TYPE

CAN_RSN_CD

A4

CI_ADJ

CAN_RSN_DESCR

A30

CI_ADJ_CAN_RSN

End Service Agreement Record (3600)

Field Name

Format

Source/Value/Description

Dummy field

End Premise Record (3700)

Field Name

Format

Source/Value/Description

Dummy field

Message Record (3900)

Field Name

Format

Source/Value/Description

BILL_MSG_CD

A4

CI_BILL_MSGS

MSG_PRIORITY_FLG

A2

CI_BILL_MSG

INSERT_CD

A8

CI_BILL_MSG

MSG_ON_BILL

A254

CI_BILL_MSG

End Bill Record (9999)

Field Name

Format

Source/Value/Description

Dummy field

Address Sub-record

The address sub-record that appears in both the bill record (0100) and the premise record (0900) is composed of the following:

Field Name

Format

Description

COUNTRY

A3

ADDRESS1

A64

Refer to The Source Of Bill Routing Information for a description of conditions when this field will contain a fax number or an Email address rather than the first line of a postal address (this only occurs for a bill record (0100)).

ADDRESS2

A64

ADDRESS3

A64

ADDRESS4

A64

CITY

A30

NUM1

A6

NUM2

A4

HOUSE_TYPE

A2

COUNTY

A30

STATE

A6

POSTAL

A12

GEO_CODE

A11

IN_CITY_LIMIT

A1

XML Bill Extracts

The system includes a sample bill extract algorithm that produces an XML document to interface to Documaker. This is an alternative to the fixed flat file format described above. For additional details, see the algorithm type Create XML bill extract records for Documaker (C1-BLEX-XML).

Algorithms of this type construct the XML file records that contain the information that appears on a printed bill. Each record in the extract is constructed using an extendable data area and may be extended by an implementation using the Post Processing Script parameter. The following steps should be followed to include additional elements in the extract:

- Create a data area that includes the additional elements for the record you wish to extend. This data area must reference the base product data area used in the extract. For example, to extend the bill record, create a data area that references data area C1-BillPrintBillRecord as its extended data area. See the C1-BLEX-XML algorithm type for a complete list of the data areas available.

- Create a service script to retrieve the additional elements. This service script must be defined as the Post Processing Script on your algorithm and its schema must include the main bill extract data area (C1-BillPrintRecord).

For an example of how to extend the XML bill extract to include additional elements, see the CI_BillPrintXMLExtract export bundle included in the demo data.

Sequential Bill Numbers

Every bill is uniquely identified by its bill ID. Bill ID is a random, system-assigned number. In some locales, bills have an additional identifier known as a "sequential bill number". Sequential bill numbers are system-assigned, sequential numbers. For example, the first bill produced by the system is assigned a sequential bill number of 1 , the next bill is assigned a value of 2 , etc. An additional requirement is that no gaps may exist between the sequential bill numbers.

The topics in this section describe how sequential bill numbers are implemented in the system.

Contents

Sequential Numbers Are Only Assigned If The Installation Option Is Turned On

Pending Bills Do Not Have A Sequential Bill Number

When / How Is The Sequential Bill Number Assigned

Additional Functionality for Sequential Bill Numbering

Sequential Numbers Are Only Assigned If The Installation Option Is Turned On

Sequential bill numbers will only be assigned if you have selected Sequential Bill Numbers as the Alternative Bill ID Option on the Installation record.

Pending Bills Do Not Have A Sequential Bill Number

Bills are assigned a sequential bill number after they are completed . This means that pending bills will not have a sequential bill number. This is intentional as pending bills can be deleted and if a deleted bill had a sequential bill number, gaps would result. Refer to Bill Lifecycle for more information about a bill's state transition lifecycle.

When / How Is The Sequential Bill Number Assigned

Warning:

This section is a technical explanation of how sequential bill numbers are assigned. It contains background information for those who wish to understand the rationale of the design.

The batch billing process (known by the batch control ID of BILLING ) takes advantage of parallel processing to allow multiple bills to be produced concurrently. In addition, we allow groups of bills to be committed in "chunks" (based on the commit frequency assigned to the billing background process). These two facts make it impossible to allocate sequential bill numbers during batch billing (because back outs could result in gaps and parallel processing could result in duplicates). This is why sequential bill numbers are allocated as follows:

- A sequential bill number is allocated when a bill is completed online (by clicking the Complete button on Bill - Main).

- If you submit the batch billing process with the following parameters, sequential bill numbers will be allocated when bills are completed:

- Batch thread number must equal 1.

- Batch thread count must equal 1.

- Override maximum records between commits must equal 1.
The above parameters mean that bills are not being produced in parallel and they are not being committed in "chunks". This allows the system to allocate sequential bill numbers when the bills are completed.

- If you do not run batch billing single-threaded, you must schedule the Assign Sequential Bill Numbers background process (known by the batch control ID of ASSGNSBN ) to run immediately after batch billing. This single-threaded process assigns sequential bill numbers to completed bills.

- The following measures are in place as a fail-safe:

- If the billing download process (known by the batch control ID of POSTROUT ) encounters a bill without a sequential bill number, it will abort with an appropriate error message.

- Users are not allowed to delete a completed bill with a sequential bill number. Note, deletion of completed bills is typically prohibited due to the presence of frozen bill segments. However, it's possible to create a bill without frozen bill segments and additional logic exist to inhibit the deletion of such bills if they have sequential bill numbers.

Additional Functionality for Sequential Bill Numbering

The following points describe additional features that are enabled when the Installation record indicates sequential bill numbers are used:

- The bill's number appears in "bill info". "Bill info" is the concatenated string of information that summarizes a bill on many pages in the system.

- The Bill Search page includes an additional search option to search by bill number.

- The match type algorithm that allows payments to be matched to a given bill id will try to match the payment to a bill with a matching sequential bill number.

Document Numbers

Every bill is uniquely identified by its bill ID. Bill ID is a random, system-assigned number. In some locales utilities may be required to assign and print an additional document number. For example, in Argentina a utility must obtain authorization from the national tax agency before they are allowed to print bills at a local office. Once authorized, the utility is assigned a printing authorization code valid for a period. The printing authorization code and expiration, as well as an official document number are printed on the bill at the location where the bill is issued.

The topics in this section describe how document numbers are implemented in the system.

Contents

Document Numbers Are Only Assigned If the Installation Option Is Turned On

Pending Bills Do Not Have a Document Number

When/How Is the Document Number Assigned

Additional Functionality Exists When Document Numbers Are Used

Document Numbers Are Only Assigned If the Installation Option Is Turned On

Document numbers will only be assigned if you have selected Document Numbers as the Alternative Bill ID Option on the Installation record. In addition, the Document Number and Document Number Details algorithms must be enabled on the Installation record. These algorithms contain the logic used by the system to assign a document number to a bill.

The logic used to assign a document number can be quite complex. For example, the document number may depend on the issuing center, the bill’s document type (credit memo, invoice or debit memo), the account’s VAT category and the CIS division. Depending on your implementations complexity, you may choose one of the following possible configurations for document numbers:

- Populate the Document Number, Document Number Details and Document Sequence Number algorithms on the Installation record. The system will behave as follows:

- During online bill completion, a document type is derived and captured on the bill along with other required bill characteristics and a document number is assigned

- During batch billing, a document type is derived and captured on the bill along with other required bill characteristics. Assigning a document number is deferred to the Assign Bill Document Numbers background process. The idea here is that all complex logic is executed during the multi-threaded batch billing process leaving the minimal amount of work for the single-threaded batch process that assigns the document number.

- Populate the Document Number and Document Number Details algorithms on the Installation record. Here, the system assigns a document number during online bill completion, but skips the assignment of document type and number during batch billing. The Assign Bill Document Numbers background process is responsible for deriving the bill’s characteristics (document type, document classification, etc.) and assigning a document number.

Pending Bills Do Not Have a Document Number

Similar to sequential bill numbers, bills are assigned a document number after they are completed . This means that pending bills will not have a document number. Refer to Bill Lifecycle for more information about a bill's state transition lifecycle.

When/How Is the Document Number Assigned

Warning:

This section is a technical explanation of how document numbers are assigned. It contains background information for those who wish to understand the rationale of the design.

- An installation algorithm assigns a document number to a bill.

Similar to sequential bill numbers, document numbers are allocated as follows:

- A document number is allocated when a bill is completed online (by clicking the Complete button on Bill - Main).

- The Assign Bill Document Numbers background process (known by the batch control ID of C1-BNBAS ) should be scheduled to run immediately after batch billing. This single-threaded process assigns document numbers to completed bills.

- The logic used to assign a document number resides in the installation options Document Number algorithm

- The following measures are in place as a fail-safe:

- If the billing download process (known by the batch control ID of POSTROUT ) encounters a bill without a document number, it will abort with an appropriate error message.

- Users are not allowed to delete a completed bill with a document number. Note, deletion of completed bills is typically prohibited due to the presence of frozen bill segments. However, it's possible to create a bill without frozen bill segments and additional logic exist to inhibit the deletion of such bills if they have sequential bill numbers.

Additional Functionality Exists When Document Numbers Are Used

The following points describe additional features that are enabled when the Installation record indicates that document numbers are used:

- The Bill Search page includes an additional search option to search by Document Number and Document Type.

- The bill's document number and type appear in "bill info". "Bill info" is the concatenated string of information that summarizes a bill on many pages in the system.

- The match type algorithm that allows payments to be matched to a given bill id will try to match the payment to a bill with a matching document number and type.

Digital Signatures

In some locales, billing software is required to generate and store digital signatures for each bill. Digital signatures are used to secure bills that are stored in the database, and the digital key for the bill will be known only to the vendor.

CCB supports digital signatures with the following features:

- An Encryption feature configuration must be configured with an algorithm info option for the key alias and signing algorithm

- The installation algorithm, C1-BILLSIG, generates the digital signature for a bill and captures this on the bill itself. The algorithm also stores an alias of the private/public key pair on the Bill as a characteristic. See the installation algorithm for a description of how the signature is generated.

- Bills are assigned a digital signature when they are completed.

- The Assign Bill Document Numbers background process (known by the batch control ID of C1-BNBAS) is responsible for generating digital signatures for a batch of bills. This batch job should be scheduled to run immediately after batch billing. See the description of the batch control and parameter settings for generating digital signatures.

- A digital signature is also generated when a bill is completed online (by clicking the Complete button)

Note: The digital signatures features are only appropriate for customers who use document number in generating bill signatures.

For an example of the objects and instructions used for implementing this feature, see the CI_BilllDocNumber & DigitalSignature export bundle included in the demo data.

For details about setting up the required keystore for this feature, see the Installation Guide .

Writing Off Bills

If your organization practices open-item accounting and your credit and collections rules revolve around collecting on unpaid bills, you can set up the system to automatically write-off bills.

If you've enabled this functionality, Bill - Main will contain a button that a user can click to manually write off a bill. A corresponding button exists that a user can click to reverse a written-off bill.

Fastpath:

Refer to Writing Off Bills for a description of how to set up the system to allow both automated and manual bill write off.

Idiosyncratic Manual Bill Cancellation

If a bill's account is associated with a Customer Class 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 customer's financial obligations to the customer. The topics in this section describe how to maintain bills.

Note:

The system creates most bills behind-the-scenes. Most bills are created by the system when it processes the bill cycle schedule. You should only have to access the bill pages to correct a bill or to add a bill real-time. For information about how the system creates bills, refer to The Big Picture of Billing.

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., service agreement, rate, meter read) 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.

Contents

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.

Warning:

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 service agreements 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 customer. 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 service agreements' SA types are executed. The system executes these algorithms first in the order of the billing processing sequence on each service agreement's SA type then in the order of the algorithm's sequence. These are not executed for the completion of credit notes.

- Pre-completion algorithms associated with the account's customer class 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 customer class. 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 customer class.

- 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. Refer to Preventing SA Balances And The GL From Being Impacted Until Bill Completion for more information.

- If a final bill segment of a deposit service agreement is detected, the deposit is refunded to the customer using the refund method algorithm plugged-in on the deposit SA's deposit class. Refer to Deposit Refund for more information. This step is skipped during the completion of credit notes, or if the bill is linked to an off cycle bill generator.

- Post completion algorithms associated with the account's service agreements' SA types are executed. The system executes these algorithms first in the order of the billing processing sequence on each service agreement's SA type then in the order of the algorithm's sequence.

- Bill completion algorithms associated with the account's customer class 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 customers adjustments and corrections are linked

- For correction notes or credit notes, the bill cancellation financial transactions are linked

- For off cycle bill generator bills:

- Adjustments linked to the off cycle bill generator are linked to the bill

- If the off cycle bill generator is linked to a service agreement, then all financial transactions associated with the SA are linked to the bill

- For all other situations, payments, adjustments and corrections are linked assuming the adjustments are not linked to an off cycle bill generator

- 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 pays automatically and the installation's Autopay Creation Option is to Create At Bill Completion , an automatic payment is created. Refer to APAYCREATE for more information about the auto pay creation algorithm. This step is skipped during the completion of credit notes.

- If the account's customer class indicates the account is an open-item customer, 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. This step is skipped during the completion of credit notes.

- If the account pays automatically and the installation's Autopay Creation Option is to Create On Extract Date , the bill is stamped with the date when the automatic payment is to be created. Refer to The System Background Processes for more information about APAYCRET , the background process that creates the automatic payment and APAYDSFR , the background process that distributes and freezes the automatic payment. This step is skipped during the completion of credit notes.

- The bill's late payment date is calculated. This is equal to the due date plus the grace days defined on the account's customer class. If the resultant date is not a workday, the LPC date is set to the next workday. This step is skipped during the completion of credit notes.

- The account is marked for review by the account debt monitor on its due date plus a grace period defined on its customer class. This step is skipped during the completion of credit notes.

- If the account's customer class indicates the account is an open-item customer, 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. This step is skipped during the completion of credit notes.

- The bill's status becomes Complete .

- Post bill completion algorithms associated with the account's customer class 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 (except if this bill is linked to an off cycle bill generator) because recompleting the bill causes the ending-balance to change, and we don't want this to happen to historical bills.

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.

Certain bill completion algorithms prevent reopening. If a bill contains a service agreement whose SA type has a "transfer accounts receivable to service provider" algorithm, the system will not allow the bill to be reopened. Refer to If You Deal With TBFU Service Providers You Can't Reopen Bills for more information about this bill completion algorithm.

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 Financial, Bill, Main to maintain core bill information.

The following discussion 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.). If sequential bill numbering has been enabled, the bill's number also appears. If document numbering has been enabled, the assigned document number and document type will also appear. If this bill is a correction note or credit note, a message will appear indicating this along with the ID of the original bill. If the batch billing background process generates the bill, the bill information includes the bill cycle and window start date. Bills generated manually, i.e., off-schedule, do not have this information.

Bill ID is the system-assigned unique identifier of the bill.

Account ID identifies the customer who is responsible for the bill. The name of the main customer on the account appears adjacent.

If this bill is a credit note or correction note, a message appears adjacent to the account information indicating that this bill is a credit note or correction note for another bill; this hyperlink will drill you to the original bill. If a credit note or correction note has been issued for one or more of this bill's bill segments, a message appears indicating such. 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.

If the bill is associated with an off cycle bill generator, a message appears adjacent to the bill status indicating this and the hyperlink will take the user to the related off cycle bill generator.

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. The system comes with configurations to display bill images using BI Publisher and Documaker, but can work with other applications.

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 customer class 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 customer class has an override due date calculation algorithm, the due date may be overridden. Refer to Setting Up Customer Classes for more information.

Note:

Late payment charges. Late payment charges are calculated on the due date plus the grace period. Refer to Defining Late Payment Charge Options for more information.

Bill Date is the business date that was used when the bill was completed. For example, if batch billing starts on 11:55 pm on 1-Jan-2000 and a bill is produced at 1:00 am on 2-Jan-2000, this bill's bill date would be 1-Jan-2000.

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 customer 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 Autopay, that, when clicked, causes the associated automatic payment to stop. You might click this button if the customer indicates that they will send in a payment. After you click the Stop Autopay 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).

The Late Payment Charge Details section contains information about how the system determines when and whether to levy late payment charges:

- Eligible for Late Payment Charge can be checked if a charge should be levied for late payment. This field is defaulted based on the customer's customer class. If you want to excuse a bill from late payment charge processing uncheck this box.

- Late Payment Charge Date is the date on which the system will levy a late payment charge if payment is not received. This date is calculated when the bill is completed. It is equal to the bill's due date plus the account's customer class's grace days. If this date does not fall on a workday, the date is set to the next available workday when the bill is completed. If you want to manually delay the onset of late payment charge processing, extend this date into the future.

Fastpath:

Late payment charges. Late payment charges are calculated on the due date plus the grace period. Refer to How Late Payment Charges Get Calculated for more information.

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 customer, 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 customer), 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 customer as of the end of the bill period.

If the account is an open-item customer, 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 customer, 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 in the grid:

- The Bill Segment column contains a concatenation of each bill segment's division, SA type, status and bill period. The division and SA type come from the bill segment's service agreement.

- The Current Amount column contains the bill segment's effect on the service agreement'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 customer. The financial impact of this bill segment appears as a "bill correction" on the next bill produced for the customer.

- Rebill prior completion appears if the bill segment is a rebill that was created before the bill was sent to the customer.

- Canceled after completion appears if the bill segment was canceled after the bill was sent to the customer. The financial impact of this bill segment appears as a "bill correction" on the next bill produced for the customer.

- Canceled prior completion appears if the bill segment was canceled before the bill was sent to the customer.

- If the bill segment's status is Error or Incomplete , this column contains an estimated value of this bill segment. The estimated value is calculated by computing an average daily amount from the service agreement's frozen bill segments in the last 365 days. This average is then applied to the number of days in this bill segment's bill period. If the bill segment doesn't have a bill period (rare, but possible), the historical average is not displayed.

- If the bill segment's status is Error , this column also contains the error message.

- Rebilled due to correction appears if a correction note was generated for the bill segment. This remark appears only if you have the Correction Note Billing Option specified in the Installation record.

- Rebilled due to correction. Canceled after completion appears for a correction note that spawns another correction note. This remark appears only if you have the Correction Note Billing Option specified in the Installation record.

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 in the grid:

- 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. If the status is Error or Incomplete , this column contains an estimated value of these bill segments. The estimated value is calculated by computing an average daily amount from frozen bill segments in the last 365 days for each service agreement. This average is then applied to the number of days in each bill segment's bill period. Please note, an historical average cannot be computed if an Error or Incomplete bill segment does not have a bill period (rare, but possible).

- 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.

Contents

Generate

Freeze

Cancel Frozen

Freeze / Complete

Complete

Delete

Reopen

Credit Note

Correction Note

Write Off

Reverse Write Off

Cancel Bill

Generate

The Generate button causes a bill segment to be created for each service agreement linked to the account. The system generates bill segments in the order of the billing processing sequence on each service agreement's SA 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:

- Cutoff Date is the last possible day of each bill segments 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 defines the financial period to which the new bill segments' financial transactions are booked. The current date defaults when the window opens.

- Check Allow Estimates if the system is allowed to estimate consumption if it can't find a meter read.

- If the service agreements use meter reads, use the Billing Option to control how the system retrieves meter reads that appear on the bill. Choose Use Cut off Date if the meter reads must exist on the Cutoff Date (defined above). Choose Use Schedule if you want the service agreement's service point(s) service cycle schedule to control the meter reads that are used (the schedule effective on the cutoff date is used to select the meter reads).

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 customer 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.

When clicked, the Cancel Frozen Bill Segments window opens.

In the Cancel Frozen Bill Segments window, you must specify the following parameters 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 customer (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 customer. 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 customer 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 customer

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.

When clicked, the Complete window opens.

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 customer. 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 .

When clicked, the Complete window opens.

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. If completing a correction note, the user is prompted to enter a Correction Note Date instead of a bill date in the Complete window.

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

- the bill is not linked to an off cycle bill generator 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.

Credit Note

The Credit Note button is used to cancel ALL bill segments and create a new bill that contains the cancellation details. We refer to this "negative bill" as a credit note. Refer to Credit Notes - Presenting Cancellation Details on a Separate Bill for more information.

This button is enabled if:

- the Use Credit Notes option on the Installation record is turned on AND

- the bill is complete AND

- the bill is not written off.

When clicked, the Credit Note window opens.

You must specify the following parameters in the Credit Note window 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.

- Credit Note Date defines the date of the credit note on which the cancellation details appear. The current date defaults when the window opens.

After specifying the parameters, click Calculate to cancel the frozen bill segments and create a credit note.

It should be noted that if this operation is successful, the new "negative bill" is complete . It is ready for transmission to the customer and for interface to the general ledger.

Note:

If you want to issue a credit note for a specific bill segment. Rather than cancel all bill segments on a bill, you can create a credit note for a specific bill segment on a bill. To do this, drill down on the bill segment in question and then click the Credit Note button on the bill segment page. You can also issue a credit note for selected bill segments on the next tab by selecting the desired bill segments and clicking the Credit Note button.

Correction Note

The Correction Note button is used to cancel and rebill ALL bill segments and create a new bill that contains the cancellation and rebill details. We refer to the resultant bill as a correction note. Refer to Correction Notes - Presenting Correction Notes on a Separate Bill for more information.

This button is enabled if:

- the Correction Note Billing Option is specified on the Installation record AND

- the bill is complete AND

- there is at least one frozen bill segment on the bill or all of the bill's bill segments are frozen or cancelled AND

- there are no bill segment financial transactions that have been transferred out of the system.

When clicked, the Correction Note window opens.

You must specify the following parameters in the Correction Note window to correct the bill segment:

- Cancel Reason defines why you are performing the correction.

- Cutoff Date is the last possible day of each bill period for a bill segment. 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 defines the financial period that the financial transactions are booked for a bill segment. The current date defaults when the window opens.

- Check Allow Estimates if the system is allowed to estimate consumption if it can't find a meter read.

- Use the Billing Option to define how the system looks for meter reads:

- Select UseSchedule if the system should select reads based on the SA's SP service cycle schedule. Refer to How The System Determines How Much Was Consumed for more information.

- Select Use Cut off Date if the system should only select reads from the end date of the existing bill segment.

- If you prefer to have the system use the consumption details used on the original bill segments, check Use Old Read/Item/SQ. If this switch is on, neither Allow Estimates nor Billing Option is relevant.

- After specifying the parameters, click Calculate to correct the bill segments and create a correction note. The Bill Page opens and displays the Correction Note.

Once you complete a correction note, it cannot be reopened.

After you create a correction note, the Undo Correction Note button is activated.

The button is enabled if:

- the Correction Note Billing Option is specified on the Installation record AND

- the bill is a correction note AND

- the bill is not linked to an off cycle bill generator AND

- all of the bill segments for the correction note are freezable.

Note:

If you want to issue a correction note for a specific bill segment. You can create a correction note for a specific bill segment on a bill. To do this, drill down on the bill segment in question and then click the Correction Note button on the bill segment page. You can also issue a correction note for selected bill segments by selecting the desired bill segments and clicking the Correction Note button.

Write Off

Refer to Writing Off Bills for a description of when the Write Off button appears and what happens if the button is clicked.

Reverse Write Off

Refer to Writing Off Bills for a description of when the Reverse Write Off button appears and what happens if the button is clicked.

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. Note that if the bill is linked to an off cycle bill generator, this button is not enabled.

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 Financial, Bill, Bill Segments to view this information.

Note:

If the bill has more than 25 bill segments and you don't use the go to buttons 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 SA 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 section below 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 SA 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 SA Filter to define the types of service agreements whose bill segments appear in the grid. The following options are available:

- Address. Use this option to restrict bill segments to those whose service agreements are linked to service points associated with a given Address, City and/or Postal code. Note, you can specify any combination of these fields.

- All. Use this option if you do not wish to restrict bill segments based on service agreement attributes.

- Geographic Type. Use this option to restrict bill segments to those whose service agreements are linked to service points associated with a given Geo Type and Value.

- SA Type. Use this option to restrict bill segments to those whose service agreements are linked to a given CIS Division and SA 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, SA type, status and bill period. The division and SA type come from the bill segment's service agreement. 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 service agreement'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 customer. The financial impact of this bill segment appears as a "bill correction" on the next bill produced for the customer.

- Rebill prior completion appears if the bill segment is a rebill that was created before the bill was sent to the customer.

- Canceled after completion appears if the bill segment was canceled after the bill was sent to the customer. The financial impact of this bill segment appears as a "bill correction" on the next bill produced for the customer.

- Canceled prior completion appears if the bill segment was canceled before the bill was sent to the customer.

- If the bill segment's status is Error or Incomplete , this column contains an estimated value of this bill segment. The estimated value is calculated by computing an average daily amount from the service agreement's frozen bill segments in the last 365 days. This average is then applied to the number of days in this bill segment's bill period. If the bill segment doesn't have a bill period (rare, but possible), the historical average is not displayed.

- If the bill segment's status is Error , this column also contains the error message.

- Rebilled due to correction note appears if the correction note was generated for the bill segment. This remark is generated only if you have Correction Note specified in the Installation record.

- Rebilled due to correction. Canceled after completionappears for a correction note that spawns another correction note. This remark is generated only if you have Correction Note specified in the Installation record.

- The Service Quantity and UOM (unit of measure) columns contain the amount of consumption that was billed. The UOM is defined on the service agreement's SA type.

- 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:

Contents

Generate (Bill - Bill Segments)

Freeze (Bill - Bill Segments)

Delete (Bill - Bill Segments)

Cancel/Rebill/Freeze (Bill - Bill Segments)

Cancel (Bill - Bill Segments)

Credit Note (Bill - Bill Segments)

Correction Note (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.

When clicked, the Generate window opens.

You must specify the following parameters in the Generate window 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.

- Check Allow Estimates if the system is allowed to estimate consumption if it can't find a meter read.

- If the service agreements use meter reads, use the Billing Option to control how the system retrieves meter reads that appear on the bill. Choose Use Cut off Date if the meter reads must exist on the Cutoff Date (defined above). Choose Use Schedule if you want the service agreement's service point(s) service cycle schedule to control the meter reads that are used (the schedule effective on the cutoff date is used to select the meter reads).

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.

When clicked, the Freeze window opens.

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. The following table describes common problems and how to fix them.

Problem

How To Fix It

The wrong rate was used

Go to Service Agreement - Rate Info and correct the rate.

The wrong meter read was used

Add a meter read with a more powerful read type for the service point in question.

The wrong meter was connected to the service point

Go to SP / Meter Installation and correct the SP / Meter linkage. Then go to Service Agreement - SA / SP and indicate the appropriate start read for the service point's correct meter.

A contract rider was applied incorrectly

Go to Service Agreement - Rate Info and correct the contract rider information.

The wrong tax exemption amount was calculated

Go to Service Agreement - Rate Info and correct the tax exemption information.

Note:

Multi-Cancel/Rebill Saves Time. If the cause of the problem impacts many bill segments related to a service agreement, you should use the Multi Cancel Rebill transaction as it allows you to cancel / rebill an unlimited number of bill segments at once.

Credit Notes. Using the cancel/rebill functionality causes the cancel and rebill details to be swept on to the customer's next bill unless you Reopen the bill. If your organization requires cancellation details to be presented to the customer separately from the new bill, you should not use the Rebill functionality. Rather, you should issue a Credit Note and then generate a new bill containing the revised charges.

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.

When clicked, the Cancel/Rebill/Freeze window opens.

- 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.

- Check Allow Estimates if the system is allowed to estimate consumption if it can't find a meter read.

- Use the Billing Option to define how the system looks for meter reads:

- Select UseSchedule if the system should select reads based on the SA's SP service cycle schedule. Refer to How The System Determines How Much Was Consumed for more information.

- Select Use Cut off Date if the system should only select reads from the end date of the existing bill segment.

- If you prefer to have the system use the consumption details used on the original bill segments, check Use Old Read/Item/SQ. If this switch is on, neither Allow Estimates nor Billing Option is relevant.

Warning:

If the cause of the rebill is an incorrect rate and the new rate requires service quantities that were not calculated when the bill was originally calculated, do not turn on Use Old Read/Item/SQ. Why? Because you want the system to derive new service 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 SA's rate to a rate that requires a unit-of-measure that doesn't exist on the SA's meter, 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.

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 customer.

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.

When clicked, the Cancel window opens.

- 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.

Credit Note (Bill - Bill Segments)

The Credit Note button is used to cancel selected bill segments and create a new bill that contains the cancellation details. We refer to this "negative bill" as a credit note. Refer to Credit Notes - Presenting Cancellation Details on a Separate Bill for more information.

This button is enabled if:

- the Use Credit Notes option on the Installation record is turned on AND

- 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 this action 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.

When clicked, the Credit Note window opens.

You must specify the following parameters in the Credit Note window 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.

- Credit Note Date defines the date of the credit note on which the cancellation details appear. The current date defaults when the window opens.

After specifying the parameters, click Calculate to cancel the frozen bill segments and create a credit note.

It should be noted that if this operation is successful, the new "negative bill" is complete . Refer to Bill Lifecycle for information about the steps that take place during completion. It is ready for transmission to the customer and for interface to the general ledger.

Note:

If you want to issue a credit note for an entire bill. Rather than cancel a specific bill segment, functionality exists that allows you to create a credit note for ALL bill segments on a bill. To use this feature, display the bill in question and then click the Credit Note button on the bill page.

Correction Note (Bill - Bill Segments)

The Correction Note button is used to cancel and rebill bill segments and create a new bill that contains the cancellation and rebill details. We refer to the resultant bill as a correction note. Refer to Correction Notes - Presenting Correction Notes on a Separate Bill for more information. This button is enabled if:

- the Correction Note option is specified on the Installation record AND

- the bill is complete AND

- the bill segment is frozen AND

- there are no bill segment financial transactions that have been transferred out of the system.

When clicked, the Correction Note window opens.

You must specify the following parameters in the Correction Note window to correct the bill segment:

- Cancel Reason defines why you are performing the correction.

- Cutoff Date is the last possible day of each bill segments 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 defines the financial period to which the corrected bill segments' financial transactions are booked. The current date defaults when the window opens.

- Check Allow Estimates if the system is allowed to estimate consumption if it can't find a meter read.

- Use the Billing Option to define how the system looks for meter reads:

- Select Use Schedule if the system should select reads based on the SA's SP service cycle schedule. Refer to How The System Determines How Much Was Consumed for more information.

- Select Use Cut off Date if the system should only select reads from the end date of the existing bill segment.

- If you prefer to have the system use the consumption details used on the original bill segments, check Use Old Read/Item/SQ. If this switch is on, neither Allow Estimates nor Billing Option is relevant.

- After specifying the parameters, click Calculate to correct the bill segments and create a correction note. The Bill Page opens and displays the Correction Note.

Note:

If you want to issue a correction note for an entire bill. You can create a correction note for ALL bill segments on a bill. To use this feature, display the bill in question on the Bill page and click the Correction Note button.

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 Financial, Bill, Bill Routings 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). If sequential bill numbering has been enabled, the bill's number also appears.

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 customer. 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 customer 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 customer 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 customer. 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.

- The Validate button on the bill page will only be available if you have set the Allow Address Validation option type to Y on the General System Configuration feature configuration. Once clicked, the Address Validation Script on the General System Configuration feature configuration will be invoked to validate the entered address. Refer to unresolvable-reference.html for more information.

Bill - Bill Messages

The Messages page is a grid containing one row for every message that appears on the bill. Open Financial, Bill, Bill Messages 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.

The bill segment(s) may also have messages. Be aware that only account-oriented messages are linked to a bill. There may also be service agreement-oriented messages linked to the bill's bill segments. Refer to Bill - Bill Messages for information about the page on which service agreement-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.

Bill messages may contain dynamic information. Refer to Substituting Field Values Into A Bill Message for more information.

The Description of Page section below 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). If sequential bill numbering has been enabled, the bill's number also appears.

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.

- Sequence Controls the order in which characteristics of the same type are displayed.

- 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.

Contents

How To Create A Bill For All Service Agreements Linked To An Account

How To Create A Bill For A Specific Service Agreement

How To Create a Bill with no Bill Segments

How To Create A One-Time Invoice

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 Create A Credit Note

How To Create A Correction Note

How To Create An Off Cycle Bill Generator

How To Override Service Quantities On A Specific Bill Segment

How To Override The Items Billed On A Specific 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 Service Agreements 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 customer. 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 you have already selected the customer (say on Control Central), 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, use the main menu to navigate to this page (Main Menu, Financial, 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 Service Agreement

Most bills contain a bill segment for every service agreement linked to the account. If you want to produce a bill that contains bill segments for a subset of service agreements (e.g., you want to create a one-time invoice for an account's billable charge service agreement), follow these steps:

- Navigate to the Bill - Main Information page:

- If you have already selected the customer (say on Control Central), 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, use the main menu to navigate to this page (Main Menu, Financial, 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 SA ID of the service agreement 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 customer 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 you have already selected the customer (say on Control Central), 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, use the main menu to navigate to this page (Main Menu, Financial, 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 A One-Time Invoice

The following points describe the steps necessary to create and bill a one-time invoice:

- If the customer to be invoiced doesn't already have an appropriate billable charge service agreement, create one. The easiest way to do this is from Start/Stop Service.

- Use Maintaining Billable Charges to add a billable charge for the service agreement. The billable charge contains the invoice lines and amounts. The system will produce the bill for this charge when the account's bill cycle next executes. If you can't wait until that time, proceed to the next step.

- If you created a new billable charge service agreement in step 1, you must activate it before billing can bill it. To do this, transfer to Service Agreement - Main Information and click the activate button.

- Refer to How To Create A Bill For A Specific Service Agreement for instructions describing how to create a bill with a bill segment for the billable charge service agreement.

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 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 customer. 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 (e.g., you need to look at the meter reads and service quantities).

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 customer (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 customer. 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 customer 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. The following table describes common problems and where to go to fix them.

Problem

How To Fix It

The wrong rate was used

Go to Service Agreement - Rate Info and correct the rate.

The wrong meter read was used

Add a meter read with a more powerful read type for the service point in question.

The wrong meter was connected to the service point

Go to SP / Meter Installation and correct the SP / Meter linkage. Then go to Service Agreement - SA / SP and indicate the appropriate start read for the service point's correct meter.

A contract rider was applied incorrectly

Go to Service Agreement - Rate Info and correct the contract rider information.

The wrong tax exemption amount was calculated

Go to Service Agreement - Rate Info and correct the tax exemption information.

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 a service agreement, 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 customer (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 customer. 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 customer because its cancellation appears on the same bill as the original charges).

How To Create A Credit Note

A credit note is used to cancel bills segments and present the results of this cancellation on a separate bill. This separate bill is referred to as a credit note. Refer to Credit Notes - Presenting Cancellation Details on a Separate Bill for more information.

Note:

Installation option must be turned on. If your organization creates credit notes, be sure to select the Credit Note Billing Option on the Installation Options. If you don't select this option, the credit note buttons will not be enabled.

Before creating a credit note, you must first determine whether a single bill segment must be canceled or whether all bill segments for a bill must be canceled:

- If you need to issue a credit note for the entire bill, navigate to the Bill page and click the Credit Note button.

- If you need to issue a credit note for a specific bill segment, navigate to the Bill Segment page and click the Credit Note button.

Note:

Open-item customers. If any of the bill segments are associated with an open-item customer class AND the original bill segment is an open item, the match event will be created and balanced with the original FT and the cancellation FT, assuming you have the appropriate FT freeze algorithm plugged-in on the customer class.

Issuing a credit note for a specific bill segment. You may also issue a credit note for an individual bill segment. When you create a credit note for an individual bill segment, that bill segment is canceled and a new credit note bill is created for that single bill segment's cancellation information.

How To Create A Correction Note

The Correction Note button is used to cancel and rebill bill segments and present the cancellation and rebill details on a separate bill. Refer to Correction Notes - Presenting Correction Notes on a Separate Bill for more information.

Note:

Installation option must be turned on. If your organization creates correction notes, be sure to select the Correction Note Billing Option on the Installation Options. If you don't select this option, the correction note buttons will not be enabled.

Before creating a correction note, you must first determine whether the note should impact a single bill segment or whether all bill segments for a bill must be corrected:

- If you need to issue a correction note for the entire bill, navigate to the Bill page and click the Correction Note button.

- If you need to issue a correction note for a specific bill segment, navigate to the Bill Segment page and click the Correction Note button.

Note:

Open-item customers. If any of the bill segments are associated with an open-item customer class AND the original bill segment is an open item, the match event will be created and balanced with the original FT and the cancellation FT, assuming you have the appropriate FT freeze algorithm plugged in on the customer class.

Issuing a correction note for a specific bill segment. You can also issue a correction note for an individual bill segment. When you create a correction note for an individual bill segment, that bill segment is canceled and a new correction note bill is created for that single bill segment's cancellation information.

How To Create An Off Cycle Bill Generator

An off cycle bill generator is used to create an off cycle bill for an account. You control the financial transactions that are linked to the bill. To create a bill using the base off cycle bill generator business object, follow these steps:

- With an account in context, select Go To Off Cycle Bill Generator + on the account context menu. This will transfer you to this portal with the respective account populated.

- Select the adjustments, billable charges and/or service agreements that you wish to include in the bill.

- Enter the required bill information to be used when creating the bill; this includes the Cutoff Date, Accounting Date, Allow Estimates switch, Billing Option and Bill Date.

- Click the save button.

- Click the Complete button to transition the off cycle bill generator to the complete state and create the bill. Any errors encountered while attempting to create the bill will be captured in the off cycle bill generator's log.

- Refer to Off Cycle Bill Generator for more information.

How To Override Service Quantities On A Specific Bill Segment

The calculation of the amount of the commodity used by the customer is one of the first steps that happens when a bill segment is created. 99.9% of the time, the system does a perfect job in this effort. However, there are rare circumstances when, due to missing or incorrect data, the quantity calculated by the system is not correct (consider what the consumption should be if the meter is broken).

To help you deal with these rare situations, a "back door" exists that allows a bill segment's service quantities to be overridden. This truly is a "back door" because the proper way to fix the amount of a commodity is to correct the cause of the error and then cancel / rebill the bill segment (or issue a credit note).

This section describes how to override the total amount of service quantity consumption billed on a bill segment. You would do this in the rare situation when you cannot get the meter reads (and exchanges) to reflect the amount of consumption you need to bill.

- Display the error or freezable bill segment on Bill Segment - Main.

Important:

You can only override consumption on a bill segment that is in Error or Freezable . This means you must generate a bill segment before you can override the SQ details.

- Transfer to the Bill Segment - SQ Details tab.

- Insert one row in the service quantity (SQ) grid (click the + button) for each service quantity you need to add. You may also change service quantities that were populated by the system when it initially generated the bill segment by overwriting the respective values.

- Save the bill segment.

- Generate the bill segment.

- If the bill segment still looks wrong, repeat the above points until the bill segment is correct.

- 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.

Warning:

Even though the system doesn't use the consumption associated with the bill segment's meter reads when you override consumption, it will use the end reading(s) as the start read(s) on the NEXT bill segment produced for the service agreement. Therefore, make sure the end read(s) are correct, otherwise you'll have to override the service quantities on the next bill segment.

Note:

Override Calculation/Audit Read Details. The above steps may also be taken to override entries in the calculation/audit read details collection.

How To Override The Items Billed On A Specific Bill Segment

The calculation of the amount of the commodity used by the customer is one of the first steps that happens when a bill segment is created. 99.9% of the time, the system does a perfect job in this effort. However, there are rare circumstances when, due to missing or incorrect data, the quantity calculated by the system is not correct.

To help you deal with these rare situations, a "back door" exists that allows a bill segment's billable quantities to be overridden. This truly is a "back door" because the proper way to fix the amount of a commodity is to correct the cause of the error and then cancel / rebill the bill segment.

This section describes how to override the total number of items billed on a bill segment. You would do this in the rare situation when you cannot get the item snapshot to reflect the amount of consumption you need to bill.

- Display the error or freezable bill segment on Bill Segment - Main.

Important:

You can only override consumption on a bill segment that is in Error or Freezable . This means you must generate a bill segment before you can override the item details.

- Transfer to the Bill Segment - Item Details tab.

- Insert one row in the item grid (click the + button) for each item you need to add. You may also change item amounts that were populated by the system when it initially generated the bill.

- Save the bill segment.

- Generate the bill segment.

- If the bill segment still looks wrong, repeat the above points until the bill segment is correct.

- 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 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 (e.g., the system generated a late payment charge but you want to forgive it) 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.

The system can be configured to work with different bill production software, and it comes configured with the ability to display a bill on-line using BI Publisher or Documaker. With Documaker, the bills are presented in PDF format. To view the bills, you must have Adobe® Acrobat® Reader installed.

To view a bill on-line, click the Display Bill button.

Financial Transactions On A Bill

Open Financial Query, Financial Transactions On A 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 SA Filter to define the types of service agreements whose financial transactions appear in the grid. The following options are available:

- Address. Use this option to restrict financial transactions to those whose service agreements are linked to service points associated with a given Address, City and/or Postal code.

- All. Use this option if you do not wish to restrict financial transactions based on service agreement attributes.

- Geographic Type. Use this option to restrict financial transactions to those whose service agreements are linked to service points associated with a given Geo Type and Value.

- SA ID . Use this option to restrict financial transactions to those of a specific service agreement.

- SA Type. Use this option to restrict financial transactions to those whose service agreements are linked to a given CIS Division and SA Type.

- Use 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.

- Use Match Event Status Filter to restrict the financial transactions based on the status of their match event. This filter only appears if the bill's account is an open-item customer. 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.

Warning:

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:

- Match Event Status shows the status of the financial transaction's match event. This column only appears if the bill's account is an open-item customer.

- 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 service agreement's current balance.

- Payoff Amount contains the financial transaction's effect on the service agreement'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 customer's bill.

- SA Information contains a summary of the respective service agreement.

- 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 service agreement linked to its account. A bill segment contains information showing how the segment was calculated and how it should be printed on the customer's bill.

The actions taken to create a bill segment are dependent on the service agreement's SA type. For example, a service agreement that charges for metered service is produced as follows:

- The system calculates the amount of the commodity that was consumed (e.g., the number of lamps, the number of gallons of water, the peak kW, etc.). Refer to How The System Determines How Much Was Consumed for the details.

- The service agreement's rate is applied to the amount consumed to calculate how much the customer owes for the service. A bill segment and a financial transaction are generated to reflect the results of this calculation. Refer to How Rates Affect The Information On Bill Segments for the details. Refer to Effective Dates & Price Proration for information about how the system prorates changes to rates and prices during a bill period.

Note:

SA type controls everything. The above points explain how a bill segment is produced for a metered service agreement. It's important to be aware that the system has other bill segment creation algorithms. For example, if the service agreement charges for a deposit, the system neither amalgamates consumption nor does it apply a rate. You may be wondering how the system knows which method to use? It uses the bill segment type on the service agreement's SA type. Refer to Designing and Defining Bill Segment Types for a description of the various bill segment creation algorithms that are supported in the system.

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., service agreement, rate, meter read) 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 service agreement 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.

Contents

Bill Segment Lifecycle

Bill Segment - Main Information

Bill Segment - Read Details

Bill Segment - Item Details

Bill Segment - SQ Details

Bill Segment - Calc Lines

Bill Segment - Financial Details

Bill Segment - Bill Segment Messages

Bill Segment - Sub Bill Segments

Bill Segment - Usage

Financial - Bill Segment Calculation Line Characteristics

Bill Segment Lifecycle

The following diagram shows the possible lifecycle of a bill segment.

Warning:

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 service agreement's rate) and regenerate the bill segment (by clicking Generate).

Click the delete button to physically remove an Incomplete , Error or Freezable bill segment from the database. Note, batch billing will delete unfrozen bill segments when it attempts to create bill segments for an account that has unfrozen bill segments. Also note, if you've plugged-in the appropriate pre-completion algorithm, the system will delete bill segments in error on the last night of the bill cycle. Refer to DELBSEG for more information.

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 customer'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 service agreement'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 a service agreement (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.

Using the cancel and cancel/rebill functionality will cause the cancel and rebill details to be swept on to the customer's next bill. If your organization requires cancellation details to be presented to the customer separately from the new bill, then you will need to use Credit Notes. Refer to Credit Notes - Presenting Cancellation Details on a Separate Bill for more information.

- 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 below 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 Financial, Bill Segment, Main 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, SA 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 service agreement'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.

SA ID contains information about the bill segment's service agreement. A concatenation of the service agreement's division, SA type, start option (if any), status and start date is displayed.

If the quotation module is not turned off, you can generate simulated bill segments when you create a quote. You can view simulated bill segments by drilling down on the desired bill segment from Quote - Quote Details. When a simulated bill segment is displayed on this page, the Billing Scenario ID that controlled the bill segment's billing period (and consumption) is displayed. Refer to Creating Quotes And Quote Details for more information.

Period is the start and end dates of the bill segment.

Usage Period is the period used by the meter data management system to determine the correct interval data to process for the bill segment. This field appears when the bill segment is for an SA that has Bill Determinants Required for the special role flag.

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.

If the Closing switch is on, this is the final bill segment for the service agreement (i.e., the service agreement has been stopped and this is the final bill segment).

If the Estimate switch is on, consumption on this bill segment has been estimated by the system. Refer to The Theory Behind Consumption Estimation for more information.

If the SQ Override switch is on, a user has overridden the service quantities (i.e., the amount of consumption for which the customer is charged is not consistent with the customer's meter reads). This switch is also set if a user has overridden the calculation/audit read details. Refer to How To Override Service Quantities On A Specific Bill Segment for more information.

If the Item Override switch is on, a user has overridden the type and/or number of items (i.e., the type/number of items for which the customer is charged is not consistent with the customer's service point information). Refer to How To Override The Items Billed On A Specific Bill Segment for more information.

If this bill segment was created for a sub service agreement where we calculate the charges (i.e., not for a "pass through" billing situation):

- SA Rel ID shows the unique identifier of the record that defines the relationship between the sub service agreement and the master service agreement (this record shows the service provider associated with the bill segment). Click the go to button to transfer to this record.

- Master Bseg ID shows the unique identifier of the master bill segment whose bill triggered the creation of this sub service agreement. This bill segment's consumption was used to calculate the charges on this bill segment.

Premise is the address of the main premise associated with the service agreement (as defined on the service agreement's characteristic premise). It's important to note that the service agreement may cover service at multiple premises, but only one may be defined as the main premise.

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 superceded 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.

Contents

Generate (Bill Segment)

Delete (Bill Segment)

Freeze (Bill Segment)

Rebill (Bill Segment)

Init Cancel (Bill Segment)

Undo (Bill Segment)

Cancel (Bill Segment)

Credit Note (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 SA 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.

When clicked, the Generate window opens.

You must specify the following parameters 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.

- Turn on Allow Estimates if the system is allowed to estimate consumption if it can't find a meter read.

- If the service agreement uses meter reads, use the Billing Option to control how the system retrieves meter reads that appear on the bill. Choose Use Cut off Date if the meter reads must exist on the Cutoff Date (defined above). Choose Use Schedule if you want the service agreement's service point(s) service cycle schedule to control the meter reads that are used (the schedule effective on the cutoff date is used to select the meter reads).

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 WillBill 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).

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. The following table describes common problems and where to go to fix them.

Problem

How To Fix It

The wrong rate was used

Go to Service Agreement - Rate Info and correct the rate.

The wrong meter read was used

Add a meter read with a more powerful read type for the service point in question.

The wrong meter was connected to the service point

Go to SP / Meter Installation and correct the SP / Meter linkage. Then go to Service Agreement - SA / SP and indicate the appropriate start read for the service point's correct meter.

A contract rider was applied incorrectly

Go to Service Agreement - Rate Info and correct the contract rider information.

The wrong tax exemption amount was calculated

Go to Service Agreement - Rate Info and correct the tax exemption information.

Note:

Multi-Cancel/Rebill Saves Time. If the cause of the problem impacts many bill segments related to a service agreement, you should use the Multi Cancel Rebill transaction as it allows you to cancel / rebill an unlimited number of bill segments at once.

Credit Notes. Using the cancel/rebill functionality will cause the cancel and rebill details to be swept on to the customer's next bill unless you Reopen the bill. If your organization requires cancellation details to be presented to the customer separately from the new bill, you should not use the Rebill functionality. Rather, you should issue a Credit Note and then generate a new bill containing the revised charges.

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 AND the bill segment's bill is not linked to an off cycle bill generator. Refer to Bill Segment Lifecycle for more information about these status values.

When clicked, the Rebill window opens.

You must specify the following parameters 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.

- Turn on Allow Estimates if the system is allowed to estimate consumption if it can't find a meter read.

- Use the Billing Option to define how the system looks for meter reads. Select Use Schedule if the system should select reads based on the SA's SP's service cycle schedule. Select Use Cut off Date if the system should only select reads from the end date of the existing bill segment.

- Turn on Use Old Read/Item/SQ for Regen if you want the system to use the consumption 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 customer'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.

When clicked, the Cancel window opens.

You must specify the following parameters 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.

Note:

Credit Notes. Using the cancel functionality will cause the cancel details to be swept on to the customer's next bill unless you Reopen the bill. If your organization requires cancellation details to be presented to the customer separately from the new bill, you should not use the cancelfunctionality. Rather, you should issue a Credit Note and then generate a new bill containing the revised charges.

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.

When clicked, the Cancel window opens.

You must specify the following parameters 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 customer (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 customer. 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 customer because its cancellation appears on the same bill as the original charges).

Credit Note (Bill Segment)

The Credit Note button is used to cancel a bill segment and create a new bill that contains the cancellation details. We refer to this "negative bill" as a credit note. Refer to Credit Notes - Presenting Cancellation Details on a Separate Bill for more information.

Note:

If you want to issue a credit note for an entire bill. Rather than cancel a specific bill segment, functionality exists that allows you to create a credit note for ALL bill segments on a bill. To use this feature, display the bill in question and then click the Credit Note button on the bill page.

This button is enabled if:

- the Use Credit Notes option on the Installation record is turned on AND

- the bill segment is frozen AND

- the bill segment's bill is not written off.

When clicked, the Credit Note window opens.

You must specify the following parameters to cancel the frozen bill segment:

- Cancel Reason defines why you are performing the cancellation.

- Accounting Date defines the financial period to which the canceled bill segment's financial transaction will be booked. The current date defaults when the window opens.

- Credit Note Date defines the date of the credit note on which the cancellation details will appear. The current date defaults when the window opens.

After specifying the above parameters, click the Calculate button to cancel the frozen bill segment and create a credit note.

It should be noted that if this operation is successful, the new "negative bill" will be complete (meaning that it will be ready for transmission to the customer and for interface to the general ledger).

Bill Segment - Read Details

The Read Details page contains information about the meter reads that were used to derive the bill segment's metered consumption. Open Financial, Bill Segment, Read Details to view this information.

Note:

Refer to How The System Determines How Much Was Consumed for how the system assembles this information.

Fastpath:

The Description of Page section below 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 Seg Info is a concatenation of the bill segment's division, SA type, status, bill period and amount. Bill Segment ID is the system-assigned unique identifier of the bill segment.

The meter read grid is a snapshot of the meter reads used to calculate the bill segment's consumption. One row exists for every register linked to every meter linked to every service point linked to the service agreement. This information is for audit purposes only and may not be modified. The following information is displayed in the grid:

- Final Unit of Measure is the unit of measure of the resultant billing quantity.

- Final Time of Use is the time-of-use code of the resultant billing quantity.

- Final Service Quantity ID is the service quantity identifier of the resultant billing quantity.

- Register Quantity is the resultant billing quantity.

- Service Point ID is the unique identifier of the service point at which the meter was located.

- Meter Configuration ID is the unique identifier of the meter's configuration.

- Sequence is the sequence number of the register on the meter.

- Unit of Measure is the register's unit of measure.

- Time of Use is the register's time-of-use code.

- SQI is reserved for future use.

- Start Register Reading is the start register reading. If the register is consumptive, (as opposed to subtractive) the word N/A - Consumptive is displayed, as the start read is not relevant. Click the Go to button to drill down into the meter read.

- End Register Reading is the end register reading. Click the Go to button to drill down into the meter read.

- Measured Quantity is the resulting measured quantity.

Note:

Measured quantity isn't necessarily the difference between the start and end read. The measured quantity is equal to the Measured Quantity * Register Constant * Installation Constant * Use Percent.

Measured quantity isn't necessarily the quantity that's billed. If the rate used to calculate the bill segment has a register rule, this consumption will be transformed further. For example, a cubic foot of gas can be transformed by a register rule to a therm of gas. When register rules convert measured consumption, they do NOT overwrite the measured quantity. Rather, they populate the Final UOM, Final TOU, Final SQI, and Register Quantity with the final billable quantity. Refer to Setting Up Register Rules for more information.

- Register Constant is the constant on the register that is multiplied by the measured quantity to derive the register's billable consumption.

- How To Use is the register's how to use code.

- How To Use (SP) is the SA/SP's how to use code.

- Use Percent is the SA/SP's usage percentage.

- Measures Peak Qty indicates if the unit of measure is one that measures peak consumption.

- Start Read Date/Time is the date and time of the start meter read. If the register is consumptive, (as opposed to subtractive) nothing will be displayed.

- End Read Date/Time is the date and time of the end meter read.

- Start Reg Read ID is the unique identifier of the start register read. If the register is consumptive, (as opposed to subtractive) nothing will be displayed.

- Read Type is the read type of the start meter read.

- End Reg Read ID is the unique identifier of the end register read.

- Read Type is the read type of the end meter read.

- Multiplier is the composite multiplier that converts the measured quantity to the registered quantity.

Note:

The multiplier is calculated by dividing the Register Quantity by the Measured Quantity (if the Measured 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.

Bill Segment - Item Details

Fastpath:

The Description of Page section below describes the fields on this page. Refer to How To Override The Items Billed On A Specific Bill Segment for a description of how to override this information.

The Item Details page contains information about the items located at the service agreement's service points. Open Financial, Bill Segment, Item Details to view this information.

Note:

Refer to How The System Determines How Much Was Consumed for how the system assembles this information.

Description of Page

Bill Seg Info is a concatenation of the bill segment's division, SA type, status, bill period and amount. Bill Segment ID is the system-assigned unique identifier of the bill segment.

The item details grid is a snapshot of the items that existed at the service agreement's service points at the time the bill segment was created. One row exists for every type of item linked to every service point linked to the service agreement.

This information may be modified on a bill segment in the Error or Freezable state. Insert one row in the item grid (click the + button) for each item you need to add. You may also change item amounts that were populated by the system when it initially generated the bill by simply overwriting the information.

Warning:

The proper way to fix the number and type of items on a bill segment is to correct the service point / item information and then regenerate the bill segment. Overriding the item details on a bill segment is a last resort that should only be used when you can't fix the service point / item information (for whatever reason).

The following information is displayed in the grid:

- Seq No is the system-assigned unique identifier of the item detail row.

- Item Type is the type of item.

- Item ID is the unique identifier of the item (this is only displayed if a badged item is linked to the service point; non-badged items don't have unique identities).

- Start Date is the first day in the bill segment's bill period that the item was linked to the service point.

- End Date is the last day in the bill segment's bill period that the item was linked to the service point.

- Item Count is the number of items of this type that were linked to the service agreement's service points.

- If the item's item type indicates the system must estimate consumption (e.g., lamps), UOM is the unit of measure of the estimated consumption. Daily Service Quantity is the item's estimated amount of daily consumption.

Fastpath:

Refer to Setting Up Item Types for more information about item types. Refer to Setting Up Estimated Consumption For Items for more information about defining the estimated consumption amount for items.

Bill Segment - SQ Details

Fastpath:

The Description of Page section below describes the fields on this page. Refer to How To Override Service Quantities On A Specific Bill Segment for instructions describing how to override this information.

The SQ Details page contains information about the service quantities (SQ) that will be priced by the service agreement's rate. In addition to showing SQ details, this page shows any Calculation / Audit Read Details that are linked to the bill segment. Open Financial, Bill Segment, SQ Details to view this information.

Description of Page

Bill Seg Info is a concatenation of the bill segment's division, SA type, status, bill period and amount. Bill Segment ID is the system-assigned unique identifier of the bill segment.

The Service Quantity details grid is a snapshot of the service quantities amassed from:

- The bill segment's meter reads.

- The bill segment's usage request.

- Those items for which the system estimates consumption.

- The SQ rules defined on the service agreement's rate. Refer to Defining Measured Quantity Manipulation Rules for more information about how SQ rules can introduce additional service quantities.

- The register rules defined on the service agreement's rate. Refer to Defining Measured Quantity Manipulation Rules for more information about how register rules can introduce additional service quantities.

- Billable charges that supply service quantities.

One row exists for every unique combination of unit of measure (UOM), time-of-use (TOU) code, and service quantity identifier (SQI) associated with the service agreement. Refer to UOM versus TOU versus SQI for more information.

This information may be overridden on a bill segment in the Error or Freezable state. Insert one row in the service quantity grid (click the + button) for each UOM/TOU/SQI 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.

Warning:

The proper way to fix the SQ details on a bill segment is to correct the cause of the error (e.g., correct the meter reading). Overriding the SQ 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 service quantity.

- Time of Use is the time-of-use of the service quantity.

- SQI is the service quantity identifier of the service quantity.

- Initial Service Quantity is the initial quantity amassed by the system before application of the rate's SQ rules.

- Billable Service Quantity is the service quantity that will be priced by the service agreement's rate. This amount differs from the initial service quantity when the rate's SQ rules manipulate consumption.

The Calculation/Audit Read Details section contains Calculation / Audit Read Details. This section only appears if any of the following conditions are true:

- The service agreement has a special role of Billable Charge , Bill Determinants Required or Interval Billing .

- The bill segment has one or more reads with a usage flag of Calculation/Audit .

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 SQI is the final service 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.

- 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 SQI.

- 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.

- SQI is the initial service 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 consumption).

- 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 consumption).

- Measured 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 consumption). 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 Measured Quantity to derive the calculation / audit read's Quantity.

- How To Use is a code that indicates if the "calculation / audit" read was is considered to be additive, subtractive, peak or check.

- Use Percent is the percentage of the total consumption that was billed.

- Meas Peak Qty indicates if the unit of measure is one that measures peak consumption.

- Multiplier is the ratio of the Quantity and the Measured Quantity. This value only appears if a non-zero value exists in both of these fields.

- Seq No is the sequence number (if any).

- Service Point is the unique identifier of the service point at which the readings were calculated (if applicable).

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.

Warning:

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.

The Calculation/Audit Usage Details grid contains usage service quantities for the bill segment. This section appears when the service agreement has a special role of Bill Determinants Required . The following information is displayed in the grid:

- Final Unit of Measure is the final unit of measure of the calculation / audit usage.

- Final Time of Use is the final time-of-use code of the calculation / audit usage.

- Final Service Quantity ID is the final service quantity identifier of the calculation / audit usage.

- Start Date/Time is the date and time of the calculation / audit usage.

- End Date/Time is the date and time of the calculation / audit usage.

- Quantity is the quantity of the calculation / audit usage. 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 SQI.

- Sequence is the sequence number.

- Service Point ID is the unique identifier of the service point at which the usage was calculated.

Fastpath:

Refer to Calculation / Audit Usage Details for more information about this section.

Bill Segment - Calc Lines

Fastpath:

The Description of Page section below 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 customer's bill. Open Financial, Bill Segment, Calc Lines to view this information.

Fastpath:

Most service agreements 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, SA type, status, bill period and amount. Bill Segment ID is the system-assigned unique identifier of the bill segment.

The Bill Segment Header ( Bill Seg Hdr) 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. For metered service, this period is referred to as the consumption period.

- 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 customer'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:

- An extra column with a drill down button appears if the bill calculation line is the result of an interval pricing rate component or a TOU pricing rate component that contains an audit algorithm. For more information, refer to Interval Billing Calculation Details.

- A drill down button appears in the Calc Line Char column if the bill calculation line has characteristics. The Calc Line 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 customer'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 customer'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 service quantity priced on the calculation line.

- Time of Use (TOU) is the time-of-use code of the service quantity priced on the calculation line.

- SQI is the service quantity identifier of the service quantity priced on the calculation line.

- Billable Service Quantity is the service quantity priced on the calculation line. This quantity will be different from the measured consumption is there are SQ 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. This is only populated if the original rate engine calculated the charges.

- Calculation Rule is the rule that calculated the line. This is only populated if the new rate engine calculated the charges.

- Measures Peak Qty is checked if the UOM priced on the calculation line is used to measure a peak quantity.

- Exempt Amount is the amount of the calculated charge that the customer doesn't have to pay because they are tax exempt.

- 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 bill factor (because only bill factors use characteristic values). Refer to An Illustration Of A Bill Factor And Its Characteristics for more information.

Bill Segment - Financial Details

Fastpath:

The Description of Page section below 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 Financial, Bill Segment, Financial Details 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, SA 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 customer'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 service agreement's current balance.

- Payoff Amount contains the FT's effect on the service agreement'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.

- Arrears 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:

- Seq 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. For example, if the line is associated with a charge for the total number of kilowatt-hours consumed, the statistics code will be the KWH and the statistics amount will be the number of kilowatt hours associated with the charge.

- 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 bill factor (because only bill factor's use characteristic values). Refer to An Illustration Of A Bill Factor And Its Characteristics for more information.

- 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.

Bill Segment - Bill Segment Messages

The Messages page is a grid containing one row for every message that appears on the bill segment. Open Financial, Bill Segment, Bill Segment Messages 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.

The bill may also have messages. Be aware that only service agreement-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, SA 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.

Bill Segment - Sub Bill Segments

The Sub Bill Segments page contains the sub bill segments that are associated with the master SA's bill segment. Open this page using Financial, Bill Segment, Sub Bill Segment.

Note:

Sub bill segments are only linked to the master SA's bill segment when the master SA has an SA relationship with a We Bill For Them - Rate Ready or an It's Us service provider. Refer to The Rate Ready Calculation Method for the details.

Description of Page

Bill Seg Info is a concatenation of the bill segment's division, SA type, status, bill period and amount. Bill Segment ID is the system-assigned unique identifier of the bill segment.

The following information is displayed in the grid.

- Click the adjacent Go To button to transfer to the bill segment.

- The Bill Segment column contains a concatenation of the bill segment's business unit, SA type, status, bill period and amount. The business unit and SA type come from the bill segment's service agreement.

- The Current Amount column contains the bill segment's effect on the sub service agreement's current balance.

- The Status column contains the bill segment's current status.

Bill Segment - Bill Segment Portal

Select Main Menu > Financial > Bill Segment and navigate to the Bill Segment Portal tab to view additional information associated with a Bill Segment.

General Information

Bill Segment ID, Bill Se Info are displayed.

Depending on your implementations requirements, you may define additional zones to appear on this Portals

Refer to The Big Picture of Portals and Zones in the Oracle Utilities Application Framework Administration Guide for a description of portal and zone functionality.

Bill Segment - Usage

This Usage portal is available when the bill segment has associated usage requests. It displays all usage requests related to the bill segment. Open this page using Financial, Bill Segment, Usage.

General Information

Bill Segment ID is the system-assigned unique identifier of the bill segment.

Bill Segment Information contains a concatenation of important information about the bill segment.

Bill Segmet Usage

The following information is displayed in the Bill Segment Usage zone:

- The Create Date/Time of the usage request.

- The Usage column contains a concatenation of the bill segment's division, SA type, status, and period of the usage request. The usage information links to the Usage Portal for the usage request.

- The Usage ID for the usage request.

Financial - Bill Segment Calculation Line Characteristics

This page displays the characteristics that are linked to a specific bill segment calculation line. The information on this page is for audit purposes only and cannot be changed.

Open this page by clicking the Go To Calc Line Characteristic button on the calculation lines grid of the Bill Segment - Calc Lines page.

Description of Page

Accountis the account to which the bill segment is linked. The name of the main person on the account appears next to the account ID.

The SA is the service agreement to which the bill segment applies. Basic information about the service agreement appears adjacent.

Premise shows the service agreement's characteristic premise (i.e., the primary premise associated with the service agreement).

The Bill Seg ID and Bill Seg Header displays the identification of the bill segment and header associated with the calculation line characteristic.

Calc Line displays the calculation line number with which the characteristics are associated.

The Description on Bill displays the description of the calculation line that appears on the customer's bill.

The characteristics grid displays the Characteristic Types and the Characteristic Values associated with the calculation line.

Fastpath:

For more information about characteristics, refer to Setting Up Characteristic Types and Their Values.

Off Cycle Bill Generator

The Off Cycle Bill Generator portal may be used to create an off cycle bill for an account where you control which financial transactions are linked to the resultant bill. For example, you can create a bill for a specific adjustment or billable charge. Navigate using Main Menu, Financial, Off Cycle Bill Generator.

Contents

Off Cycle Bill Generator Query

Off Cycle Bill Generator Portal

Off Cycle Bill Generator Query

Use the query portal to search for an existing off cycle bill generator. Once an off cycle bill generator is selected, you are navigated to the maintenance portal to view and maintain the selected record.

Off Cycle Bill Generator Portal

This portal appears when an off cycle bill generator has been selected from the Off Cycle Bill Generator Query portal.

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

Contents

Off Cycle Bill Generator Actions

Off Cycle Bill Generator Zone

Financial Transactions On Bill

Off Cycle Bill Generator Log

Off Cycle Bill Generator Actions

This is a standard actions zone.

If the off cycle bill generator is in a state that has valid next states, buttons to transition to each appropriate next state are displayed.

Fastpath:

Refer to How To Create An Off Cycle Bill Generator for more information about how to create an off cycle bill on-line / real time.

Off Cycle Bill Generator Zone

The Off Cycle Bill Generator zone contains display-only information about the off cycle bill generator.

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

Financial Transactions On Bill

The Financial Transactions On Bill zone shows financial transactions linked to the off cycle bill generator's bill. Information displayed on this zone is similar to that displayed on the Financial Transactions On A Bill transaction.

Off Cycle Bill Generator Log

An off cycle bill generator log contains an entry for every recorded event during the lifecycle of the off cycle bill generator. There are two general types of log entries:

- Automatic entries. The system automatically creates an entry in the log when an off cycle bill generator 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.

Multi Cancel/Rebill

The Multi-Cancel/Rebill transaction is used to cancel / rebill (and freeze) one or more bill segments linked to a service agreement.

Note:

You would typically use this transaction when something has been wrong for an extended period of time. For example, if the customer was assigned the wrong rate when they first started service, you would correct the customer's rate using Service Agreement - Rate Info and then use this transaction to cancel / rebill the customer's historical bill segments.

Also note that for service agreements that require bill determinants from Meter Data Management, this transaction may only be used to cancel / rebill a single bill segment at a time.

The following topics describe how to use this transaction.

Contents

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 Financial, Multi-Cancel/Rebill to use this transaction.

Description of Page

This page contains all non-cancelled bill segments associated with a given SA ID. The service agreement's SA Info, Account ID (and name), characteristic Premise (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 Clear 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. When this button is clicked, an additional informational page displays. 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.

- Turn on Allow Estimates if the system is allowed to estimate consumption if it can't find a meter read.

- Use the Billing Option to define how the system looks for meter reads:

- Select UseSchedule if the system should select reads based on the SA's SP's service cycle schedule.

- Select Use Cut off Date if the system should only select reads from the end date of the existing bill segment.

- If you'd prefer to have the system use the consumption details snapshot on the original bill segments, turn on Use Old Read/Item/SQ. If this switch is on then neither Allow Estimates nor Billing Option is relevant. The Use Old Read/Item/SQ switch is not available if the bill's SA references an SA type with a special role flag of Bill Determinants Required .

Warning:

If the cause of the rebill is an incorrect rate and the new rate requires service quantities that were not calculated when the bill was originally calculated, do not turn on Use Old Read/Item/SQ. Why? Because you want the system to derive new service quantities during the rebill process.

Note:

Default note. The Accounting Date is defaulted to the current date and the Use Old Read/Item/SQ 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 SA's rate to a rate that requires a unit-of-measure that doesn't exist on the SA's meter, 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.

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 customer.

Multi Cancel/Rebill - Graph

This page contains a graph that shows the rebilled and original payoff amounts for a service agreement's non-cancelled bill segments. Open Financial, 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 a service agreement'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.

SA Billing History

Open Financial Query, SA Billing History to view a history of all bill segments produced for a service agreement.

Description of Page

The Account ID is displayed with the account's name adjacent.

The SA Information shows a summary of information about the service agreement. The SA ID is the unique identifier of this SA.

One row is displayed for every bill segment ever produced for the selected service agreement.

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 service quantity designated as the "graph UOM" for the SA's SA type.

- The total amount of the service Billable Service Quantity that was billed.

- The Avg Daily Qty is the Billable Service 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 customer should be charged for a service that occurs outside the normal course of business. For example, you would create a billable charge to charge a contractor for the repair of a ruptured gas line.

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 a service agreement. This service agreement behaves just like any other service agreement:

- Bill segments are created for the service agreement. Whenever billing is performed for an account with billable charge service agreements, the system creates a bill segment for each billable charge. This means that if a service agreement has many unbilled billable charges, it will have many bill segments.

- Payments are distributed to the service agreement. Payments made by an account are distributed to its billable charge service agreements just like any other service agreement.

- Overdue debt is monitored. The credit and collections process monitors billable charge service agreements for overdue debt and responds accordingly when overdue debt is detected.

- This service agreement must reference an SA Type that has a Special Role Flag of Billable Charge . If such a service agreement 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 customer. 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. For example, you can create a billable charge template to levy charges when a contractor ruptures a gas main. This template would contain the bill lines, amounts and distribution codes associated with a ruptured pipe repair. Then, when a contractor ruptures a line, a user can create a billable charge using the template and override the amount to reflect the actual repair amount (if it differs from the norm).

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 - SQ Details for information about how to have the system calculate tax lines and append them to the billable charge.

Contents

Billable Charge - Main

Billable Charge - Line Characteristics

Billable Charge - SQ Details

Billable Charge - Read Details

Billable Charge - Main

Open Financial, 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 SA ID to define the ID of the billable charge service agreement that will hold the billable charge's debt. The Account ID for the service agreement 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 customer $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 SA Type indicates a billable charge template, that value will be defaulted.

Use Description on Bill to define the verbiage that should print on the customer's bill above the line item details.

Billable Charge Status defines the state of the billable charges. Possible values are Billable and Cancelled . 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 scroll 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 customer'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 A One-Time Invoice. For more information about billable charge templates, refer to Setting 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 Financial, Billable Charge, Line Characteristics 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 - SQ Details

Optionally, you may specify service 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 SA must specify a rate. If you want the system to calculate additional charges based on the service quantities defined on this page, the related billable charge service agreement must reference a rate. This rate must have rate components that calculate charges based on the service quantities specified on this page. When the service agreement is next billed, the system will sweep on the billable charges and then call the rate and pass it the service quantities defined on this page. The rate will calculate the additional charges and these will be appended to the bill segment.

Open Financial, Billable Charge, SQ Details to maintain a billable charges service quantities.

Description of Page

The following fields display:

Sequence Specify the sequence number of the SQ.

UOM Select the unit of measure of this SQ. One or more of UOM, TOU, or SQ Identifier must be selected.

TOU Select the time of use period.

SQ Identifier Select the SQ identifier.

Service Quantity Specify the number of units of this service quantity.

Billable Charge - Read Details

Optionally, you may specify meter read details associated with a billable charge. These are most commonly used when you need to print the read details that were used to calculate the bill lines that appear on the main tab.

Note:

Using these reads to derive billable consumption. The base package bill segment creation algorithm simply sweeps billable charge read details onto the related bill segment as calculation / audit reads. This algorithm does NOT use these reads to derive billable consumption. This is intentional as most implementations that import reads also import billable consumption and therefore deriving billable consumption is unnecessary (and also error prone). If your implementation needs to derive billable consumption from these reads, you can develop your own bill segment creation algorithm to do just this.

Open Financial, Billable Charge, Read Details to maintain a billable charges service quantities.

Description of Page

The grid is a snapshot of the meter reads whose consumption was billed using the bill lines shown on the main tab. One row exists for every read that should be swept onto the related bill segment as a calculation / audit read 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 unit of measure of the resultant billing quantity.

- Final Time of Use is the time-of-use code of the resultant billing quantity.

- Final Service Quantity Identifier is the service quantity identifier of the resultant billing quantity.

- Register Quantity is the resultant billing quantity.

- How To Use (SP) is the SA/SP's how to use code.

- Service Point ID is the unique identifier of the service point at which the meter was located.

- Meter Configuration ID is the unique identifier of the meter's configuration.

- Sequence is the sequence number of the register on the meter.

- Unit of Measure is the register's unit of measure.

- Time of Use is the register's time-of-use code.

- SQI is reserved for future use.

- Start Register Reading is the start register reading.

- End Register Reading is the end register reading.

- Measured Quantity is the resulting measured quantity.

- Register Constant is the constant on the register that is multiplied by the measured quantity to derive the register's billable consumption.

- How To Use is the register's how to use code.

- Use Percent is the SA/SP's usage percentage. A value of 100% is defaulted.

- Measures Peak Qty indicates if the unit of measure is one that measures peak consumption.

- Start Read Date/Time is the date and time of the start meter read. If the register is consumptive, (as opposed to subtractive) nothing will be displayed.

- End Read Date/Time is the date and time of the end meter read.

- Start Reg Read ID is the unique identifier of the start register read. If the register is consumptive, (as opposed to subtractive) nothing will be displayed.

- Read Type is the read type of the start meter read.

- End Reg Read ID is the unique identifier of the end register read.

- Read Type is the read type of the end meter read.

- Multiplier is the composite multiplier that converts the measured quantity to the registered quantity.

Note:

The multiplier is calculated by dividing the Register Quantity by the Measured Quantity (if the Measured 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.

Contents

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.

Contents

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.

Contents

Billable Charge Upload Staging Layout

Billable Charge Line Upload Staging Layout

Billable Charge Line Characteristic Upload Staging Layout

Billable Charge Service Quantity Upload Staging Layout

Billable Charge Read 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

This is the external system id of the sender of the billable charge. See the description of the SA_EXT_REFT_ID field for how this field is used to determine the billable charge's SA_ID. Refer to Designing External Systems for more information about this field.

SA_EXT_REF_ID

36

N

Varchar2

This field along with NT_XID_CD are used to uniquely identify the service agreement against which the billable charge will be stored. These two fields are used to identify a SA relationship record; the SA relationship record, in turn, has a sub SA and it is this SA that the billable charge will be linked to. Note well: these fields are only necessary if you do not know the billable charge SA ID. Refer to Maintaining SA Relationships for more information.

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 a SA ID of a billable charge service agreement. You may leave this column blank if NT_XID_CD and SA_EXT_REF_ID are populated.

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 BCHG_UP_XTYPE. Please pay special attention to the Comments column below as many fields, if left blank, will default from each record's BCHG_UP_XTYPE.

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 customer's printed bill. This should be N if the line should not appear on the customer'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 Service Quantity Upload Staging Layout

You must create a billable charge service quantity upload record for each service 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 service quantity within the Billable Charge Upload

UOM_CD

4

N

Char

The unit of measure of the Billable Charge Upload SQ 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 SQ 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 service quantity identifier of the Billable Charge Upload SQ 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 service used for the UOM / TOU / SQI combination

Billable Charge Read Details Upload Staging Layout

You must create a billable charge read details upload record for each read 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

Note, if USAGE_FLG is calculation, you can set this field to 0 if you do not know the SP ID. The only thing that's important is that the combination of BCHG_UP_ID, SP_ID and SEQNO are unique.

SEQNO

5

Y

Number

This should be a value greater than zero. See SP_ID comment for more information. This is typically the sequence number of the register on the meter.

END_READ_DTTM

26

Y

DateTime

This is the date and time of the end read

END_REG_READ_ID

12

N

Char

This field must reference an existing register read ID if USAGE_FLG is anything other than a calculation.

END_REG_READING

9.6

Y

Number

This is the reading of the end read.

FINAL_REG_QTY

12.6

Y

Number

This is the final amount of the reading (this is the amount of billable consumption the read detail contributed to the entire billed consumption).

FINAL_SQI

8

N

Char

The service 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

This is the difference between END_REG_READING and START_REG_READING for subtractive registers.

REG_CONST

6.6

Y

Number

This is the register's constant (the value used to adjust the measured quantity due to something associated with the physical meter). Set this to a value of 1 if it is not known.

SQI_CD

8

N

The service quantity identifier of END_REG_READING and START_REG_READING. 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 reading.

START_REG_READ_ID

12

Y

Char

This field must reference an existing register read ID if USAGE_FLG is anything other than a calculation.

START_REG_READING

9.6

Y

Number

This is the reading of the start read.

TOU_CD

8

N

Char

The time-of-use code of END_REG_READING and START_REG_READING. If specified, it must reference a valid value on CI_TOU.

UOM_CD

4

Y

Char

The unit of measure of END_REG_READING and START_REG_READING.

USAGE_FLG

2

Y

Char

See the field description in the data dictionary for the valid values ( CI_BCHG_UP_READ ).

USE_PCT

3

Y

Number

This is the percentage of the consumption that was billed (this will typically be 100).

BCU1 - Validate & Populate Billable Charge Upload Staging

This process has several functions:

- It populates the SA ID on all BC upload staging records where SA ID is left blank. This means that you don't have to know the SA ID in order to interface a billable charge into the system. The program populates SA ID with the service agreement related to the SA relationship with the most recent effective date for a given combination of service provider's external system ID and customer's ID in the sender's system. The system can only do this if the following points are true:

- You use the system's SA relationship functionality to define that you provide bill ready billing services for a service provider. On the customer's SA relationship record you must define the customer's ID in the service provider's system. Refer to Maintaining SA Relationships for more information.

- You identify the service provider's external system ID on the billable charge upload staging record.

- You identify the customer's ID in the sender's system.

Note:

You can still interface billable charges if you don't use the system's SA relationship functionality. How? You simply need to derive the SA ID associated with the uploaded billable charge.

- It 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 BC upload records in the Pending state.

If the billable charge's SA 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 service agreement's SA type has an override value for the line's billable charge line type. Refer to SA 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 BC Upload Staging page (don't forget to change 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.

Contents

Billable Charge Upload - Main

Billable Charge Upload - Lines

Billable Charge Upload - SQ Details

Billable Charge Upload - Read Details

Billable Charge Upload - Main

Open this page using Financial, Billable Charge Upload Staging, Main.

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 Financial, Billable Charge Upload Staging, Lines.

Description of Page

Fastpath:

Refer to Billable Charge Line Upload Staging for more information about these fields.

Billable Charge Upload - SQ Details

Open this page using Financial, Billable Charge Upload Staging, SQ Details.

Description of Page

Fastpath:

Refer to Billable Charge Service Quantity Upload Staging for more information about these fields.

Billable Charge Upload - Read Details

Optionally, you may specify meter read details associated with a billable charge. These are most commonly used when you need to print the read details that were used to calculate the bill lines that appear on the main tab.

Note:

Using these reads to derive billable consumption. The base package bill segment creation algorithm simply sweeps billable charge read details onto the related bill segment's read detail. This algorithm does NOT use these reads to derive billable consumption. This is intentional as most implementations that import reads also import billable consumption and therefore deriving billable consumption is unnecessary (and also error prone). If your implementation needs to derive billable consumption from these reads, you can develop your own bill segment creation algorithm to do just this.

Open Financial, Billable Charge, Read Details to maintain a billable charges service quantities.

Description of Page

Fastpath:

Refer to Billable Charge Read 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.

Budget Review

The Budget Review page shows all accounts with an anomalous budget amount.

Note:

This information on this page is created by the Budget Monitor background process.

Open this page using Financial Query, Budget Review.

Description of Page

One row is displayed for every account whose current budget amount is out-of-sync with the recommended budget amount.

Clicking the Go To button will cause the Account - Budget page to open. When this page opens you can recalculate the customer's budget amount.

Payments

In this section, we describe how to manage your customer's payments.

Contents

The Big Picture of Payments

Maintaining Payment Events

Payment Event Quick Add

Payment Quick Add

Maintaining Payments

Payment Portal

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.

Contents

A Payment Event Has Payments And Tenders

Multiple Tenders Used To Pay For Multiple Accounts

An Overview Of The Payment Event Creation & Allocation Process

Distributing A Payment Event

Distributing A Payment Amongst An Account's Service Agreements

Overpayment

Canceling A Tender Versus Canceling A Payment

NSF Cancellations

Transferring A Payment

Unbalanced Payment Events

How And When Payments Appear On Bills

Tender Management and Workstation Cashiering

Exceptions

Payment Financial Transaction Considerations

A Payment May Affect More Than Just Customer Balances

Automatic Payments

Issuing A Payment Advice Instead Of Creating An Automatic Payment

A Payment Event Has Payments And Tenders

The explanation in The Financial Big Picture provides an accurate, but incomplete view of payments. The missing pieces concern payment events and tenders. The following diagram illustrates the difference 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 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 SA's The system allocates an account's payment amount amongst its service agreements. The system creates a payment segment for each service agreement 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.

By default, the system allocates the sum of the tenders 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 service agreements based on the age of each service agreement's debt AND distribution priority. The system creates a payment segment for each service agreement that receives part of the payment.

Fastpath:

Refer to Distributing A Payment Amongst An Account's Service Agreements for more information.

You may manually redistribute the payment amount amongst the account's service agreements 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 service agreements' 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.

Distributing A Payment Event

Warning:

This section deals with the concept distributing a payment amount into payment(s). It does not discuss the distribution of a single payment into segments. For more information about payment distribution, refer to Distributing A Payment Amongst An Account's Service Agreements.

The base-package, by default, creates a single payment for a payment event. Some business practices require potentially many payments to be created when payment events are added.

A few examples of when multiple payments may be necessary are:

- A payment amount needs to be distributed towards different distribution types:

- $50 in interest

- $60 in collection charges

- $70 in taxes

- Each of the above distributions is realized as a separate payment identified by its own match type (i.e., there'll be one match type called Interest, another called Collection Charges, etc.).

In this example, the debt of a single service agreement may be relieved by each of these payments.

- In a similar way, you may want to create a separate payment for an overpayment to differentiate it from regular payments (using yet another match type).

- In the case of a social service agency that pays for many accounts, a single payment event may be distributed amongst multiple accounts.

The method by which a payment amount is distributed to create payment(s) is contained in Create Paymentalgorithms plugged in on a distribution rule.

There is yet another aspect to having control over how payment events are created. The default method of creating payment events assumes knowledge of account IDs (of the payor and the payee) when making a payment. In cases where payments are made by and towards business entities other than accounts, knowledge of their corresponding account IDs may not be available at payment time. Consider the following examples:

- A payment is made to pay a person's bill, providing the person's identification at payment time.

- A payment is made towards a specific service agreement using a "contract number" defined as SA characteristic.

The method by which the tender account is determined by means of an alternate identifier is contained in Determine Tender Accountalgorithm plugged in on a distribution rule.

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 Service Agreements

Warning:

This section deals with the concept of distributing a payment amongst an account's service agreements. It does not discuss how the sum of a payment event's tenders is balanced out by payment allocations. For more information about payment event balance, refer to Unbalanced Payment Events.

A payment must be distributed to one or more service agreements for its financial impact to be realized. When a payment satisfies an account's entire debt, you don't have to worry about how the system distributes the payment. The concept of payment distribution is only relevant when a partial or excess payment is distributed.

The first important point to understand is that the method of distributing a payment amongst an account's service agreements is contained in an algorithm that's plugged in on to Customer Class. This means that you can have different distribution algorithms for different customer classes.

Note:

Manual overrides. Most of the time, you'll let the payment distribution algorithm distribute the payment amongst an account's service agreements. However, you may manually distribute a payment when a customer directs a payment to specific service agreement(s).

The following explanation describes one of the base package payment distribution algorithms (refer to Payment Distribution - Pay Priority and Debt Age for information about this algorithm). This algorithm distributes a payment based on:

- The age of each service agreement's debt.

- The payment distribution priority of each service agreement's SA type.

The following diagram helps illustrate how the distribution algorithm works.

Important:

There are other payment distribution algorithms in the base package. Click here to see the available algorithm types.

The above example shows three columns, one for each service agreement linked to a hypothetical account. Notice that two of the service agreements have the same distribution priority, the third has a lower priority. The numbers in the cells indicate the order in which the system distributes a partial payment.

Note:

Debt terminology. Before we can discuss the distribution algorithm, you must understand the terminology we use to categorize debt. Delinquent debt is associated with financial transactions that appear on overdue bills. Non-delinquent debt is associated with financial transactions that appear on current bills. New debits debt is associated with financial transactions that do not yet appear on a completed bill (e.g., a late payment charge that hasn't been billed yet).

The following points describe the algorithm used to distribute the partial payment:

- The system pays off delinquent debt of the highest priority service agreements first. In the above example, where multiple service agreements have the same distribution priority, the system does NOT payoff one service agreement before it starts on the next (which one would it pick?). Rather, it distributes the payment amongst the service agreements based on the age of the respective debt on each service agreement. In the above example, this is represented by steps 1 through 6 (notice how the distribution jumps between SA1 and SA2).

- After all delinquent debt has been relieved from the highest priority service agreement(s), the system pays off the next priority until all delinquent debt is relieved. In the above example, this is represented by steps 7 through 9.

- The system next pays off non-delinquent debt using each service agreement's respective distribution priority. Note well, the payment distribution algorithm doesn't associate an age with non-delinquent debt and therefore the distribution is based purely on the service agreements' respective distribution priority. In the above example, this is represented by steps 10 through 12.

- After all non-delinquent debt is relieved, the system next pays off "new debit" debt based on the service agreements' respective distribution priority. In the above example, this is represented by steps 13 through 15.

- Refer to Overpayment for a description of what happens if money still exists after the above distribution is complete.

Note:

Payment segments and financial transactions. A payment segment exists for each service agreement that receives a portion of a payment. Linked to each payment segment is a financial transaction. It is the financial transaction that causes the service agreement's debt to be relieved and the general ledger to be impacted.

Fastpath:

Refer to Payment Exception for more information about how the system handles errors detected during the payment distribution process.

Note:

Overriding the distribution algorithm for uploaded payments. The standard distribution algorithm is used for payments that are Interfaced From An External System unless you specify a MATCH_VALUE and MATCH_FLG on the Payment Staging row associated with the uploaded payment. These fields 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_FLG indicates how the payment should be distributed (e.g., only distribute to a specific service agreement), MATCH_VALUE contains the ID of the restriction (e.g., the SA ID).

Open item customers. For an open-item customer, you MUST override the standard distribution algorithm because the payment is distributed as per the open items that it is relieving. Refer to Payments And Match Events for more information.

Overpayment

Overpayment refers to the situation where money is left over after a payment has been distributed to all eligible service agreements, and all debt is relieved. Refer to Overpayment Segmentation 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 misdistribution 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 customer class. Algorithms of this type will typically create an adjustment or billable charge to levy the NSF charge. Refer to NSFC-DFLT for an example of such an algorithm.

Note:

The payor gets the NSF adjustments. It's possible for the payor of a tender to differ from the payee (e.g., when a social service agency pays for other customers' debt). When you cancel a tender you must specify a cancellation reason. If the cancellation reason indicates an NSF charge should be levied, the sample algorithm provided with the system levies the NSF charge on the PAYOR's account. Because adjustments must be linked to a service agreement, the algorithm picks the payor's service agreement with the highest payment distribution priority and levies the adjustment specified in the service agreement's SA type's NSF adjustment type.

Besides calling this algorithm, a NSF cancellation may affect the tendering account's credit rating and cash-only score. The cancellation reason indicates the extent to which the account's ratings are affected.

And finally, whenever a tender is canceled due to non-sufficient funds, the account is scheduled for review by the Account Debt Monitor.

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, by default, distributes the sum of a payment event's tenders to the account that remits the tender with a single payment. After distribution the sum of the tenders equals the sum of the payments when the event is first created. We refer to such an event as being balanced .

However, it is possible for an event's tender amount to not equal the sum of the payment allocations (i.e., the event becomes unbalanced ). How? Well, 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 tenders 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 uncanceled 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.

How And When Payments Appear On Bills

Fastpath:

Refer to Financial Transactions Created Between Bills for more information.

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.

Note:

Default note. When a user adds a tender control the system attempts to default a tender source based on the currency of the deposit control and the tender source(s) defined on the user's record. If your organization accepts alternate currency payments, then a tender source must exist for each currency code accepted at a location.

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, customers 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.

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.

Contents

Managing Your Cash Drawers

Turn Ins

Balancing By Tender Type

Cash Back

Managing Payments Interfaced From External Sources

Managing Your Cash Drawers

Warning:

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 follows 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.

Note:

Alternate currency payments. If your organization accepts payments in alternate currencies, that is, a currency other than the account's currency; a supervisor would create a deposit control for each such currency. Likewise, the cashier would create a tender control for each such currency.

Fastpath:

Refer to Alternate Currency Payments for more information.

- 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.

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 customer. For example, if a customer 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 customer 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:

Alternate currency payments. If your organization accepts payments in alternate currencies, that is, a currency other than the account's currency; the cash back tender is always created in the account's currency.

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 service agreement 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.

Contents

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 service agreement to hold a credit. For example, if an account overpays their debt and the account doesn't have a single service agreement 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 service agreements linked to the payment's account. Note, this may occur when a customer is verbally asked to pay a connection fee or deposit prior to starting service, and for some reason, the appropriate service agreement has not been set up yet, or is still pending.

- For each such payment, it attempts to re-distribute the payment. If service agreements have been created in the meantime, this payment will distribute and freeze successfully.

Payment Financial Transaction Considerations

A payment segment exists for each service agreement that receives a portion of a payment. Linked to every frozen payment segment is a financial transaction. This financial transaction affects a service agreement'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.

Contents

Payment - Current Balance versus Payoff Balance

The Source Of GL Accounts On A Payment Financial Transaction

Payment - Current Balance versus Payoff Balance

Warning:

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 customer 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 customer was never billed 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 Customer Balances

The topics in this section provide information about obscure things that may happen when a payment is distributed and frozen.

Contents

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 customers who pay their bills automatically (via direct debit or credit card debits)

Contents

How To Set Up A Customer To Pay Automatically

What Are Automatic Payments?

How And When Are Automatic Payments Created?

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 Payments

Non-billed Budgets and Automatic Payment

Downloading Automatic Payments and Interfacing Them To The GL

ACH Record Layouts

How To Set Up A Customer To Pay Automatically

If a customer wants to pay automatically, transfer to Account - Auto Pay and define the source of the funds and the customer's account or credit card number.

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:

- The system creates automatic payments for bills linked to accounts with an active auto pay option (note, the system uses the account's autopay option that's effective on the bill's due date). When the system does this is dependent on the value of the Autopay Creation Option on the installation record:

- If you've set this option to Create At Bill Completion , the automatic payment is created when the account's bill is completed . The payment is distributed and frozen at the same time. This means that the account's balance is almost always zero (or in credit if they have a deposit). You will see the automatic payments in the payment list immediately after the bill is completed (rather than waiting until the automatic payment's extraction date).

- If you've set this option to Create On Extract Date , the automatic payment is NOT created when the bill is completed . Rather,

- 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.

- The automatic payment is NOT distributed and frozen when the automatic payment is initially created. A separate background process ( APAYDSFR) 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 customer'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 that it is possible for automatic payments to be distributed and frozen after being extracted and interfaced to a financial institution. Please refer to Downloading Automatic Payments and Interfacing Them To The GL and The Nightly Processes.

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. Please refer to APAM-DFLT for more information about how the algorithm that is supplied with the base package calculates this amount.

Note:

With balance forward accounting, automatic payments are not just for new charges. The base package algorithm includes prior balances when it creates a customer's first automatic payment. For example, if a customer 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.

- If a customer with a pay plan indicates that the payment method is via "autopay", a background process ( PPAPAY) creates an automatic payment on the scheduled payment dates. Please note, if the Autopay Creation Option on the installation record is set to Create On Extract Date , the automatic payment is NOT distributed and frozen when the automatic payment is initially created. Rather, a separate background process ( APAYDSFR) 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.

- If a customer with an account that is set up for automatic payment has a non-billed budget that is not excluded from automatic payment, a background process ( NBBAPAY) creates an automatic payment on the scheduled payment dates. Please note, if the Autopay Creation Option on the installation record is set to Create On Extract Date , the automatic payment is NOT distributed and frozen when the automatic payment is initially created. Rather, a separate background process ( APAYDSFR) 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 What is a Non-billed Budget for more information about non-billed budgets.

- 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. This would be a rather unusual thing to do, but you might do this if you want to immediately debit a customer's bank account after a large adjustment is added to the system (e.g., if they suddenly owe you a lot of money and you don't want to wait until the next bill to collect it). Automatic payments created by this method must be distributed and frozen before they can be extracted.

Note:

An algorithm is used to create automatic payments. The logic used to create automatic payments is plugged in on the Installation Record. Please note that this algorithm is not called when a user manually creates an automatic payment (by adding a payment tender with a tender type that indicates that it is for automatic payment purposes).

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.

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, customers 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 customer may want to prevent direct debits of more than $50 from being applied to their checking account.

You define a customer'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 customer who pays automatically the system calls the automatic payment creation algorithm that's plugged in on the Installation Record. The base-package autopay creation algorithm checks if the amount of the automatic payment exceeds the customer's maximum withdrawal amount. If so, the autopay creation algorithm calls the automatic payment over limit algorithm that's plugged in on the account's customer class. Algorithms of this type have the ability to reduce the amount of the autopay or to prevent the autopay 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 and non-billed budgets. Please note that automatic payments that are created as a result of pay plans and non-billed budgets are not subject to maximum withdrawal limits. This is because both of these options required customer approval and therefore the customer 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:

- 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).

- An operator can cancel an automatic payment (refer to How To Cancel A Tender) at any time. You would do this if the automatic payment was rejected by the financial institution.

Fastpath:

Refer to Credit / Correction Notes and Auto Pay for information about how a credit note may cancel an 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 customers). 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 Payments

If a customer 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 Customer To Pay Automatically). In addition, the payment method defined on the pay plan must indicate automatic payment is being used.

When this is done, a background process referred to as PPAPAY creates automatic payments on the scheduled payment date by calling the automatic payment creation algorithm plugged in on the installation record.

Non-billed Budgets and Automatic Payment

If a customer wants to pay their non-billed budget scheduled payments automatically, the account must be set up for automatic payment (as described under How To Set Up A Customer To Pay Automatically). In addition, the non-billed budget must indicate that automatic payment is being used.

When this is done, a background process referred to as NBBAPAY creates automatic payments on the scheduled payment date by calling the automatic payment creation algorithm plugged in on the installation record.

Downloading Automatic Payments and Interfacing Them To The GL

The following diagram illustrates the background processes that interface automatic payment out of the system:

These processes are described in the following topics.

Contents

ACTVTAPY - Activating Automatic Payments

APAYACH - Download Automatic Payments To The ACH (automated clearing house)

C1-APACH - Download Automatic Payments To The ACH (automated clearing house)

BALAPY - Creating Automatic Payment Tender Controls

ACTVTAPY - Activating Automatic Payments

When an automatic payment is first created, it gets marked with an extract date. The extract date is the date the automatic payment will be downloaded to the respective financial institution. The extract 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 calculates this date.

On the extract date, the automatic payment is "activated". The automatic payment is activated is marked for download the next time its download process runs. An automatic payment's download process is defined on its auto-pay source's route type.

APAYACH - Download Automatic Payments To The ACH (automated clearing house)

This process reads all auto pay download staging records marked with a given batch control ID & run number and creates the flat file that's passed to the ACH. Refer to ACH Record Layouts for the details of the record layouts.

Note:

This process may be rerun. You can reproduce the flat file at any time. Simply request this job and specify the run number associated with the historic run.

If you require a different flat file format, you must create additional versions of this program. Refer to Setting Up Automatic Payment Extracts for instructions describing how to add another process.

C1-APACH - Download Automatic Payments To The ACH (automated clearing house)

This process is an alternative to using APAYACH. Similar to APAYACH, this process reads all auto pay download staging records marked with a given batch control ID and run number and creates the flat file that's passed to the ACH. Refer to ACH Record Layouts for the details of the record layouts.

The following outlines the differences between APAYACH and C1-APACH:

- C1-APACH populates the Effective Entry Date field on the Company Batch Header Record with a date (the actual draft date) as to when the payment should be withdrawn from the customer's account. APAYACH uses the Business Process Date as the draft date.

- C1-APACH produces a file with multiple occurrences of the Company Batch Header Record differing on the Effective Entry Date field. APAYACH produces a file that has 1 File Header Record, 1 Company Batch Header Record and multiple detail lines.

Note:

This process may be rerun. You can reproduce the flat file at any time. Request this job and specify the run number associated with the historic run.

If you require a different flat file format, you must create additional versions of this program. Refer to Setting Up Automatic Payment Extracts for instructions describing how to add another process.

C1-SDDCE SEPA Direct Debit Payment Extract

This process reads all auto pay download staging records marked with a given batch control ID and run number to create an XML extract file that's passed to the financial institution. Refer to SEPA Direct Debit Record Layouts for the details of the record layouts.

Note:

This process may be rerun. You can reproduce the XML extract at any time. Simply request this job and specify the run number associated with the historic run.

BALAPY - Creating Automatic Payment Tender Controls

This process creates a new tender control (with an associated deposit control) for each unique batch control and run number encountered in the extracted automatic payments (where its payment tender is not yet linked to a tender control). The payment tender of each of these automatic payments is then linked to the corresponding tender control. This process also balances the open tender control records afterwards.

ACH Record Layouts

The topics in this section describe the layout of the records created by APAYACH - Download Automatic Payments To The ACH (automated clearing house) and C1-APACH - Download Automatic Payments To The ACH (automated clearing house).

Note:

APAYACH and C1-APACH share most of the same fields. The exceptions are documented in the following tables.

Contents

File Header Record

Company Batch Header Record

Entry Detail Record

Company Batch Control Record

File Control Record

File Header Record

The ACH extract flat file must have one record of this type and it must be the first logical record on file.

Field Name

Format

Source/Value/Description

RECORD-TYPE

A1

"1"

PRIORITY-CD

A2

"01"

RESERVED-01

A1

Spaces

IMMEDIATE-DESTINATION

A9

CI_BANK_ACCOUNT.DFI_ID_NUM

COMPANY-ID

A10

CI_BANK_ACCOUNT.ACCOUNT_NBR

FILE-CRE-DT

A6

YYMMDD. Current date

FILE-CRE-TM

A4

HHMM. Current time

FILE-ID-MODIFIER

A1

"A"

RECORD-SIZE-CONST

N3

"094" The "FILLER" at the end of all but the Entry Detail Record serves to bring the total length of each record up to this constant.

BLOCKING-FACTOR

N2

"10"

FORMAT-CD

A1

"1"

ORIG-FIN-INST-NAME

A23

CI_BANK_L.DESCR

COMPANY-NAME

A23

CI_BANK_ACCOUNT_L.DESCR

REFERENCE-CD

A8

Spaces

Company Batch Header Record

The ACH extract flat file must have one record of this type and it must be the second logical record on file.

Field Name

Format

Source/Value/Description

RECORD-TYPE

A1

"5"

SERVICE-CLASS-CD

A3

"200"

COMPANY-NAME

A16

CI_BANK_ACCOUNT_L.DESCR

COMPANY-DISCRETIONARY

A20

Spaces

COMPANY-ID

A10

CI_BANK_ACCOUNT.ACCOUNT_NBR

STD-ENTRY-CLASS

A3

"PPD"

CO-ENTRY-DESCR

A10

"PAYMENT"

EFF-ENTRY-DT

Note. This field applies only to C1-APACH.

A6

CI_APAY_CLR_STG.SCHED_EXTRACT_DT + NBR-DAYS batch parameter if specified greater than 0

COMPANY-DESCR-DT

A6

Business process date

EFF-ENTRY-DT

A6

Business process date

RESERVED-01

A3

Spaces

ORIGINATOR-STAT-CD

A1

"1"

ORIGIN-DFI-ID

A8

CI_BANK_ACCOUNT.DFI_ID_NUM

BATCH-NBR

N7

The batch number of this batch within the file.

Entry Detail Record

The ACH extract flat file must have one record of this type for every direct debit record.

Field Name

Format

Source/Value/Description

RECORD-TYPE

A1

"6"

TRANSACTION-CD

A2

CI_TENDER_TYPE.EXT_TYPE_FLG

TRANSIT-RTG-NBR

A9

CI_APAY_SRC.EXT_SOURCE_ID

DFI-ACCT-NBR

A17

CI_APAY_CLR_STG.EXT_ACCT_ID

AMOUNT

N8.2

CI_PAY_TNDR.TENDER_AMT

INDIVIDUAL-ID

A15

CI_PAY_TNDR.PAYOR_ACCT_ID

INDIVIDUAL-NAME

A22

CI_APAY_CLR_STG.ENTITY_NAME

DISCRETIONARY-DATA

A2

Spaces

ADDENDA-REC-IND

A1

"0"

DFI-ID

A8

CI_BANK_ACCOUNT.DFI_ID_NUM

ENTRY-DETAIL-CNT

N7

Ascending counter starting at 1 and incremented by 1 for each entry detail record

Note:

External Account ID. The EXT_ACCT_ID field supports up to 50 characters. If the value entered in the field is longer than that supported by the record layout (17 characters), the value will be truncated.

Company Batch Control Record

The ACH extract flat file must have one record of this type and it must follow the Entry Detail records.

Field Name

Format

Source/Value/Description

RECORD-TYPE

A1

"8"

SERVICE-CLASS-CD

A3

"200"

ENTRY-ADDENDA-CNT

N6

The total number of entry detail records in this batch.

ENTRY-HASH

N10

The product of the first 8 digits of the external source id of the autopay source, multiplied by the number of entry detail records in the batch.

TOTAL-DR-DOLLAR-AMT

N10.2

Total tender amounts of the entry detail records.

TOTAL-CR-DOLLAR-AMT

N10.2

Zero.

COMPANY-ID

A10

CI_BANK_ACCOUNT.ACCOUNT_NBR

RESERVED-01

A19

Spaces

RESERVED-02

A6

Spaces

ORIGIN-DFI-ID

A8

CI_BANK_ACCOUNT.DFI_ID_NUM

BATCH-NBR

N7

The batch number of this batch within the file.

File Control Record

The ACH extract flat file must have one record of this type and it must be the last logical record on file.

Field Name

Format

Source/Value/Description

RECORD-TYPE

A1

"9"

BATCH-CNT

N6

The number of batches in this file.

BLOCK-CNT

N6

Calculation of the total number of records in the file / 10.0 + 0.9

ENTRY-ADDENDA-CNT

N8

The total number of entry detail records in this file.

ENTRY-HASH

N10

The sum of the entry hash values on all the batch control records in this file.

TOTAL-DR-DOLLAR-AMT

N10.2

Sum of the total debit entry dollar amounts of all the batches in this file.

TOTAL-CR-DOLLAR-AMT

N10.2

Sum of the total credit entry dollar amounts of all the batches in this file.

RESERVED-01

A39

Spaces

SEPA Direct Debit Record Layouts

Contents

Group Header

Payment Information

Direct Debit Transaction Information

Group Header

A SEPA XML file must include a group header. The XML path for the group header is CstmrDrctDbtInitn/GrpHdr and the elements under the group header are as follows:

Description

Element Name

Source/Value

Message Identification

MsgId

Retrieved from the direct debit task type

Creation Date/Time

CreDtTm

Batch business date in the format YYYY-MM-DDThh:mm:ss

Number of Transactions

NbOfTxs

Calculated at extract time

Initiating Party Name

InitgPty/Nm

Retrieved from the direct debit task type

Payment Information

Payment Information contains elements related to the credit side of the transaction, such as creditor and payment type. The XML path for payment information is CstmrDrctDbtInitn/PmtInf and the elements are as follows:

Description

Element Name

Source/Value

Payment Information Identification

PmtInfId

Constructed at extract time by concatenating the following: Batch Code, Batch Run Number, Batch Business Date and a Sequence Number assigned to each Payment

Payment Method

PmtTpInf/PmtMtd

Defaulted to DD (Direct Debit)

Service Level Code

SvcLvl/Cd

Retrieved from the direct debit task type; defaulted to 'SEPA'

Local Instrument Code

PmtTpInf/LclInstrm/Cd

Retrieved from the direct debit task type; defaulted to 'CORE'

Sequence Type

PmtTpInf/SeqTp

Direct debit mandate task's Payment Type

Requested Collection Date

ReqdColltnDt

Payment event's pay date

Creditor Name

Cdtr/Nm

Direct debit mandate task's Creditor Name

Creditor Account Identification IBAN

CdtrAcct/Id/IBAN

CI_BANK_ACCOUNT.ACCOUNT_NBR

Creditor Agent Financial Institution Identification BIC

CdtrAgt/FinInstnId/BIC

CI_BANK_ACCOUNT.DFI_ID_NUM

Creditor Account Number

CdtrSchmeId/Id/PrvtId/Othr/Id

Direct debit task type's Creditor Identification

Creditor Party

CdtrSchmeId/Id/PrvtId/Othr/SchmeNm/Prtry

Defaulted to 'SEPA'

Direct Debit Transaction Information

Direct Debit Transaction Information contains elements related to the debit side of the transaction, such as debtor and remittance information rules. The XML path for direct debit transaction information is CstmrDrctDbtInitn/PmtInf/DrctDbtTxInf and the elements are as follows:

Description

Element Name

Source/Value

Payment End to End Identification

PmtId/EndToEndId

CI_PAY_TNDR.PAY_TENDER_ID

Payment Instructed Amount

InstdAmt

CI_PAY_TNDR.TENDER_AMT

Mandate Related Information – Mandate Identification

DrctDbtTx/MndtRltdInf/MndtId

Direct debit mandate task's External Mandate Reference

Mandate Related Information – Date of Signature

MndtRltdInf/DtOfSgntr

Direct debit mandate task's Effective Date

Mandate Related Information – Electronic Signature

MndtRltdInf/ElctrncSgntr

Direct debit mandate task's Signature

Debtor Agent Financial Institution Identification BIC

DbtrAgt/FinInstnId/BIC

CI_APAY_SRC.EXT_SOURCE_ID

Debtor Name

Dbtr/Nm

CI_APAY_CLR_STG.ENTITY_NAME

Debtor Account Identification IBAN

DbtrAcct/Id/IBAN

CI_APAY_CLR_STG.EXT_ACCT_ID

Issuing A Payment Advice Instead Of Creating An Automatic Payment

If the system is configured to send the customer 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 Advices for more information.

Contents

How To Set Up A Customer To Receive Payment Advices

Payment Advice Option Is For Bill-Related Automatic Payments Only

How To Set Up A Customer To Receive Payment Advices

Use Account - Auto Pay to capture the customer's bank details and indicate an auto pay method of Payment Advice .

Payment Advice Option Is For Bill-Related Automatic Payments Only

Payment advices 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 Auto Pay ( PPAPAY ) batch process will log an error in this case.

An auto pay for a non-billed budget scheduled payment will not be created if the account's effective auto pay option is set to Payment Advice . The Non-Billed Budget Pay Plan Auto Pay ( NBBAPAY ) 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.

Contents

Payment Lifecycles

Payment Event - Add Dialog

Payment Event - Main Information

Payment Event - Tenders

Payment Event - Characteristics

Payment Event Action Codes

Payment Lifecycles

The topics in this section describe the lifecycle of the various payment objects.

Contents

Payment Event Lifecycle

Tender Lifecycle

Payment Lifecycle

Payment Event Lifecycle

The following diagram shows the possible lifecycle of a payment event.

Warning:

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.

Warning:

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.

Warning:

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 service agreements.

- 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 customer class and to the service agreement's SA type.

- The payment's state becomes Frozen and the payment may now appear on a customer's bill.

You may not change a payment once it is frozen. However, you may reverse the payment's financial effect by clicking Cancel. 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 customer class.

- If the payment has a related adjustment, this adjustment is also cancelled. Refer to Loan Overpayments for an example of payments with adjustments.

- 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 Financial, Payment Event page in add mode from either the Account context menu or from the main 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 customer'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 customer (because the customer 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 Backamount if the customer 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 customer class. In this situation, specify a Match Type to define how the payment should be matched to the customer'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 customer wants to pay the latest bill.

- The customer wants to restrict the distribution of the payment to a specific service agreement. In this situation, specify a Match Type of "service agreement ID" and a Match Value of the respective service agreement ID.

The Payment Date defaults to the current date.

If the Payor Account ID's customer class is designated as non-CIS (i.e., the person making the payment isn't a customer), the following information appears in the above window:

- Non CIS 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 CIS Comments are used to describe anything unusual about the non-CIS 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 service agreements using standard distribution logic

- If this option is selected, the system distributes the Payment Amount amongst the account's service agreements. 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 service agreements. 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 service agreements. 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.

Note:

Cash only warning. If the account has exceeded your cash-only threshold and the Tender Type isn't marked as "like cash", a warning appears advising of such. Note, a customer's cash-only points are maintained on Account - Credit Rating.

Payment Event - Main Information

The Main page contains core payment event information. Open this page using Financial, Payment Event.

Fastpath:

The Description of Page section below 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

Note:

Cash-only customers. When you attempt to add a new payment event, the system warns you if the account remitting the tender is a cash-only customer and the tender's tender type is not cash. An account is considered cash-only if their current cash-only points exceed the cash-only tolerance maintained on the CIS Installation record. A customer's cash-only points are maintained on Account - Credit Rating.

Pay Event Info contains a concatenation of the payment date, amount, and the name of the main customer on the account that remits the tender. If multiple tenders exist, the customer'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. If document numbering has been enabled, the assigned document number will appear. If the payment was made in an alternate currency, the message Alternate Currency Used is displayed. Pay Event Info is only displayed after the payment event has been added to the database.

Refer to Alternate Currency Payments and Document Numbers for more information. 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 displays.

Payment Date is the business date associated with the payment event.

Warning:

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.

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 customer.

The system displays a Cash Back Amount if the customer 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 customer 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.

- Account ID references the payment's account. The name of the account's main customer 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 customer class. In this situation, specify a Match Type to define how the payment should be matched to the customer'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 customer wants to restrict the distribution of the payment to a specific service agreement. In this situation, specify a Match Type of "service agreement ID" and a Match Value of the respective service agreement ID.

- The remaining columns are only used if the payment is linked to an Account ID that belongs to a customer class that is used for non-CIS payments. Refer to Setting Up Customer Classes for more information. If such an account exists, the following fields must be defined.

- Non CIS 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 CIS Comments are used to describe anything unusual about the non-CIS payment.

- Note, you can also define a comment for a non-CIS 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 Financial, Payment Event, Tenders.

Fastpath:

The Description of Page section below 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 customer on the account that remits the tender. If multiple tenders exist, the customer'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. If document numbering has been enabled, the assigned document number will appear. If the payment was made in an alternate currency, the message Alternate Currency Used is displayed. 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 customer.

The system displays a Cash Back Amount if the customer 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 customer is displayed adjacent. If the account has exceeded your cash-only threshold, the warning Cash only appears.

Warning:

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. The amount is disabled if the payment was made in an alternate currency.

- 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.

Note:

Authorizing Tenders. The Tender Type dropdown list does not include tender types that require authorization (i.e. credit card payments).

Fastpath:

For information about tender types requiring authorization, refer to Credit Card Payments.

- If the payment tender was remitted in an alternate currency, i.e. a currency other than the payor account's currency, Alternate Currency and Exchange Rate will display the formatted alternate amount ((includes the alternate amount and currency) and the exchange rate that was in effect on the payment date.

Fastpath:

For information about accepting payments in alternate currencies, refer to Alternate Currency Payments.

- 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 customer'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. The Auto Pay Section contains the following fields:

- 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.

- External Account ID is the customer'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 customer'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 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 customer's account ID that appeared on the interfaced payment.

- Ext. Reference ID is the unique identifier of the payment upload interface record.

- Name is the customer'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 on the Tenders page 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 Indicate the value of the characteristic.

Payment Event - Characteristics

To update payment event characteristics, open Financial, Payment Event and navigate to the Characteristics tab.

Description of Page

The Characteristics collection contains information that describes miscellaneous information about the payment event.

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 Event Action Codes

The topics that follow describe each of the actions that appear on the payment event pages.

Contents

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.

Contents

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 that follow describe payment event-oriented actions. Refer to How To for a description of typical business processes that use these buttons.

Contents

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.

Contents

Transfer (No Distribution Details Exist)

Transfer (Distribution Details Exist)

T ransfer (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.

When clicked, the Payment Event Transfer dialog opens.

You must specify the following parameters in the Payment Event Transfer dialog 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 customer class or to restrict the distribution of the payment to a specific service agreement. 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 CIS Name, Reference Number, and Non CIS Comments appear if the Account ID belongs to a customer class that is used for non-CIS payments. Refer to Setting Up Customer Classes 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 payment characteristics associated with the original payment are copied to the new payment.

- The new payment is distributed.

- If so designated, the new payment is frozen.

T ransfer (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

When clicked, the Payment Event Transfer dialog opens.

You must specify the following parameters in this dialog to transfer payment(s):

- Distribution Rule is the account to which the payment event 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(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. The payment characteristics associated with the original payment are copied to the new payment.

- 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.

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.

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

When clicked, the Tender Cancel window opens.

You must specify the following parameters 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.

Cancellation after cash back. If a customer tenders a check for $100, but only owes $80, the system will recommend returning $20 in cash to the customer (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 Financial, 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 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.

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.

Note:

Cash-only customers. When you attempt to add a new payment event, the system warns you if the account remitting the tender is a cash-only customer. An account is considered cash-only if their current cash-only points exceed the cash-only tolerance maintained on the Installation record. A customer's cash-only points are maintained on Account - Credit Rating.

Contents

Multiple Payment Events Dialog

Single Payment Event Dialog

Multiple Payment Events Dialog

This section describes 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.

- Specify the Rule Value associated with the payment and expected by the distribution rule.

- 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 that the Tender Type defaults from the installation record.

Note:

Authorizing Tenders. The Tender Type dropdown list does not include tender types that require authorization (i.e. credit card payments).

Fastpath:

For information about tender types requiring authorization, refer to Credit Card Payments.

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 customer 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.

- MICR ID is the MICR ID associated with the tender.

- 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 section describes the default dialog setup 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 customer is displayed adjacent. If the account has exceeded your cash-only threshold, the warning Cash only appears.

Warning:

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 customer 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 customer'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 customer'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 customer'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 Payment 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 is not less than 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 Financial, 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.

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 customer 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.

Note:

Cash-only customers. You cannot use this transaction to add a payment for a "cash-only" account if the tender type is not "like cash". An account is considered cash-only if its cash-only points exceed the cash-only tolerance maintained on the Installation record. A customer's cash-only points are maintained on Account - Credit Rating. You must use the Payment Event transaction to add such a payment (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).

- 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.

Note:

Authorizing Tenders. The Tender Type dropdown list does not include tender types that require authorization (i.e. credit card payments).

Fastpath:

For information about tender types requiring authorization, refer to Credit Card Payments.

- 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 customer class. In this situation, specify a Match Type to define how the payment should be matched to the customer'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, we assume the customer wants to pay the latest bill.

- The customer wants to restrict the distribution of the payment to a specific service agreement. In this situation, specify a Match Type of "service agreement ID" and a Match Value of the respective service agreement 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 (e.g., the account is considered "cash-only" and a tender type other than cash is remitted, or if the account already has a payment for this amount on this date):

- 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 service agreements 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 service agreements).

- To override the distribution of a payment amongst its account's service agreements. Refer to Distributing A Payment Amongst An Account's Service Agreements for information describing how payments are typically distributed.

The topics in this section describe how to maintain a payment.

Contents

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 Financial, Payment, Main.

Warning:

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 service agreements.

Fastpath:

The Description of Page section below 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 customer 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 customer on the account that remits the event's tender. If multiple tenders exist, the customer'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 customer 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. If the account has exceeded your cash-only threshold, a warning (in red) appears adjacent to Payment Amount. Note, a customer's cash-only points are maintained on Account - Credit Rating.

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 customer class. In this situation, specify a Match Type to define how the payment should be matched to the customer'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 customer wants to restrict the distribution of the payment to a specific service agreement. In this situation, specify a Match Type of "service agreement ID" and a Match Value of the respective service agreement 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 a customer class that is used for non-CIS 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-CIS 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 defined which payment segments should be displayed). If 25 or fewer payment segments exist, the grid contains information about each payment segment:

- Premise is the address of the service agreement's main premise.

- SA Information contains basic information about the service agreement.

- Distributed Amt is the amount of the service agreement'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 customer'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 Financial, Payment, Payment Segments to view this information.

Warning:

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 SA 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 customer on the account that remits the event's tender. If multiple tenders exist, the customer'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 SA Filter to define the type of payment segments that should be retrieved.

Use the SA Filter to define the types of service agreements whose payment segments appear in the grid. The following options are available:

- Address. Use this option to restrict payment segments to those whose service agreements are linked to service points associated with a given Address, City and/or Postal code. Note, you can specify any combination of these fields.

- All. Use this option if you do not wish to restrict payment segments based on service agreement attributes.

- Geographic Type. Use this option to restrict payment segments to those whose service agreements are linked to service points associated with a given Geographic Type and Geographic Value.

- SA Type. Use this option to restrict payment segments to those whose service agreements are linked to a given CIS Division and SA Type.

Don't forget to click the search button after changing the SA Filter.

The grid that follows contains the payment segments that match your search criteria. The following information appears in the grid:

- The Premise column contains the characteristic premise associated with the payment segment's service agreement. Refer to Maintaining Premises for more information about this 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.

- SA Information contains summary information about the service agreement.

- Distributed Amt is the amount of the service agreement's debt relieved by the distribution.

- Adjustment ID is displayed if there is an adjustment associated with the payment. Refer to Loan Overpayments for an example of when an adjustment is associated with a 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 customer'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 service agreements linked to the payment's account and to manually distribute a payment amongst specific service agreements.

Open this page using Financial, Payment, Manual Distribution.

Warning:

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 service agreements.

Note:

If the payment's account has more than 25 service agreements, the search criteria are intentionally left blank in order to avoid retrieving all service agreements (with the resultant slow response times). You must therefore use the SA Filter to define the type of service agreements 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 service agreements, the search criteria are intentionally left blank in order to avoid retrieving all service agreements (with the resultant slow response times). You must therefore use the SA Filter to define the type of service agreements that should be retrieved.

Use the SA Filter to define the types of service agreements that appear in the grid. The following options are available:

- Address. Use this option to restrict service agreements to those linked to service points associated with a given Address, City and/or Postal code. Note, you can specify any combination of these fields.

- All. Use this option if you want to view all service agreements.

- Geographic Type. Use this option to restrict service agreements to those linked to service points associated with a given Geographic Type and Geographic Value.

- SA Type. Use this option to restrict service agreements to those linked to a given CIS Division and SA Type.

Don't forget to click the search button after changing the SA Filter.

The grid that follows contains the service agreements that match your search criteria. The following information appears in the grid:

- Premise contains the characteristic premise associated with the service agreement.

- SA Information contains summary information about the service agreement.

- Distributed Amt is the amount of the service agreement'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 service agreement 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 service agreement.

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 service agreement. 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.

that an implementation can override the type of grid displayed for open item accounts by setting up a Financial Transaction Options Feature Configuration with an Always Use Manual Payment Distribution By SA option set to Y . With this in place, the system will always display the manual distribution by service agreement grid.

The open item manual distribution grid contains 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 SA or an excess credit SA.

- Row is a pay segment of a balance forward payment distribution.

- Premise Information contains the characteristic premise associated with the service agreement.

- SA Information contains summary information about the service agreement.

- 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 service agreement 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 customer'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 Financial, 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.

Contents

Distribute (A Payment)

Redistribute (A Payment)

Confirm (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 service agreements. Refer to Distributing A Payment Amongst An Account's Service Agreements 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 service agreements. Refer to Distributing A Payment Amongst An Account's Service Agreements 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.

Confirm (A Payment)

Clicking the Confirm button confirms that manually entered amounts associated to certain SAs will relieve their balances. This is the same process that is triggered by clicking Save.

This button is enabled if a value is manually entered in a Distributed Amount field.

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.

Contents

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 the Payment Transfer window 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 customer class or to restrict the distribution of the payment to a specific service agreement. 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 CIS Name, Reference Number, and Non CIS Comments appear if the Account ID belongs to a customer class that is used for non-CIS payments. Refer to Setting Up Customer Classes 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 characteristics associated with the original payment are copied to the new payment.

- The payment is distributed amongst the new account's service agreements.

- If so designated, the new payment is frozen.

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 SA. Each of the incorrectly directed payments can be transferred to the correct SA(s) using the Transfer via Distribution Rules 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 service agreement 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 service agreement(s). The payment characteristics associated with the original payment are copied to the new payment.

- 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.

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 .

Payment Portal

The base package is shipped with a configured payment portal that can be used for payment processing. The portal supports the following functionality that is not supported in the base Payment Event - Add Dialog:

- Processing of payments that require authorization (i.e. credit card payments)

- Creating non CIS payments based on payment templates

- Processing payment tenders in alternate currencies

Fastpath:

Refer to The Big Picture of Portals and Zones in the Oracle Utilities Application Framework Administration Guide for a description of portal and zone functionality.

Contents

Credit Card Payments

Non CIS Payments

Alternate Currency Payments

Credit Card Payments

The payment portal provides the functionality needed for posting and authorizing customers' credit card charges in real-time. If the credit card authorization is successful, the payment will be added automatically (assuming you selected the appropriate payment freeze action via the portal).

Fastpath:

Refer to How To for instructions describing how to add a payment that requires authorization.

Non CIS Payments

The payment portal allows you to add non-CIS payments using a payment template. Payment Templates can be configured for common types of payment allocations to pre-populate the payment distribution, allowing non-CIS payments to be directly allocated against the appropriate distribution codes.

Fastpath:

Refer to How To for instructions describing how to add a non-CIS payment using a payment template.

Alternate Currency Payments

The payment portal allows you to process a payment tender remitted in an alternate currency. The system enables conversion of the tendered amount into the account's currency.

Fastpath:

Refer to How To for instructions describing how to process a payment in an alternate currency.

How To

The topics in this section describe how to perform common payment maintenance functions.

Contents

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 Service Agreement

How To Get An Unbalanced Tender Control In Balance (Fixing Over/Under)

How To Add A Non-CIS Payment Using A Template

How To Authorize A Credit Card Tender

How To Reverse A Credit Card Tender

How To Process An Alternate Currency Payment

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 service agreements 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 customers 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.

On on the payment event Main page, do the following:

- If the remitting account shouldn't have received any part of the payment, Remove it from the payments grid 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 payments grid (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 Quick Add and Payment Event Quick Add transactions. Refer to those sections for more information.

The print dialog functions are described below.

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. The following steps explain how to do this.

Warning:

These steps only make 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 Cancel. Proceed to step 3.

3. Before the system cancels the tender, you must specify the cancel reason. The tender cancel window opens.

In the tender cancel window, 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 SA Type - Main Information for more information.

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.

Cancellation after cash back. If a customer tenders a check for $100, but only owes $80, the system will recommend returning $20 in cash to the customer (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 Service Agreement

When you click Distribute, the system uses the payment distribution algorithm defined on the account's customer class to allocate the payment amongst the account's service agreements. In this section, we describe how to override this distribution (e.g., when you need to allocate a payment to specific service agreement(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 service agreement 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 a service agreement whose SA 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 and the tender type configured for cash drawer over/under amounts. This will cause cash to be debited by the over amount, and the expense account associated with the account's service agreement 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 and the tender type configured for cash drawer over/under amounts. This will cause cash to be credited by the over amount, and the expense account associated with the account's service agreement to be debited.

Important:

A separate tender type is used for recording cash drawer over/under amounts. Once the over/under amount has been determined, you must enter a new tender using your over/under tender type for the company-use account. 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

Over/Under

-

$-0.50

-

-

$-0.50

Over $0.50

In this example, you'd have to create a new tender for the company-use account for the amount that will be distributed to the company-use account's service agreement (debit over/under expense, credit cash):

- Tender type: Over/Under, Tender amount: -$0.50

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).

How To Add A Non-CIS Payment Using A Template

The payment portal allows you to add non-CIS payments using a payment template. Payment Templates can be configured for common types of payment allocations to pre-populate the payment distribution and allowing non-CIS payments to be directly allocated against distribution codes. The following steps explain how to do this.

You navigate through the pages as follows:

- From the main menu open Financial, Payment Portal.

- The Add Non CIS Payment Zone shows a list of all active payment templates. Use the Add button to add a non-CIS payment for a specific payment template.

- Enter the payment and tender details ( Payment Amount, Payment Date defaults to the current date, Tender Source is used to find an open tender control when adding the tender).

Note:

Authorizing Tenders. If the Tender Type selected requires authorization (i.e. credit card payments), additional authorization details are required (e.g. credit card type, credit card number, etc.). Only one tender that requires authorization can exist for a single payment event.

Fastpath:

For information about tender types requiring authorization, refer to How To Authorize A Credit Card Tender.

- Enter the non-CIS information for the customer remitting the payment ( Customer Name, Agreement Number and Comments to describe anything unusual about the non CIS payment).

Note:

Payor Account ID. The Non CIS Account Id specified on the payment template is used as the tendering account. If the account has exceeded your cash-only threshold and the Tender Type isn't marked as "like cash", a warning appears advising of such.

Including a CIS payment. If a portion of the tender is for a CIS payment, ensure that the Add CIS Payment checkbox is selected. The system will process the non-CIS payment, and then navigate the user to the Payment Event page where the CIS payment can be included.

- The distribution details are defaulted from the payment template but may be overridden. You can add additional distribution lines. Enter the payment amount and Reference Number for each applicable distribution line.

- When you click the OK button, the system creates the payment event and tender(s). A single payment is created for each non-zero amount entry in the distribution details list. The payment template is captured as a characteristic on the tender. The corresponding distribution code, GL account and reference number are captured as characteristics on each payment. When the financial transactions are created for these payments, the distribution code (and GL account) is retrieved from the payment characteristic collection.

How To Authorize A Credit Card Tender

You can use the Payment Portal to add a payment event for a tender that requires authorization. The following steps explain how to do this.

If your organization is using the base tender authorization functionality, you can navigate through the pages as follows:

- From the main menu open Financial, Payment Portal.

- The Add CIS Payment Z one only expands if there's an account in context. To expand this zone, either search for an account using Control Central or use the Tender Search available on the Payment Portal.

- Use the Add Payment button to add a payment for the account displayed in the zone.

- The information displayed is the same as that on the Payment Event - Add Dialog, except for the following:

- Use Distribute Action to describe what you'd like to have happen when you click the OK button. The dropdown contains the following values - Distribute and Freeze if OK , Manual Distribution and Manual Distribution - Multiple Payments

Note:

The Distribute and Freeze if OK and Manual Distribution options are also present on the Distribute Action on the payment event add dialog screen. The third option, Manual Distribution - Multiple Payments, is special for credit card authorization processing. This option is similar to the Manual Distribution option except that the user is navigated to the Payment Event maintenance page after authorization has taken place.

- If the Tender Type selected requires authorization (e.g., credit card payments), additional authorization details are required (e.g. credit card type, credit card number, etc.). This information is displayed in the Credit Card Information section.

Note:

Authorizing Tenders. Only one tender that requires authorization can exist for a single payment event.

- The Authorization Override checkbox is only displayed if the tender type selected requires authorization. Use the Authorization Override checkbox to indicate whether or not tender authorization should take place. If Authorization Override is checked, an authorization code must be entered and the system bypasses the authorization web service call.

- Click OK to save the payment and navigate to the appropriate page .

- Assuming the credit card is accepted, the authorization code returned by the credit card authorization provider is captured as a tender characteristic.

- If the credit card is declined, the tender will not be added.

How To Reverse A Credit Card Tender

The steps required to reverse a credit card tender are the same as the steps for How To Cancel A Tender.

The reversal code from the credit card authorization service is stored as a tender characteristic.

Fastpath:

For more information on authorizing credit card payments, refer to the following business objects: Tender Type - Credit Card with Authorization , CyberSource - Credit Card Authorization and CyberSource - Credit Card Reversal .

How To Process An Alternate Currency Payment

You can use the Payment Portal to add a payment event for a tender(s) in an alternate currency, i.e. a currency that differs from the account's currency. The following steps explain how to do this.

- From the main menu open Financial, Payment Portal.

- The Add CIS Payment Z one only expands if there's an account in context. To expand this zone, either search for an account using Control Central or use the Tender Search available on the Payment Portal.

- Use the Add Payment button to add a payment for the account displayed in the zone.

- The information displayed is the same as that on the Payment Event - Add Dialog, except for the following:

- • If your organization accepts payment tenders in alternate currencies, the Currency Converter button appears in the tender list

- Use the Currency Converterbutton to enter the Tendered Amount and Tendered Currency in the alternate currency and click OK. The system will convert the alternate currency amount to the account's currency.

- Click OK to save the payment and navigate to the appropriate page .

- When you click the OK button, the system creates the payment event and tender(s). Each tender is linked to an appropriate tender control based on the currency of the tender.

Fastpath:

Refer to Alternate Currency Payments for more information.

Financial Transactions On A Payment

Open Financial Query, 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 ID provides you with options that control which financial transactions appear in the grid. The following points describe the various options:

- Use the SA Filter to define the types of service agreements whose financial transactions appear in the grid. The following options are available:

- Address. Use this option to restrict financial transactions to those whose service agreements are linked to service points associated with a given Address, City and/or Postal code.

- All. Use this option if you do not wish to restrict financial transactions based on service agreement attributes.

- Geographic Type. Use this option to restrict financial transactions to those whose service agreements are linked to service points associated with a given Geo Type and Value.

- SA ID . Use this option to restrict financial transactions to those of a specific service agreement.

- SA Type. Use this option to restrict financial transactions to those whose service agreements are linked to a given CIS Division and SA Type.

- 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 customer. 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.

Warning:

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 customer.

- 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 service agreement's current balance.

- Payoff Amount contains the financial transaction's effect on the service agreement'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 customer's bill.

- SA Information contains a summary of the respective service agreement.

- 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 service agreements. Open this page using Financial Query, Account Payment History.

Description of Page

One row is displayed for every payment that has been distributed to an account's service agreements. 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 History

The Payment Tender History page shows a list of all tenders linked to an open tender control for the current user. Open this page using Financial Query, Payment Tender History.

Description of Page

One row is displayed for every tender that is linked to an open tender control to which the current user has access. The freeze date/time, payor account id, name, tender amount, tender type, pay tender id, tender status and payment date are displayed for each tender.

Payment / Tender Search

This page allows you to look for payments and/or tenders using a combination of search criteria. Open this page using 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 customers named Brandon whose amount is between 150 and 170 will be displayed.

Warning:

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 customer'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.

Note. 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.

Warning:

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 Source This contains the source of the tender of the tender. 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.

Contents

The Lifecycle Of A Deposit Control

Deposit Control - Main

Deposit Control - Tender Control

Deposit Control - Tender Deposit

Deposit Control - Turn Ins

Deposit Control - Characteristics

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 Financial, Deposit Control and then navigate to the Main 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.

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 minus the deposit tender amount. 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 .

Fastpath:

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 Financial, Deposit Control, Tender 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.

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 Financial, 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 Financial, Deposit Control 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.

Deposit Control - Characteristics

To update deposit control characteristics, open Financial, Deposit Control and navigate to the Characteristics 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 Characteristics collection contains information that describes miscellaneous information about the deposit control.

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.

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.

Contents

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 Financial, 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 Balances equals the sum of all Expected Ending Balances.

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.

- Nbr 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.

- Total Tenders 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 Balanceplus Total Tenders 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 Financial, Tender Control, Tenders.

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 Financial, 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 Financial, 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 Financial, 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 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 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.

Contents

Interfacing Payments

Interfacing Payments Using Distribution Rules

Interfacing Payments

The topics in this section describe how the payment interface using the system default method of creating payment events works.

Contents

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.

Contents

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.

Contents

Deposit Control Staging

Tender Control Staging

Payment Tender Staging

Payment Advice Staging

D eposit 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.

T ender 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.

P ayment 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 customer 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 SA 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 customer name on the payment.

CHECK_NBR

10

N

A/N

This is the check number on the payment.

P ayment 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 service agreement, you must insert a row on this table to indicate the specific the service agreement in question. You do this by populating MATCH_TYPE_CD with a value that indicates that you are paying for a specific service agreement and MATCH_VALUE with the unique ID of the service agreement.

- 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 customer 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 customer 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 SA 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 service agreement), MATCH_VALUE contains the ID of the restriction (e.g., the SA 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.

Contents

Phase 1 - Create Deposit Control

Phase 2 - Create Tender Control

Phase 3 - Create Payment Events, Tenders, Payments and Payment Segments

P hase 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

P hase 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:

that 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 SA'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 service agreements, and payment segments are created. Note, the payment could be in error if there are no SA'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.

Note: Balancing Control Tables. The balancing of the deposit and tender control tables during payment upload can either be done by PUPL, or after PUPL successfully completes. The latter might be useful for high volume payment uploads that could result in deadlocks on these control tables. If your implementation wishes to execute control table balancing after PUPL completes, ensure that the necessary batch parameter is set to exclude balancing when PUPL runs and also that the separate balancing batch process (C1-PUBAL) is scheduled after PUPL.

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.

Contents

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 Financial, 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 Financial, Deposit Control Staging, Tender Control Staging.

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.

Contents

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 Financial, Payment Upload Staging, Tender Detail.

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.

Ext. 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 customer 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 SA 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.

Note:

Authorizing Tenders. The Tender Type dropdown list does not include tender types that require authorization (i.e. credit card payments).

Fastpath:

For information about tender types requiring authorization, refer to Credit Card Payments.

MICR ID is the MICR ID associated with the tender.

Check Number is the check number on the payment.

Name is the customer'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 customers other than that defined on the Tender Detail page, the customers 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 customer.

Fastpath:

Refer to Populating The Payment Upload Staging Records for more information about this record.

Open this page using Financial, Payment Upload Staging, Payment Advice.

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 customer(s) other than the tendering customer. The following information is displayed.

Customer ID This is the account ID or the old account number of the customer 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 customer class of the account are displayed here.

Payment Amount This is the amount of the tender to be distributed to the customer.

Match Type and 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 service agreement), Match Value indicates the ID of the restriction (e.g., the service agreement ID). Valid values of Match Type are Service Agreement .

Payment Upload Staging- Characteristics

Select Financial > Payment Upload Staging and navigate to the Characteristics tab to define characteristic values for the payment tender staging record.

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.

Ext. Reference ID is the external source's unique identifier of the payment tender.

Use the characteristics grid to capture additional information about the payment tender staging record.

- Use Payment Characteristics Entity to define where each characteristic will be populated on upload. Valid values are: Payment, Payment Event or Payment Tender

- Select a Characteristic Type for each payment characteristic entity. You can only choose Characteristic Types defined as permissible for the applicable entity. 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.

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.

Interfacing Payments Using Distribution Rules

The topics in this section describe how the payment interface using distribution rules works.

Contents

Populating The Payment Event Upload Staging Records

Payment Event Upload Staging

Populating The Payment Event Upload Staging Records

The following diagram illustrates the processes involved in the uploading of payment event distribution details into the system.

The topics in this section describe each background process referenced above.

Contents

Process X - Populate Payment Event Upload Staging

Data Setup Examples of Payment Distribution Details

The Lifecycle of a Payment Event Upload Staging Record

To Do Entries Instead of Exception Records

Process C1-PEPL1 - Upload Payments (Step 1)

Process C1-PEPL2 - Upload Payments (Step 2)

Process C1-PEPL3 - Upload Payments (Step 3)

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.

P ayment 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 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.

PEVT_DTL_SEQ

12

Y

N

Unique identifier of the detail record within the transmission. The C1-PEPL1 process uses this field to organize the parallel threads.

PEVT_STG_ST_FLG

4

Y

A/N

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.

DST_RULE_VALUE

254

Y

A/N

This must be a valid value for the characteristic type defined on the distribution rule.

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 customer information.

NAME1

30

N

A/N

This field may be used to capture additional payment tender information.

EXT_REFERENCE_ID

30

N

A/N

This field may be used to capture external information associated with the payment tender.

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 service agreement), MATCH_VALUE contains the ID of the restriction (e.g., the SA ID).

If MATCH_TYPE_CD is specified, it must reference a valid Match Type.

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. If left blank, 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-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 customer'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 customer's name in the financial institution's system

Data Setup Examples of Payment Distribution Details

Typically, each staging record will represent a single payment event - with a corresponding payment tender and payment. However, it is possible to specify complex relationships within a set of staging records. For example, it will be straightforward to define a set of staging records that represent a single tender but multiple payments (to model the single payment tender of a welfare agency which covers payments for multiple accounts). Similarly, it is equally possible to define a set of staging records that represent a single payment but multiple tenders (although not a common requirement).

Each staging record can represent:

- Zero or one new payment events. Typically, each detail staging record will represent a single payment event. However, it is possible to define multiple records for a single payment event. All details for a single payment event are identified by a common value on the staging record: Pay Event Process ID.

Note:

Pay Event Process 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.

- A partial or one new payment tenders. Typically, each detail staging record will represent a single payment tender. However, it is possible to define multiple staging records for a single pay tender. All details for a single tender are identified by a common payment event ID as well as common tender information (tender type, tender account ID, check number, external reference, etc.).

- A partial or many new payments. Typically, each detail staging record will represent a set of one or many new payments. However, it is possible to define multiple staging records for a single payment. All details for a single payment are identified by a common payment event ID as well as common distribution rule and characteristic value information.

The sections below provide examples of a few of these complex payment event configurations. Note that these examples assume the same distribution rule is referenced in all staging records.

Contents

Staging Entry Example 1: One Payment Event, Two Tenders, Two Payments

Staging Entry Example 2: One Payment Event, One Tender, Two Payments

Staging Entry Example 3: One Payment Event, Two Tenders, One Payment

S taging Entry Example 1: One Payment Event, Two Tenders, Two Payments

Seq.

Pay Event Process ID

Tender Account ID

Tender Ref.

Date

Rule Value

Amount

Tender Type

Check No

1

1234567890

1234567890

112A

1/1/2006

113-54-8978

30.00

Check

101

2

1234567890

1234567890

112B

1/1/2006

575-40-3030

40.00

Check

102

S taging Entry Example 2: One Payment Event, One Tender, Two Payments

Seq.

Pay Event Process ID

Tender Account ID

Tender Ref.

Date

Rule Value

Amount

Tender Type

Check No

1

1234567890

1234567890

112A

1/1/2006

113-54-8978

30.00

Check

101

2

1234567890

1234567890

112A

1/1/2006

575-40-3030

40.00

Check

101

S taging Entry Example 3: One Payment Event, Two Tenders, One Payment

Seq.

Pay Event Process ID

Tender Account ID

Tender Ref.

Date

Rule Value

Amount

Tender Type

Check No

1

1234567890

1234567890

112A

1/1/2006

575-40-3030

30.00

Check

101

2

1234567890

7878787870

888Q

1/1/2006

575-40-3030

40.00

Check

9872

The Lifecycle of a Payment Event Upload Staging Record

The following diagram shows the possible lifecycle of a payment event upload staging record.

- Incomplete . A payment event staging record is initially created in incomplete state. The C1-PEPL1 process sets it to pending once it links it to a tender control and determines its tender account.

- 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.

Fastpath:

Refer to To Do Entries Instead of Exceptions for more information on how To Do entries are used to capture processing errors.

To Do Entries Instead of Exception Records

Instead of creating an exception record for staging records in 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.

Process C1-PEPL1 - Upload Payments (Step 1)

The batch process C1-PEPL1 refers to the first of three 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. 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 Tender Account ID field is populated. The Determine Tender Account algorithm defined on the distribution rule is called and the returned account ID is posted on the staging record.

- The Pay Event Process ID field is populated. If 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.

Contents

Phase 1 - Create Tender Control

Phase 2 - Determine Tender Account

P hase 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 To Do 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.

Note:

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, a 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.

P hase 2 - Determine Tender Account

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.

- Execute the Determine Tender Account algorithm defined on the distribution rule and populate the record with the returned account ID. Note that the algorithm is called even when the tender account is populated to provide for a potential override of the initial value when necessary. 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 set the record to Error and create a To Do entry for the error message.

- If no error occurred, a 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 2)

The batch process C1-PEPL2 refers to the second of three 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.

- The staging record is moved to the complete 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 .

Note:

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, a 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 3)

The batch process C1-PEPL3 refers to the last of three 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.

Payment Event Upload Staging

The Payment Event Upload Staging 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 uploaded by the payment event upload processes.

The topics in this section describe this page.

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 Financial, Payment Upload Staging, Tender Detail.

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 Transmission 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-PEPL1 process uses 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.

Match Type and Match Value 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 service agreement), Match Value indicates the ID of the restriction (e.g., the service agreement ID).

Payor Account ID is the tender account. If not populated the C1-PEPL1 process populates 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 or remittance (e.g., cash, check, etc.). Note that the Tender Type defaults from the installation record.

Note:

Authorizing Tenders. The Tender Type dropdown list does not include tender types that require authorization (i.e. credit card payments).

Fastpath:

For information about tender types requiring authorization, refer to Credit Card Payments.

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 customer information.

Name may be used to record additional payment tender information.

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 Auto Pay section displays. 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 customer'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 customer'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 customer's name in the financial institution's system.

Pay Event Process ID is used to group multiple staging records into a single payment event. If not populated, the C1-PEPL1 process sets this field equal to the Payor Account ID.

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.

Adjustments

In this section, we describe when and how to adjust a service agreement's balance.

Contents

The Big Picture Of Adjustments

Maintaining Adjustments

How and When To Use An Adjustment

Interfacing Adjustments From External Sources

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.

Contents

Adjustments - Current Balance versus Payoff Balance

Canceling Adjustments

Transfer Adjustments

Calculated Adjustments

Adjustment Amount May Be Positive, Negative Or Zero

Adjustment Type Controls Everything

Unbilled Adjustments And Aged Debt

An Adjustment May Affect More Than Just Customer Balances

Adjustments - Current Balance versus Payoff Balance

Adjusting how much a customer owes involves changing a service agreement's payoff balance and/or current balance by creating an adjustment. In this section we describe these two balances.

Warning:

If you do not understand the difference between payoff balance and current balance, refer to Current Amount versus Payoff Amount.

Contents

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 service agreements, payoff balance and current balance are always the same (or in colloquial speech - the amount the customer thinks they owe 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-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

27-Apr-99

Adj: Late Payment Charge $10

285

285

As you can see, payoff balance and current balance are always in sync.

When Current Balance Differs From Payoff Balance

For some service agreements, payoff balance and current balance differ (or in colloquial speech - the amount the customer thinks they owe differs from what they would owe if they wanted to payoff their account).

Let's run through an example of a customer on a budget to illustrate a classic service agreement where these two balances are not the same. The values in the payoff balance and current balance columns reflect the amount due after the financial transaction has been applied:

Date

Financial Transaction

Payoff Balance

Current Balance

1-Jan-99

Bill: $125, Budget $150

125

150

15-Jan-99

Payment: $150

-25

0

2-Feb-99

Bill: $175, Budget $150

150

150

14-Feb-99

Payment: $150

0

0

3-Mar-99

Bill: $200, Budget $150

200

150

15-Mar-99

Payment: $150

50

0

2-Apr-99

Adj: Mar 3, 97 bill incorrect due to meter exchange discrepancies; manual correction of -$33.

17

0

Notice the adjustment of -$33 affects only payoff amount. This is because the customer is on a budget. The adjustment will not affect their monthly payment and therefore it doesn't affect how much they think they owe.

The following table describes the various types of service agreements where these balances may differ.

Type Of Service Agreement

What Payoff Balance Holds

What Current Balance Holds

Deposit

Payoff balance holds the amount of deposit you are holding on behalf of the customer's debt. This amount is showed as a credit (with a negative sign) because you truly owe the customer this money.

Current balance holds the amount the customer owes for a deposit.

Charitable contribution

N/A - charitable contribution service agreements never have a payoff balance.

Current balance holds the amount the customer owes for a charitable contribution.

Payment arrangements

Payoff balance holds the total amount of delinquent debt that remains unpaid. When a payment arrangement is started, you transfer the payoff balance from the utility service agreement to the payment arrangement service agreement. Each billing period, the customer pays down this balance.

Current balance holds the amount the customer owes in respect of the billed payment arrangement amounts.

Utility agreements on a budget plan

Payoff balance holds the actual amount owed (actual bills minus payments).

Current balance holds the amount the customer owes in respect of the billed budget amount.

Loans

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 customer 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 service agreement. For example, if your organization doesn't allow budget billing, all adjustments for a utility service agreement will affect payoff balance and current balance the same (you can't get the balances out-of-sync).

The various types of adjustments that may be linked to a service agreement are controlled by the adjustment profiles defined on the service agreement's SA type.

Fastpath:

Refer to Adjustment Type Controls Everything for more information.

Canceling Adjustments

You may cancel any frozen adjustment. Canceling the adjustment creates another financial transaction that reverses the financial effects of the original adjustment. The impact of the cancellation appears on the customer'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 service agreements. 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).

Calculated Adjustments

An adjustment can calculate the adjustment amount using an algorithm. A calculated adjustment can be used to calculate:

- Sales or other taxes for a base amount

- Any charge amount based on a user-supplied quantity, such as feet, miles, hours, etc.

- Others.... Any calculation that can be made by a rate can be applied to an adjustment.

When you create a calculated adjustment, you may be asked to supply a base amount. The user may supply the base amount or the amount could be defaulted from the adjustment type and possibly overridden by the user prior to calculating the adjustment amount.

When the adjustment is generated, the calculation algorithm may use the base amount and calculation date. The base package algorithm calls the rate application and returns the calculated amount with calculation lines and GL distribution codes.

An adjustment's adjustment type controls whether the adjustment is calculated and the algorithm that performs the calculation.

Fastpath:

For more information, refer to Adjustment Type Controls Everything and Setting Up Calculated Adjustment Types.

Adjustment Amount May Be Positive, Negative Or Zero

An adjustment's amount may be positive, negative or zero:

- A positive amount causes the customer's balance(s) to increase.

- A negative amount causes the customer's balance(s) to decrease.

- A zero amount will not affect the customer'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.

Adjustment Type Controls Everything

When you create an adjustment, you must define its adjustment type. The topics in this section describe how adjustment type controls the behavior of an adjustment.

Contents

Controls Which Balance(s) Are Affected

Defines The GL Account Affected By The Adjustment

Defaults The Adjustment Amount

Calculates The Adjustment Amount

Controls The Interface To A/P & 1099 Reporting

Controls Information Printed On The Bill

Controls If The Adjustment Can Be Frozen Prior To Bill Completion

Controls If The Adjustment Requires Approval

Controls Which Balance(s) Are Affected

The adjustment type's financial transaction (FT) algorithm controls how payoff balance and current balance are affected by the adjustment amount.

Defines The GL Account Affected By The Adjustment

Most adjustments affect the general ledger (GL) in some way. The following points describe the source of these GL accounts.

- For normal adjustments (i.e., non-calculated adjustments that affect a single service agreement), there is a single accounting entry generated:

- One side of the accounting entry is taken from the distribution code on the SA type of the service agreement affected by the adjustment. For example, if you are adjusting the payoff balance on a normal service agreement, the A/R account is constructed from the distribution code on the service agreement's SA type.

- The other side of the accounting entry is taken from the distribution code on the adjustment's adjustment type. For example, if a late payment charge is created, the "late payment charge" adjustment type references this fee's revenue account.

- For transfer adjustments (i.e., adjustments used to transfer moneys between two service agreements), there are two accounting entries generated - one for the "from" side and one for the "to" side. Each adjustment carries its own set of balanced GL accounting details.

- For each adjustment, one side of the entry is taken from the distribution code on the SA type of the service agreement affected by the adjustment (just like for normal adjustments).

- The other sides of both accounting entries have the same GL account. This account should be the intermediate clearing GL account that is to be used for the transfer. The source of this clearing GL account is the distribution code on the adjustment type used to transfer the funds.

- For calculated adjustments (i.e., adjustments where rates may be applied to calculate the adjustment amount), there is a single accounting entry:

- For each adjustment, one side of the entry is taken from the distribution code on the SA type of the service agreement affected by the adjustment (just like for normal adjustments).

- The other side of the entry is taken from the distribution codes that resulted from the rate calculation if the adjustment financial transaction algorithm is set up to use the calculation lines as the distribution code source. If the adjustment financial transaction algorithm is set up to use the adjustment type as the distribution code source, the other side of the accounting entry is taken from the distribution code on the adjustment type.

Note:

Not all adjustments affect the GL. As a general rule of thumb, only those adjustments that affect a service agreement's payoff balance affect the GL. So, if you adjust a budget customer's current balance, but don't adjust their payoff balance, the GL is not affected.

Defaults The Adjustment Amount

The adjustment type may default the adjustment amount in one of the following ways:

- The adjustment type may specify a default amount. This would be used for those adjustment types that have a standard charge for all customers that receive this adjustment, for example a non-sufficient funds charge.

- The adjustment type may specify a default adjustment amount algorithm. This would be used for those adjustment types that have a charge that varies based on other factors. For example, a non-sufficient funds charge may be based on a customer's credit rating.

When an amount is defaulted onto a new adjustment it may be overridden by a user.

Calculates The Adjustment Amount

Some adjustment types calculate the adjustment amount. If the adjustment type uses a calculated amount, a base amount is passed to the rate application, which then returns the calculated amount with calculation lines and GL distribution codes.

The adjustment type's generate adjustment algorithm controls which rate is applied to the base amount. A user supplied calculation date controls which version of the rate is used. The user may supply the base amount or it may be defaulted from the adjustment type and possibly overridden by the user prior to calculating the adjustment amount.

Controls The Interface To A/P & 1099 Reporting

If the adjustment type is associated with a payment (e.g. a refund or a loan disbursement) of money to a customer, the adjustment type indicates such with a reference to an A/P request type.

When an adjustment that references an A/P request type is frozen , an A/P download request record is created. This record is the interface request to ask your A/P system to cut a check. This interface record is marked with a batch process ID and run number.

- The batch process ID is the process responsible for creating the flat file that contains check request that is interfaced to your account's payable system. The batch process ID is defined on Installation Options - Financial. The base package is supplied with a skeletal background process (referred to by the process ID of APDL ) that must be populated with logic to format the records in the format compatible with your accounts payable system.

- The run number is the batch process ID's current run number.

Fastpath:

Refer to Accounts Payable Check Request for more information.

If the resultant check needs to be reported for income tax purposes under a specific 1099 category, the category is also specified on the adjustment type. The 1099 category is in turn interfaced to the A/P system (the system does NOT manage 1099 reporting).

Controls Information Printed On The Bill

If the adjustment appears on the customer's next bill, the verbiage is specified on the adjustment type (and may NOT be overridden on the adjustment).

Controls If The Adjustment Can Be Frozen Prior To Bill Completion

Refer to Preventing SA Balances And The GL From Being Impacted Until Bill Completion for how adjustment type can control whether adjustments of a given type can be frozen prior to bill completion.

Controls If The Adjustment Requires Approval

If an adjustment's adjustment type references an approval profile, the system will not allow the initiating user to freeze the adjustment. Rather, the initiating user can 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 will freeze 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).

Note:

Only online adjustments are subject to approval. The system assumes that no approval is necessary for adjustments created by batch processes even those whose adjustment type references an approval profile.

Fastpath:

Refer to The Big Picture of Adjustment Approvals for more information.

Unbilled Adjustments And Aged Debt

A Frozen adjustment waits in limbo until the customer's next bill is produced. This limbo period could be several weeks if the customer is billed infrequently. When the customer's next bill is completed, all limbo adjustments are linked to the bill. A brief description (as defined on the adjustment type) appears on the printed bill.

It is important to stress the following in respect of these limbo adjustments:

- If the adjustment decreases the amount of debt, the customer's aged debt is affected immediately regardless of whether the adjustment appears on a bill.

- If the adjustment increases the amount of debt, the amount the customer owes from an aged debt perspective may or may not be affected by the adjustment. There is a switch on the financial transaction created for the adjustment called New Charge that controls the arrears behavior. When the FT for this type of adjustment is created, the switch is set to on and the customer's aged debt will not reflect the adjustment amount until the adjustment is swept onto a bill. The moment the adjustment is swept onto the customer's bill, the debt starts aging. A user may turn the switch off to cause the debt to start aging sooner. For this case, the date on which the adjustment starts aging must be defined in the Arrears Date field.

- The amount a customer owes in total is immediately affected by the adjustment regardless of whether the adjustment appears on a bill. This means that amount of aged debt may not be in sync with the total amount owed. This seems odd but is useful from a credit and collections perspective. You see, you probably don't want to start aging an adjustment until the customer has actually seen it.

An Adjustment May Affect More Than Just Customer Balances

Fastpath:

When an adjustment is frozen or cancelled, a customer'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 a service agreement. 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.

Contents

The Lifecycle Of An Adjustment

Adjustments - Main Information

Adjustments - Characteristics

Adjustments - Transfer Adjustment

Adjustments - A/P Request

Adjustments - Approval

Financial - Adjustment Calculation Line Characteristics

The Lifecycle Of An Adjustment

The following diagram shows the possible lifecycle of an adjustment.

Warning:

This diagram only makes sense in the context of the page used to maintain Adjustments. Refer to Adjustments - Main Information for the details.

Note: Even though New is considered a valid adjustment state, this is only used as default when adding an adjustment. Once the adjustment is saved, it is assigned the appropriate state in the adjustment life cycle. An adjustment will never exist in the New state.

Adjustments are initially created in the Incomplete state. Adjustments in this state don't have a financial transaction. This means, you can change the adjustment type and amount at will.

Click Generate to generate a financial transaction for the adjustment. The financial transaction contains the adjustment's effect on the general ledger and on the customer's payoff and current balances. If the adjustment is calculated, the algorithm on the adjustment type's Generate Adjustment event controls how the adjustment is calculated. If the adjustment is calculated, you must specify the calculation date, which is passed as a parameter to the calculation algorithm and is used for calculations that are effective dated (e.g., rate version or bill factor value). The financial transaction (FT) algorithm defined on the adjustment type Adj. Financial Transaction event controls how the financial transaction is constructed. For calculated adjustments, the distribution code may be taken from the adjustment type or the calculation lines.

After generating the financial transaction, the adjustment becomes Freezable . While in this state, you may change the service agreement, adjustment type and amount at will. However, if you change this information, you will have to regenerate the financial transaction (by clicking the Generate button).

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.

Click the delete button to physically remove an Incomplete , Error or Freezable adjustment from the database.

Warning:

Please be aware that you can prevent specific types of adjustments from being frozen until the account's next bill is completed . Refer to Preventing SA Balances And The GL From Being Impacted Until Bill Completion for how to enable this feature on your adjustment types.

Click Freeze to freeze the adjustment and its financial transaction. After doing this, the adjustment's state becomes Frozen . While in this state, you cannot change the adjustment's type or amount, but you may change:

- When the adjustment starts aging.

- Whether the adjustment appears on a customer's bill.

- The accounting date used to derive the general ledger accounting period(s) to which the financial transaction is booked.

Note:

Adjustments may require approval. If the adjustment type referenced on the adjustment has an approval profile, the Freeze button is replaced with a Submit for Approval button. If an adjustment is currently being approved, all action buttons are disabled because the adjustment must be either approved or rejected using the Adjustments - Approval page. Refer to The Big Picture of Adjustment Approvals for more information.

If you need to remove the financial effects of an adjustment, click Cancel. Canceling an adjustment causes the generation of another financial transaction. This new financial transaction reverses the financial impact of the original adjustment.

Adjustments - Main Information

Fastpath:

The Description of Page section below 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 Financial, Adjustment.

Warning:

All adjustments reference a very important field that controls much validation and processing; this field is called Adjustment Type. Take special care when adding a new adjustment to specify the appropriate Adjustment Type as it affects how the adjustment appears on the customer's bill, how the adjustment is reflected in your general ledger, and much more. After the adjustment is frozen, you may not change its Adjustment Type.

Description of Page

Adjustment Info contains a concatenation of the adjustment amount, adjustment type and status.

Note:

Formatting may be performed by a plug-in. The contents of Adjustment Info may be formatted by a plug-in algorithm on the Adjustment Type. Refer to the base package's C1-ADT-INFO for an example. If such an algorithm is not plugged-in on the Adjustment Type, the system looks for a corresponding algorithm on the installation record. Refer to the base package's C1-ADI-INFO for examples. If you prefer different formatting logic, your system administrator should configure the system appropriately.

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 Service Agreement ID to define the service agreement whose value needs to be adjusted. Basic information about the service agreement appears adjacent.

Premise is a display-only field that shows the Service Agreement's characteristic premise (i.e., the primary premise associated with the service agreement).

Indicate the Adjustment Type. This field is very important as it controls numerous aspects of the adjustment's impact on the customer's balance and your general ledger. This field is gray after the adjustment is frozen.

Note:

You can only choose certain adjustment types. The service agreement's SA 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 SA type.

Enter the Amount of the adjustment. If the adjustment type is a calculated 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 calculated adjustment type. It is used by the generate adjustment algorithm for any calculations that are effective dated (e.g., rate version or bill 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.

On Behalf SA ID is a display-only field that is only populated on system-generated adjustments instigated by one customer, but attributed to another customer. For example, if chargeable field work is performed for a customer, but is payable by the customer's meter maintenance service provider, the adjustment will be linked to the service provider and will reference the customer's SA as its On Behalf SA ID. This field is only visible if it is populated on the adjustment.

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.

Use the Comments to describe anything unusual about the adjustment.

The Creation Date defines the date on which the adjustment was created.

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.

- Arrears 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 service agreement's current balance.

- Payoff Amount contains the FT's effect on the service agreement'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 service agreement's account.

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 displays 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 customer'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 customer'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.

- Unit of Measure (UOM) is the unit of measure of the service quantity priced on the calculation line.

- Time of Use (TOU) is the time-of-use code of the service quantity priced on the calculation line.

- SQI is the service quantity identifier of the service quantity priced on the calculation line.

- Billable Service Quantity is the service quantity priced on the calculation line. This quantity differs from the measured consumption if there are SQ 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. This is only populated if the original rate engine calculated the charges.

- Calculation Rule is the rule that calculated the line. This is only populated if the new rate engine calculated the charges.

- Measures Peak Qty is checked if the UOM priced on the calculation line is used to measure a peak quantity.

- Exempt Amount is the amount of the calculated charge that the customer doesn't have to pay because they are tax exempt.

- 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 bill factor (because only bill factors use characteristic values). Refer to An Illustration Of A Bill Factor And Its Characteristics for more information.

Fastpath:

For more information, refer to Calculated 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.

Warning:

Please be aware that you can prevent specific types of adjustments from being frozen until the account's next bill is completed . Refer to Preventing SA Balances And The GL From Being Impacted Until Bill Completion for how to enable this feature on your adjustment types.

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 Financial, Adjustment, Characteristics.

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 below 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 Financial, Adjustment, Transfer Adjustment.

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 Service Agreement ID to define the transfer to service agreement. Basic information about the service agreement appears adjacent.

Premise is a display-only field that shows the Service Agreement's characteristic premise (i.e., the primary premise associated with the service agreement).

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.

- Arrears 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 service agreement's current balance.

- Payoff Amount contains the FT's effect on the service agreement'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.

Adjustments - A/P Request

Fastpath:

The Description of Page below 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 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 Financial, Adjustment, A/P Request.

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.

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. This name is derived from the account's main person:

- 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.

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

- Holdif 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. This is the billing address of the main customer linked to the account. After the adjustment is frozen, this information is automatically populated based on the address information for the account. This information is modifiable until the status is Paid .

Adjustment - Adjustment Portal

Select Main Menu > Financial > Adjustment and navigate to the Adjustment Portal tab to view additional information associated with an Adjustment.

General Information

Adjustment ID, Adjustment Info are displayed.

Depending on your implementations requirements, you may define additional zones to appear on this Portal.

Refer to The Big Picture of Portals and Zones in the Oracle Utilities Application Framework Administration Guide for a description of portal and zone functionality.

Adjustments - Approval

This page only appears after an adjustment has started the approval process. Open this page using Financial, Adjustment, Approval.

Fastpath:

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.

Contents

Adjustment Information

Approval Request

Approval Request Log

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

Accountis the account to which the adjustment is linked. The name of the main person on the account appears next to the account ID.

The SA is the service agreement whose value needs to be adjusted. Basic information about the service agreement appears adjacent.

Premise shows the service agreement's characteristic premise (i.e., the primary premise associated with the service agreement).

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 customer's bill.

The characteristics grid displays the Characteristic Types and the Characteristic Values associated with the calculation line.

Fastpath:

For more information about characteristics, refer to Setting Up Characteristic Types and Their Values.

How and When To Use An Adjustment

Note:

A last resort. Adjustments should be viewed as a last resort because you should correct the cause of errors, rather than the effect. For example, if a customer's bill is incorrect, you should fix the customer's rate / meter reads / contract terms and then perform a cancel / rebill. Issuing an adjustment to fudge the balance is really just that - a fudge.

The topics in this section describe how to perform common adjustment maintenance functions.

Contents

How To Create A Transfer Adjustment

How To Create A Calculated Adjustment

How To Cancel An A/P Adjustment After It Has Been Selected By A/P

How To Correct Normal Service Agreement Debt

How To Apply Ad Hoc Fees To A Service Agreement

How To Apply Interest To A Deposit

How To Apply A Deposit To Outstanding Debt

How To Refund A Deposit With A Check

How To Write-Down Deposit Due

How To Refund A Credit Balance With A Check

How To Transfer A Credit Balance To A Service Agreement In Arrears

How To Change The Age Of Debt

How To Write-Down A Charitable Contribution Service Agreement Debt

How To Write-Off Debt

How To Cancel A Service Agreement's Budget

How To Adjust A Service Agreement On A Budget

How To Adjust An Installment Plan Service Agreement

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 on the Adjustment page.

Note:

You cannot use an adjustment type with a calculated amount for transfer adjustments.

Warning:

These steps only make sense in the context of the page used to maintain Adjustments. Refer to Adjustments - Main Information for the details.

To create a transfer adjustment:

- Specify the "transfer from" account and service agreement on the Adjustment - Main page.

- Specify the adjustment type and the amount and transfer to the Transfer Adjustment page.

- Specify the "transfer to" service agreement and click the Generate and Freeze buttons to generate and freeze the adjustments' financial transactions. Please be aware that the Freeze button may be disabled for certain types of adjustments. This is because you can prevent specific types of adjustments from being frozen until the account's next bill is completed . Refer to Preventing SA Balances And The GL From Being Impacted Until Bill Completion for how to enable this feature on your adjustment types.

How To Create A Calculated Adjustment

The following steps describe how to create a calculated adjustment on the Adjustment page.

Warning:

These steps only make sense in the context of the page used to maintain Adjustments. Refer to Adjustments - Main Information for the details.

To create a calculated adjustment:

1. Open Financial, Adjustment, Main and specifiy the Service Agreement to which the adjustment will be applied.

2. Specify the Adjustment Type that calculates the amount, and enter a base Amount.

3. Click Generate. The Generate dialog box opens.

4. In the resulting dialog box, specify an Accounting Date and Generation Reference Date. Click Calculate.

5. Click Freeze to freeze the calculated transactions.

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 bill factor value).

Please be aware that the Freeze button may be disabled for certain types of adjustments. This is because you can prevent specific types of adjustments from being frozen until the account's next bill is completed . Refer to Preventing SA Balances And The GL From Being Impacted Until Bill Completion for how to enable this feature on your adjustment types.

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 CIS 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 in CIS to Canceled . At this point, you can cancel the adjustment in CIS.

How To Correct Normal Service Agreement Debt

If a customer is unhappy with the balance on a "normal" service agreement and you cannot fix the source of their unhappiness (i.e., the bills and payments), create an adjustment. Simply select an adjustment type that describes why you are adjusting the balance and enter the amount of the adjustment (a negative number if you are crediting the customer).

Note:

What's normal? There really is no such thing as a "normal" service agreement. We use this term to reference service agreements used to bill for services like utility service, land leases, home warranties, security monitoring, etc. where the current amount is the same as the payoff amount.

Warning:

A service agreement that is part of a budget plan is NOT normal. Refer to How To Adjust A Service Agreement On A Budget for more information.

How To Apply Ad Hoc Fees To A Service Agreement

If you need to apply a fee (e.g., late payment charge, connection charge, NSF charge) to a "normal" service agreement, issue an adjustment using the appropriate adjustment type. The adjustment amount should be a positive number so that the customer's balance increases.

Warning:

Take care if you apply a fee to a service agreement that's on a budget. The adjustment affects current balance and payoff balance by the amount of the fee. If you didn't mean to affect the customer's current balance, you'll have to issue another adjustment to change it.

How To Apply Interest To A Deposit

Fastpath:

You should only have to issue adjustments to calculate and refund interest if you need to override the system's automated procedures. Refer to Controls Interest Calculation for the details.

If you need to manually apply interest to a deposit, issue an adjustment using the appropriate adjustment type. The adjustment amount should be a negative number (you are crediting the customer's deposit balance).

If you want to apply the interest to the customer's outstanding balance, refer to How To Apply A Deposit To Outstanding Debt .

If you want to cut a check for the deposit, refer to How To Refund A Deposit With A Check .

How To Apply A Deposit To Outstanding Debt

Fastpath:

You should only have to issue adjustments to apply a deposit to outstanding debt if you need to override the system's automated procedures. Refer to Refunding Deposits for the details.

Applying a deposit is a two-step process:

- The deposit service agreement's payoff balance contains the amount of deposit you are holding on behalf of the customer's debt. Its current balance should be zero (i.e., the customer doesn't owe any additional deposit). Before you apply the deposit balance, we recommend making the deposit's current balance equal to the amount to be transferred. You do this by issuing an adjustment that just affects the deposit's current balance. The amount of this adjustment should be a negative number.

- After the deposit's current balance reflects an appropriate credit amount (equal to the amount to be applied to the customer's debt), use the Transfer Adjustment process to apply the deposit's credit balance to another service agreement's debit balance. The deposit service agreement is the transfer from service agreement; the delinquent service agreement is the transfer to service agreement. The adjustment amount should be a positive number. Refer to How To Create A Transfer Adjustment for more information.

Warning:

Take care if you apply a deposit to a service agreement that's on a budget. The transfer adjustment affects current balance and payoff balance by the same amount. If you didn't mean to affect the customer's current balance, you'll have to issue another adjustment to change it.

How To Refund A Deposit With A Check

Fastpath:

You should only have to issue adjustments to apply a deposit to outstanding debt if you need to override the system's automated procedures. Refer to Refunding Deposits for the details.

Refunding a deposit with a check (cut by your A/P system) is a two step process:

- The deposit service agreement's payoff balance contains the amount of deposit you are holding on behalf of the customer's debt. Its current balance should be zero (i.e., the customer doesn't owe any additional deposit). Before you refund the deposit balance, we recommend making the deposit's current balance equal to the amount to be refunded. You do this by issuing an adjustment that just affects the deposit's current balance. The amount of this adjustment should be a negative number.

- After the deposit's current balance reflects an appropriate credit amount (equal to the amount to be refunded), issue a refund adjustment. The adjustment amount should be a positive number. This adjustment causes a check request to be interfaced to your A/P system.

How To Write-Down Deposit Due

If a customer doesn't pay their deposit and you don't expect them to, create an adjustment to write-down the current balance. Simply select an adjustment type that describes why you are adjusting the balance and enter the amount of the adjustment (a negative number).

How To Refund A Credit Balance With A Check

If you need to refund a credit balance on a "normal" service agreement, issue a refund adjustment using the appropriate adjustment type. The adjustment amount should be a positive number. This adjustment causes a check request to be interfaced to your A/P system.

Warning:

Take care if you refund a credit balance from a service agreement that's on a budget. The adjustment affects current balance and payoff balance by the amount of the refund. If you didn't mean to affect the customer's current balance, you'll have to issue another adjustment to change it.

How To Transfer A Credit Balance To A Service Agreement In Arrears

Use the Transfer Adjustment process to apply a "normal" service agreement's credit balance to another service agreement's debit balance. The credit service agreement is the transfer from service agreement; the delinquent service agreement is the transfer to service agreement. The adjustment amount should be a positive number. Refer to How To Create A Transfer Adjustment for more information.

Warning:

Take care if you apply a credit to a service agreement that's on a budget. The transfer adjustment affects current balance and payoff balance by the transfer amount. If you didn't mean to affect the customer's current balance, you'll have to issue another adjustment to change it.

How To Change The Age Of Debt

If a service agreement's debt is older (or younger) than what it should be (for whatever reason), you should do the following.

- Use the Transfer Adjustment process to re-age the debt. The transfer from and transfer to service agreements will be the same. The adjustment amount should be a negative number. Refer to How To Create A Transfer Adjustment for more information.

- After creating the transfer adjustment, drill into the transfer to adjustment and populate the arrears date with the day on which the debt should start aging (e.g., if the debt should be 7 days old, the arrears date should be the current date minus 7 days).

Warning:

Be careful if you transfer debt from a service agreement that's on a budget. Before doing the transfer, you should make the customer's current balance equal their payoff balance.

How To Write-Down A Charitable Contribution Service Agreement Debt

If a customer doesn't want to contribute as much to the charity as the agreed to, create an adjustment to fix the current balance (charity service agreements shouldn't have a payoff balance as the "debt" is voluntary). Simply select an adjustment type that describes why you are adjusting the balance and enter the amount of the adjustment (a negative number).

How To Write-Off Debt

To write-off debt:

Warning:

You don't have to do the tasks outlined below if you use the Write Off - Main page. This page does these tasks for you.

- Create a write-off service agreement using the Start Service page (you could also use the Service Agreement page to do this).

- Use the Transfer Adjustment process to transfer the delinquent debt to the to the write-off service agreement. The original service agreement is the transfer from service agreement; the write-off service agreement is the transfer to service agreement. The adjustment amount should be a negative number. Refer to Transfer Adjustments for more information.

Warning:

Take care if you transfer debt from a service agreement that's on a budget. Before doing the transfer, you should make the service agreement's current balance equal their payoff balance.

How To Cancel A Service Agreement's Budget

Warning:

You don't have to do the tasks outlined below if you use the Account - Budget panel. This panel does these tasks for you.

Canceling a service agreement's budget involves the following steps:

- Update the service agreement to indicate the service agreement is no longer on a budget.

- Issue an adjustment to make the service agreement's current balance equal the payoff balance.

Note:

Credit and collections (C&C). You can change the arrears date on the adjustment that synchronizes current and payoff balance to reflect the true age of the debt. You do this on the financial transaction associated with the adjustment. If you do this, C&C will monitor the old debt accordingly.

How To Adjust A Service Agreement On A Budget

If you need to adjust the debt on a service agreement that's on a budget plan, you have to ask yourself why you're adjusting the balance:

- If you're adjusting the balance to correct the payoff balance (for whatever reason), choose an adjustment type that just affects this balance.

- If you're adjusting the balance to correct the current balance (for whatever reason), choose an adjustment type that just affects this balance.

- If you need to adjust both balances equally, choose an adjustment type that affects both.

How To Adjust An Installment Plan Service Agreement

If you need to adjust the debt on a service agreement that's used to bill a total amount in installments, you have to ask yourself why you're adjusting the balance:

- If you're adjusting the balance to correct the payoff balance (for whatever reason), choose an adjustment type that just affects this balance.

- If you're adjusting the balance to correct the current balance (for whatever reason), choose an adjustment type that just affects this balance.

If you need to adjust both balances equally, choose an adjustment type that affects both.

How To Use An Adjustment To Change The GL Distribution

Assume you have a frozen bill segment that affected an incorrect GL distribution code (e.g., it booked revenue to commercial - time-of-use - revenue and it should have booked it to industrial - time-of-use - revenue. You have two ways to correct such a situation:

- You could correct the cause of the incorrect distribution code (probably incorrect GL information on a rate component/pricing rule) and cancel / rebill the bill segment. Refer to Cancel / Rebill for more information about this method.

- You could create an adjustment that does not impact the customer'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 customer'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.

Note:

Adjusting statistical amounts. You can use the above approach to change the statistical amount that is interfaced to the general ledger. The statistical amount is simply another column on the financial transaction's GL distribution rows.

Interfacing Adjustments From External Sources

The topics in this section describe how adjustments are uploaded from an external source.

Contents

Interfacing Adjustments

Suspense Adjustments

Maintaining Adjustment Staging Control

Maintaining Adjustment Upload Staging

Interfacing Adjustments

The following diagram illustrates the processes involved in the uploading of adjustments into the system.

The topics in this section describe how these processes work.

Contents

Process X - Populate Adjustment Upload Records

Process C1-ADUP1 - Preprocess Adjustment Uploads

Process C1-ADUP2 - Upload Adjustments

Process X - Populate Adjustment Upload Records

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.

Contents

Adjustment Staging Control

Adjustment Staging Control Characteristic

Adjustment Upload Staging

Adjustment Characteristic Upload Staging

The Lifecycle of an Adjustment Staging Control Record

The Lifecycle of an Adjustment Upload Staging Record

Adjustment Staging Control

You must create an adjustment staging control record for each batch of adjustments to be uploaded into the system. The name of this table is CI_ADJ_STG_CTL. The following describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

ADJ_STG_CTL_ID

12

Y

N

This is the unique identifier of the adjustment staging control record. This key is a sequential number so you can use a database function to assign the value when populating the table.

CRE_DTTM

15

Y

DateTime

This is the date / time on which the adjustment staging control record was created. This must be populated with the current date / time.

ADJ_STG_CTL_STATUS_FLG

4

Y

A/N

This must be set to P for Pending .

ADJ_STG_UP_REC_CNT

10

Y

N

This is the total number of adjustment upload staging records that are linked to this adjustment staging control.

TOT_ADJ_AMT

13.2

Y

N

This column must equal the sum of adjustment amounts on the adjustment upload staging records that are linked to this adjustment staging control.

CURRENCY_CD

3

Y

A/N

This must be a valid currency code in the system. Refer to Defining Currency Codes for more information.

MESSAGE_CATEGORY

5

N

N

Leave this blank. The adjustment upload preprocessor populates this when an error occurs during upload.

MESSAGE_NBR

5

N

N

Leave this blank. The adjustment upload preprocessor populates this when an error occurs during upload.

Adjustment Staging Control Characteristic

You must create an adjustment staging control characteristic record for each characteristic that you would like to link to the adjustment staging control. The name of this table is CI_ADJ_STG_CTL_CHAR. The following describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

ADJ_STG_CTL_ID

12

Y

N

This must correspond with the prime key of the related CI_ADJ_STG_CTL record.

CHAR_TYPE_CD

8

Y

A/N

This must correspond with a characteristic type that is defined as valid for adjustment staging control . 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 adjustment staging control 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.

Adjustment Upload Staging

You must create an adjustment upload staging record for each adjustment you want to upload. The name of this table is CI_ADJ_STG_UP. The following describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

ADJ_STG_UP_ID

12

Y

N

This is the unique identifier of the adjustment upload staging record. This key is a sequential number so you can use a database function to assign the value when populating the table.

ADJ_STG_CTL_ID

12

Y

N

The ID of the adjustment staging control that is linked to this adjustment upload staging record.

ADJ_TYPE_CD

8

Y

A/N

This must correspond to the prime key of one of your adjustment types. Refer to Setting up Adjustment Types for more information.

ADJ_STG_UP_STATUS_FLG

4

Y

A/N

This must be set to P for Pending .

CREATE_DT

10

Y

Date

The date when the adjustment occurred.

ADJ_AMT

13.2

Y

N

The amount of the adjustment.

ADJ_SUSPENSE_FLG

4

Y

N

This must be set to NSUS for Not In Suspense .

SA_ID

10

N

A/N

This must correspond to a valid service agreement in the system.

If you leave this blank and opt to let the system find the SA during adjustment upload preprocessing, a Determine SA algorithm must be plugged in on the associated adjustment type. This plug-in is meant to derive the SA ID based on supplied miscellaneous information - e.g. information supplied via adjustment characteristic upload staging.

ADJ_ID

10

N

A/N

Leave this blank. The adjustment upload process populates this.

SUSPENSE_ADJ_ID

10

N

A/N

Leave this blank. The adjustment upload process populates this.

MESSAGE_CATEGORY

5

N

N

Leave this blank. The adjustment upload background processes populate this when an error occurs during upload.

MESSAGE_NBR

5

N

N

Leave this blank. The adjustment upload background processes populate this when an error occurs during upload.

Adjustment Characteristic Upload Staging

You must create an adjustment characteristic upload staging record for each characteristic that you would like to link to the adjustment upload staging. The name of this table is CI_ADJ_STG_UP_CHAR. The following describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

ADJ_STG_UP_ID

12

Y

N

This must correspond with the prime key of the related CI_ADJ_STG_UP record.

CHAR_TYPE_CD

8

Y

A/N

This must correspond with a characteristic type that is defined as valid for adjustment 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 adjustment upload staging 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 an Adjustment Staging Control Record

The following diagram shows the possible lifecycle of an adjustment staging control record.

- Pending. An adjustment staging control record is created in this state. The C1-ADUP1 process selects pending adjustment staging control records for validation.

- In Progress. The C1-ADUP1 process sets a pending record to in progress when the totals on the adjustment staging control are successfully validated against the totals from the associated adjustment upload staging records.

- Complete . The C1-ADUP2 process sets the adjustment staging control's status to complete when all adjustment upload staging records linked to the adjustment staging control are complete .

- Error. The C1-ADUP1 process sets a pending record to error if the adjustment staging control fails validation. The status may be set back to pending after the error is fixed.

- Held. The held status is available for situations where you want to prevent or delay the upload of a batch of adjustment staging records. The status may be set back to pending when the batch of records is ready for upload.

- Pending, error and held records may be deleted.

The Lifecycle of an Adjustment Upload Staging Record

The following diagram shows the possible lifecycle of an adjustment upload staging record.

- Pending. Adjustment upload records are created in this state. The C1-ADUP2 process selects pending adjustment upload records and creates adjustments for each of them.

- Complete. The C1-ADUP2 process sets a pending record to complete if an adjustment is successfully created.

- Error. Either C1-ADUP1orC1-ADUP2 process sets pending record to error when it encounters an error during the upload process. The status may be set back to pending after the error is fixed.

- Pending and error records may be deleted.

Process C1-ADUP1 - Preprocess Adjustment Uploads

The batch process identified by batch process ID C1-ADUP1 refers to the background process that validates adjustment staging control records and populates service agreement IDs on adjustment upload staging records that do not specify an SA ID.

Contents

Phase 1 - Validate Adjustment Staging Controls

Phase 2 - Populate SA ID

Phase 1 - Validate Adjustment Staging Controls

The following points describe, at a high level, the first phase of the adjustment upload pre-process:

- For each Pending adjustment staging control,

- Check that the record count on the adjustment staging control record equals the number of adjustment upload staging records that are linked to the adjustment staging control.

- Check that the total adjustment amount on the adjustment staging control record equals the sum of the adjustment amounts from the adjustment upload staging records that are linked to the adjustment staging control.

- If the adjustment staging control passes validation, set its status to In Progress . Otherwise, set the status to Error . Create a To Do entry using the inputs To Do type and To Do role (if supplied) for adjustment staging control errors. (Complete any outstanding To Do entries for the adjustment staging control before creating a new To Do entry.)

- If no errors occur, perform To Do cleanup by completing any outstanding To Do entries that were previously created for the adjustment staging control.

Note:

You can fix errors by going to the To Do entry and drilling into the adjustment staging control page. Don't forget to change the adjustment staging control's status back to Pending after fixing the error.

Phase 2 - Populate SA ID

The following points describe, at a high level, the second phase of the adjustment upload pre-process:

- For each Pending adjustment upload staging that is linked to an In Progress adjustment staging control AND does not have the SA ID,

- Execute the Determine SA algorithm that is plugged in on the adjustment type.

- If the algorithm returns a valid SA ID, stamp that SA ID onto the adjustment upload staging. If the algorithm also returns an indication that the adjustment is to be put into suspense, set the suspense flag on the adjustment upload staging to In Suspense . Refer to Suspense Adjustments for more information on how suspense adjustments are handled.

- If the algorithm returns an error, set the adjustment upload staging record's status to Error . Create a To Do entry using the inputs To Do type and To Do role (if supplied) for adjustment upload staging errors. (Complete any outstanding To Do entries for the adjustment upload staging before creating a new To Do entry.)

- If no errors occur, perform To Do cleanup by completing any outstanding To Do entries that were previously created for the adjustment upload staging.

Note:

You can fix errors by going to the To Do entry and drilling into the adjustment upload staging page. Don't forget to change the adjustment upload staging's status back to Pending after fixing the error.

Process C1-ADUP2 - Upload Adjustments

The batch process identified by batch process ID C1-ADUP2 refers to the background process that creates adjustments for all adjustment upload staging records that are stamped with an SA ID.

The following diagram and section describe, at a high level, the processing done in the C1-ADUP2 background process.

- For each Pending adjustment upload staging that has an SA ID,

- Add a frozen adjustment using the amount, creation date and adjustment type on the staging record.

Note:

If the type of adjustment being uploaded is one that is calculated, the algorithm that's plugged in on the adjustment type will calculate the adjustment amount and generate associated calculation lines (if applicable). See Calculated Adjustments for more information.

- If adjustment creation is successful, update the adjustment ID on the staging record and set the staging record's status to Complete .

- If adjustment creation results in an error, set the staging record's status to Error . Create a To Do entry using the To Do type on which this batch process ( C1-ADUP2 ) is defined as creation process. (Complete any outstanding To Do entries for the adjustment upload staging before creating a new To Do entry.)

- If no errors occur, perform To Do cleanup by completing any outstanding To Do entries that were previously created for the adjustment upload staging.

Suspense Adjustments

Contents

What Are Suspense Adjustments?

How Are Suspense Adjustments Resolved?

What Are Suspense Adjustments?

When the adjustment upload preprocessor is unable to identify a valid SA ID, it can post the adjustment to a suspense SA. This is similar to how a payment is posted to a suspense account when a valid account ID could not be identified during payment upload.

Putting adjustments in suspense is optional. Therefore, this logic sits in a plug-in spot. If suspense adjustments are applicable to you, you must plug in your suspense logic in a Determine SA algorithm on Adjustment Type.

How Are Suspense Adjustments Resolved?

A background process can be run periodically to automatically resolve suspense adjustments. Since rules for resolving suspense may vary, this logic sits in a plug-in spot. You must plug in your resolve logic in a Resolve Suspense algorithm on Adjustment Type.

Process C1-ADURS - Resolve Suspense Adjustments

The batch process identified by batch process ID C1-ADURS refers to the background process that resolves suspense adjustments.

For each adjustment upload staging that is In Suspense , execute the Resolve Suspense algorithm that is plugged in on the adjustment type.

Maintaining Adjustment Staging Control

Use this page to add, view or modify an adjustment staging control record. Open this page using Financial, 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 descriptionif 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 Financial, 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 customer's balance and your general ledger.

Note:

You can only choose certain adjustment types. The service agreement's SA 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 SA 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.

Service Agreement indicates the SA to which the adjustment was posted. If the adjustment is in suspense, the label shows Suspense SA 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.

Credit & Collections

The system periodically monitors how much your customers owe to ensure they haven't violated your collection criteria. When a violation is detected, the system generates the appropriate events (e.g., letters, disconnect field activities, To Do entries, write-off outstanding debt, etc.). This section describes how to manage your credit & collections processing.

Note:

In the section, The Big Picture Of Credit & Collections (C&C), we describe how to set up the control tables that automate most of your credit & collections processing. If you set these tables up properly, the system will manage most of your collection, severance and write-off processes; little or no user intervention should be necessary. You will only access the C&C pages when you need to override what the system does.

Contents

The Big Picture Of Credit & Collections

Collection Process Maintenance

Severance Process Maintenance

Write-off Process Maintenance

Writing Off Uncollectable Debt

Collection Referral

Payment Arrangements and Pay Plans

The Big Picture Of Credit & Collections

The topics in this section provide background information about a variety of credit & collections issues.

Contents

Automating Your C&C Activities

The Lifecycle Of A Collection Process And Its Events

The Collection Process Background Processes

The Lifecycle Of A Severance Process And Its Events

The Severance Process Background Processes

The Lifecycle Of A Write Off Process And Its Events

The Write-Off Process Background Processes

Automating Your C&C Activities

Fastpath:

Refer to The Big Picture Of Credit & Collections (C&C) to understand how the system monitors overdue debt and initiates the appropriate collection, severance and write-off events when a customer exceeds your debt tolerances.

The Lifecycle Of A Collection Process And Its Events

The following diagram illustrates the lifecycle of a typical collection process and its collection events:

The above diagram is referenced in the following topics.

Contents

What Is A Collection Process?

How Are Collection Processes Created?

How Are Collection Events Completed?

How Are Collection Processes (and their Events) Canceled?

What Happens If A Payment Is Not Received?

What Is A Collection Process?

A collection process is a series of events (e.g., letters, To Do entries) meant to encourage an account to pay its delinquent debt. Linked to the collection process are the specific service agreements that contributed to the delinquent debt.

How Are Collection Processes Created?

A collection process and its events may be created as follows:

- The Account Debt Monitor is a background process that creates a collection process when an account violates your collection criteria. The collection process has one or more collection event(s). The collection process template associated with the collection process controls the number and type of events.

- A user may create an ad hoc collection process at will. The collection process template controls the number and type of events linked to the collection process.

In the above diagram, the event on 1-Dec-99 shows the creation of a collection process with three collection events. Notice that the events all exist in the Pending state. The events will exist in this state until their trigger date is on or before the current date.

Fastpath:

Refer to How Does The Account Debt Monitor Work? to understand how the system monitors overdue debt and initiates the appropriate collection process when a customer exceeds your debt tolerances. Refer to The Big Picture Of Collection Events for more information about a collection process' events.

When you enable the Control Central alert algorithm, C1-COLLPR-AC, an alert displays when an account has an active collection process. This algorithm is plugged-in on the installation record.

How Are Collection Events Completed?

The event activator runs periodically (at least daily). It looks for collection events with a trigger date on or before the current date. For each such event, the system executes its activity and then completes it.

In the above diagram, the event activator activates pending events on 1-Dec-99 and 16-Dec-99. Notice that the events are moved to the Complete state.

Fastpath:

Refer to The Big Picture Of Collection Events for more information about the various types of collection events and what happens when they are completed.

How Are Collection Processes (and their Events) Canceled?

Fastpath:

Refer to How Are Collection Processes Cancelled for a description of how and when collection processes are automatically cancelled by the system.

Besides the automated cancellation process, a user may cancel a collection process at will. Refer to How To Cancel A Collection Process for more information.

What Happens If A Payment Is Not Received?

If a payment (or some other type of credit) is not received by the trigger date of the last event in the process, a severance process is initiated for one or more service agreements. Refer to The Last Collection Event Should Sever Service Agreement(s) for more information.

The Collection Process Background Processes

There are 3 background processes that automate the creation, activation, and cancellation of collection processes:

Contents

Account Debt Monitor

Collection Event Activator

Collection Process Monitor

Account Debt Monitor

The Account Debt Monitor (ADM) creates a collection process when an account violates your collection criteria. The collection process has one or more collection event(s). The number and type of events is defined on the collection process's template.

Note:

Heads up. There are actually two background processes involved with the monitoring of overdue debt. These processes are referred to using the batch process ID's of ADM and ADM2 .

In the above diagram, the ADM creates a collection process (with 3 events) on 1-Dec-99. Notice that the events all exist in the Pending state. The events will exist in this state until their trigger date is on or before the current date.

Fastpath:

Refer to How Does The Account Debt Monitor Work for more information.

Collection Event Activator

The collection event activator runs periodically (at least daily). It looks for collection events with a trigger date on or before the current date. For each such event, the system executes its activity and then completes it.

Note:

This batch process is referred to using the batch ID CET .

In the above diagram, the collection event activator activates pending events on 1-Dec-99 and 16-Dec-99. Notice that the events are moved to the Complete state after they are activated.

Collection Process Monitor

The Collection Process Monitor runs periodically (at least daily). This process reviews a collection process whenever one of its service agreements' debt is reduced.

Note:

This batch process is referred to using the batch ID CPM .

At review time, the Collection Process Monitor determines if it can cancel the collection process (because the customer's debt is no longer in a bad state). Refer to How Does The Collection Process Monitor Work for details describing how this process works.

In the above diagram, the collection process monitor cancels the process on 17-Dec-99. Notice that the events are moved to the Cancelled state and the process becomes Inactive .

The Lifecycle Of A Severance Process And Its Events

The following diagram illustrates the first part of the lifecycle of a typical severance process and its events:

The above diagram is referenced in the following topics.

Contents

What Is A Severance Process?

How Are Severance Processes Created?

How Are Severance Events Completed?

How Are Severance Processes (and their Events) Canceled?

What Happens If The Customer Does Not Pay?

What Is A Severance Process?

A severance process is a series of events (e.g., letters, To Do entries, field activities) that lead to the severance of a service agreement. A separate severance process is required for each service agreement to be severed.

How Are Severance Processes Created?

Severance processes may be created as follows:

- The Collection Event Activator creates a severance process when it completes a "start severance process" collection event. The severance process has one or more severance event(s). The severance process template associated with the severance process controls the number and type of events.

- A user may create an ad hoc severance process at will. The severance process template defined when the severance process is created controls the number and type of events linked to the severance process.

Note:

Manual Creation. A user can create a severance process for an account that does not qualify to be on severance according to the cancel criteria algorithm. For example, perhaps your cancel criteria algorithm cancels a severance process when the account's debt falls below a threshold amount. A user can create a severance process for an account whose debt is already below this threshold. Because cancellation is real time, there is no action that will cause this severance process to be canceled. When a manual severance process is created, the system executes the appropriate cancellation criteria algorithm. If the algorithm indicates that the system would have canceled this severance process, a warning is issued. Refer to How Are Severance Processes Cancelled for more information about cancellation algorithms.

In the above diagram, the event on 18-Dec-99 shows the creation of a severance process with three collection events. Notice that only the first event has a trigger date, this is because the later events' trigger date can only be determined after the first event is completed. Also, notice that the events all exist in the Pending state. The events will exist in this state until their trigger date is on or before the current date.

Fastpath:

Refer to How Are Collection Events Completed? for more information about the completion of collection events.

When you enable the Control Central Alert installation algorithm, C1-SEVPR-ACT, an alert displays when an account has an active severance process. This algorithm is plugged-in on the installation record.

How Are Severance Events Completed?

The Severance Event Activator (note: this batch process is called SET ) runs periodically (at least daily). It looks for severance events with a trigger date on or before the current date. For each such event, the system executes its activity. The type of severance event dictates what happens to the severance event's state. Refer to Field Events Versus Office Events for the details.

In the above diagram, the event activator activates a pending event on 18-Dec-99. Take note of the state of the severance event (it becomes Awaiting Field Activity Completion ).

Fastpath:

Refer to The Big Picture Of Severance Events for more informationabout the various types of severance events and what happens when they are completed.

How Are Severance Processes (and their Events) Canceled?

Fastpath:

Refer to How Are Severance Processes Cancelled for a description of how the system automatically cancels a severance process.

Note:

Real time cancellation. Unlike collection processes, the system cancels severance processes real time (i.e., there is no equivalent of the collection process monitor for severance processes). Why are severance processes canceled real time? Because a severance process may have events that create field activities to sever service. These events need to be canceled the moment the FT is frozen, we can't wait until a background process runs. This means that if a customer pays in person for a service agreement that is pending severance, the system will cancel the process and its field activities (if any) the moment the payment is entered. The logic to cancel the field activities is in an algorithm plugged in on the installation record.

Fastpath:

Refer to Setting Up Severance Process Templates for more information about severance process templates. Refer to Designing Your Reconnection Procedures for more information about how severance processes are used to reconnect services.

Besides the automated cancellation process, a user may cancel a severance process at will.

What Happens If The Customer Does Not Pay?

If a payment (or some other type of credit) is not received by the trigger date of the last event in the severance process, the service agreement is stopped (as long as you've setup your severance process to include an Expire Service Agreement event as the last event). The expiration of the last service agreement will, in turn, trigger a final bill. If the account doesn't pay the final bill, a write-off process will be started.

Note:

Final bills. The account will be setup for final billing when the LAST service agreement linked to the account is stopped. Refer to Finalizing Pending Stops for more information about how the system changes the account's bill cycle when the last service agreement is stopped.

Fastpath:

Refer to The Big Picture Of Write Off Processing for more information about the write off process.

The Severance Process Background Processes

The Collection Event Activator creates a severance process when it completes a "start severance process" collection event. The severance process has one or more severance event(s). The severance process template associated with the severance process controls the number and type of events. There are 3 background processes that automate the activation and cancellation of severance events:

Contents

Severance Event Activator

Completing Severance Events That Are Dependent On The Completion Of A Field Activity

Set Trigger Date

Severance Event Activator

The Severance Event Activator runs periodically (at least daily). It looks for severance events with a trigger date on or before the current date. For each such event, the system executes its activity. The type of severance event dictates what happens to the severance event's state.

Note:

This batch process is referred to using the batch ID SET .

In the above diagram, the event activator activates a pending event on 18-Dec-99. Take note of the state of the severance event (it becomes Awaiting Field Activity Completion ).

Completing Severance Events That Are Dependent On The Completion Of A Field Activity

The Complete Field Events process runs periodically (at least daily). It looks for severance events that are dependent on the completion of field activities before they can be completed. The system completes each such event when the field activities linked to the event are complete.

Note:

This batch process is referred to using the batch ID SEC .

In the above diagram, this process completes the event that was Awaiting Field Activity Completion on 19-Dec-99. Take note of the state of the severance event (it becomes Complete ).

Set Trigger Date

The Set Trigger Date process runs periodically (at least daily). It looks for severance events that are dependent on the completion of other events before their trigger date can be set. The system sets the trigger date of each such event when all of its dependent events are complete.

Note:

This batch process is referred to using the batch ID SED .

In the above diagram, this process sets the trigger date of the second event on 19-Dec-99.

The Lifecycle Of A Write Off Process And Its Events

The following diagram illustrates the lifecycle of a typical write-off process and its write-off events:

The above diagram is referenced in the following topics.

Contents

What Is A Write-off Process?

How Are Write-off Processes Created?

How Are Write-off Events Completed?

How Are Write-off Processes (and their Events) Canceled?

What Happens If The Debt Is Not Paid?

How Is Debt Referred To Collection Agencies

What Is A Write-off Process?

A write-off process is a series of events (e.g., letters, collection agency referrals) meant to encourage an account to pay its delinquent debt. Linked to the write-off process are the specific service agreements that contributed to the delinquent debt.

How Are Write-off Processes Created?

A write-off process and its events may be created as follows:

- The Write Off Monitor is a background process (referred to by the batch ID WPM ) that creates a write-off process when an account has finaled, unpaid service agreements. The write-off process has one or more write-off event(s). The write-off process template associated with the write-off process controls the number and type of events.

- A user may create an ad hoc write-off process at will. The write-off process template controls the number and type of events linked to the write-off process.

In the above diagram, the event on 15-Jan-00 shows the creation of a write-off process with three write-off events. Notice that the events all exist in the Pending state. The events will exist in this state until their trigger date is on or before the current date.

Fastpath:

Refer to How Does The Write-Off Monitor Work? to understand how the system monitors overdue debt and initiates the appropriate write-off process when a customer has unpaid, finaled service agreements. Refer to The Big Picture Of Write-off Events for more information about a write-off process' events.

How Are Write-off Events Completed?

The event activator runs periodically (at least daily). It looks for write-off events with a trigger date on or before the current date. For each such event, the system executes its activity and then completes it.

In the above diagram, the event activator activates a pending event on 15-Jan-00. Notice that the events are moved to the Complete state.

Fastpath:

Refer to The Big Picture Of Write-off Events for more information about the various types of write-off events and what happens when they are completed.

How Are Write-off Processes (and their Events) Canceled?

When a stopped service agreement's balance is reduced to zero (i.e., it closes), the system checks if there is an ongoing write-off process associated with the service agreement. If so:

- The system "removes" the service agreement from the write-off process.

- When the last service agreement is removed from a write-off process, the system cancels all pending write-off events and deactivates the write-off process.

- If the canceled process has collection agency referrals, the system cancels the referrals.

Note:

Real time cancellation. Unlike collection processes, the system cancels write-off processes real time (i.e., there is no equivalent of the collection process monitor for write-off processes). This means that if a customer (or collection agency) pays for a service agreement that is linked to write-off process, the system will cancel the process and its collection agency referrals (if any) the moment the payment is entered.

Fastpath:

Refer to Setting Up Write Off Process Templates for more information about write off process templates.

Besides the automated cancellation process, a user may cancel a write-off process at will.

What Happens If The Debt Is Not Paid?

If a payment (or some other type of credit) is not received by the trigger date of the last event in the process, the debt will be written off (assuming you designed your write off process template to do such).

Note:

The last write-off event should cause debt to be written off. Debt will only be written off if the last write-off event is the type that writes off debt. If the write-off process template contains no such event, nothing further will transpire until the next time the write-off monitor runs (when it will create another write-off process for the unpaid, finaled debt).

Fastpath:

Refer to How Is Debt Financially Written-Off? for a description of exactly how debt is written off.

How Is Debt Referred To Collection Agencies

Fastpath:

Refer to How Do Collection Agency Referrals Work? for more information about how the system refers debt to a collection agency.

The Write-Off Process Background Processes

There are 2 background processes that automate the creation, activation, and cancellation of write-off processes:

Note:

If necessary, you can write-off debt outside of the automated write-off process by simply transferring bad debt to a write-off service agreement using the Write Off transaction.

Contents

Write-Off Monitor

Write-Off Event Activator

Write-Off Monitor

The Write-Off Monitor is a background process that has two functions:

- It attempts to close Stopped and Reactivated service agreements using several methods as described under Attempt To Close The SA Before Creating A Write Off Process.

- If it is unsuccessful at closing a SA, it creates a write-off process. The write-off process has one or more write-off event(s). The write-off process template associated with the write-off process controls the number and type of events.

Note:

This batch process is referred to using the batch ID WPM .

In the above diagram, the event on 15-Jan-2000 shows the creation of a write-off process with three write-off events. Notice that the events all exist in the Pending state. The events will exist in this state until their trigger date is on or before the current date.

Write-Off Event Activator

The write-off event activator runs periodically (at least daily). It looks for write-off events with a trigger date on or before the current date. For each such event, the system executes its activity and then completes it.

Note:

This batch process is referred to using the batch ID WET .

In the above diagram, the write-off event activator activates a pending event on 15-Jan-2000. Notice that the event is moved to the Complete state.

Collection Process Maintenance

A collection process is a series of events (e.g., letters, To Do entries) meant to encourage an account to pay its delinquent debt. Linked to the collection process are the specific service agreements that contributed to the delinquent debt. The topics in this section describe the pages on which collection process-related information is maintained.

Fastpath:

For more information about collection processes, refer to The Lifecycle Of A Collection Process And Its Events.

Contents

Collection Process - Main Information

Collection Process - SAs (Service Agreements)

Collection Process - Events

How To Perform Common Collection Process Functions

Collection Process - Main Information

The Main page contains core collection process information. Open this page using Credit & Collection, Collection Process.

Fastpath:

The Description of Page section below describes the fields on this page. Refer to How To Perform Common Collection Process Functions for more instructions describing how to use this transaction.

Description of Page

Collection Process is a concatenation of summary information about this collection process. It is composed of the name of the main customer on the account, the collection status, the reason code for the collection status, the collection class control name, and the creation date of the process.

Collection Process ID is the unique system-generated identifier for this collection process.

Account ID is the system-generated account number. The name of the main customer on the account and its customer class are displayed next to the ID number.

Collection Status defines the state of the collection process. The following values may exist:

Active The system creates a collection process in the Active state. A collection process remains in this state until the last event linked to the process is complete OR the customer pays the collection amount on the service agreements linked to the process OR you want to stop the process for whatever reason.

Inactive A collection process becomes Inactive when the last event linked to the process is completed OR the customer pays the collection amount on all service agreements linked to the process OR you want to stop the process for whatever reason. The Reason field tells you how a collection process became inactive.

Fastpath:

To completely understand the significance of a collection process' status, refer to The Lifecycle Of A Collection Process And Its Events.

Reason defines how a collection process became Inactive or why a collection process is Active . The following values may exist:

Canceled by User This reason should be used when a user manually inactivates a collection process (for whatever reason).

Canceled by System This reason is populated by the system when it cancels a collection process. The system automatically cancels a collection process when sufficient credits have been posted to the process' service agreements since the process was started.

Events Pending This reason is populated by the system when a process has pending events.

Completed This reason is populated by the system when it completes the last event linked to the collection process.

Collection Class Control defines the debt class (i.e., the type of debt) associated with the collection process. This is important as it controls which service agreements can be linked to the collection process (every service agreement is associated with a specific debt class). This field is gray when there are service agreements linked to the collection process.

Note:

Multiple collection processes may be linked to an account. It's important to be aware that if an account's service agreements reference multiple debt classes, a collection process must be created for each debt class that you want to collect.

One collection process per debt class. A given debt class for an account may only have one ongoing collection process at any point in time.

Beneath Collection Class Control is displayed a message showing why the system generated the collection process. This information is only displayed for collection processes created by the Account Debt Monitor. If you have plugged in a Collection Process Additional Information algorithm on the Installation table, the results of the algorithm, if any, is displayed on a separate line.

The following line displays the minimum value payment to the collection process debt class that will cause cancellation of the collection process.

Fastpath:

For more information, refer to How Does The Account Debt Monitor Work?.

Collection Process Template defines the collection events in the process. You can override these events on the Events page.

Note:

Changing the template. If you change the template when all events are pending , the system will remove the pending events and replace them with the new template's events.

Fastpath:

For more information, refer to Setting Up Collection Process Templates.

Creation Date/Time defines the start date/time of the collection process. This is important as it affects the trigger dates of the process' collection events. This field becomes protected after the collection process exists on the database. If you need to change the trigger date on the events you can navigate to the Events tab and change the dates manually. Alternatively, you can perform the following "trick":

- Change the Collection Process Template to something (anything). Doing this causes the Create Date/Time to become unprotected.

- Specify the date of the first collection event in the newly unprotected Create Date/Time.

- Change the Collection Process Template back to the desired value. When you change the template, the system removes the events and creates new ones using the Create Date/Time.

The collection process cancellation logic will cancel a collection process when its account's debt no longer exceeds a given amount (you define this threshold amount when you set up the system). Rather than compare an account's total debt to the threshold amount, the cancellation logic compares the account's debt that is older than X days to the threshold amount. X is the date specified in Collection Amount Base Date. You can have the system calculate this date for you by entering the age of the arrears in the field embedded in Calculate Date Using ___ Days In Arrears.

Fastpath:

For more information, refer to How Are Collection Processes (and their Events) Canceled?

Enter any Comments about the collection process.

The tree at the bottom of the page shows a variety of information about the account and the collection process including:

- The service agreements linked to the collection process.

- The events linked to the collection process.

- The amount of debt currently associated with the account's debt classes.

- Whether a pay plan exists for the account, or existed at the time the collection process as created.

- The balance for any service agreements linked to the collection process in Inactive status but that have credit balances contributing to the overall debt class arrears for the account.

- A summary of other active collection activities (i.e., collection, severance and write-off processes) associated with the account.

Collection Process - SAs (Service Agreements)

The SA page contains the service agreements whose debt is being collected by the collection process. Open this page using Credit & Collection, Collection Process, SAs.

Fastpath:

The Description of Page section below describes the fields on this page. Refer to How To Perform Common Collection Process Functions for more instructions describing how to use this transaction.

Description of Page

The top portion of every page in this page contains the following information:

Collection Process is a concatenation of summary information about this collection process. It is composed of the name of the main customer on the account, the collection status, the reason code for the collection status, the collection class control name, and the creation date of the process.

ID is the unique system-generated identifier for this collection process.

The Collection SAs scroll contains the service agreement being collected under this collection process. To modify a service agreement linked to the collection process, simply move to a field and change its value. To add a new service agreement, press the + button to insert a row, then fill in the information for each field. The following fields display:

Service Agreement ID identifies the service agreement being collected. Information about the service agreement is displayed beneath the SA ID.

Status defines the state of the service agreement in respect of the collection process. The following values may exist:

Active An Active service agreement is one currently being collected by the collection process. The service agreement will remain in this state until the last event linked to the process is complete OR the customer pays the collection amount on the service agreement OR you want to remove the service agreement from the collection process for whatever reason.

Inactive A service agreement becomes Inactive within the collection process when the last event linked to the process is completed OR the customer pays the collection amount on the service agreement OR you want to remove the service agreement from the collection process for whatever reason

The Collection Amount is the amount of debt that initially triggered the collection process. This will be zero for collection processes that were created manually.

The Amount Still Owing is the amount of debt older than the Collection Amount Base Date defined on the Main page.

The Credit Amount is displayed if the Amount Still Owing is less that zero.

The SA Balances area displays how much is owed for the service agreement. The Days Old and Arrears Amount information shows how old the current balance is. This information will be blank if the current balance is a credit.

Note:

Information about debt balances by age is not applicable to open-item accounts.

Current Balance indicates the amount the customer currently owes for the service. Payoff Balance indicates the amount the customer would owe if they wanted to close the service agreement. This value is only displayed when it differs from the current balance.

Fastpath:

Refer to Current Amount versus Payoff Amount for more information.

Collection Process - Events

The events page contains the activities that will be performed to persuade the customer to pay the outstanding debt. Open this page using Credit & Collection, Collection Process, Events.

Fastpath:

The Description of Page section below describes the fields on this page. Refer to How To Perform Common Collection Process Functions for more instructions describing how to use this transaction.

Note:

We strongly recommend that you understand the information described in How Are Collection Events Completed? before using this page.

Fastpath:

The number and type of events associated with a collection process are defined by the process's collection process template (which is defined on the first page). Refer to Setting Up Collection Process Templates for more information.

Description of Page

The top portion of every page in this page contains the following information:

Collection Process is a concatenation of summary information about this collection process. It is composed of the name of the main customer on the account, the collection status, the reason code for the collection status, the collection class control name, and the creation date of the process.

ID is the unique system-generated identifier for this collection process.

The Collection Events scroll contains the collection events that comprise the collection process. Only one event is displayed at a time. The inner scroll controls the display of the customer contacts that were created by the system when a particular collection event was triggered.

Event Sequence is the unique identifier of the event.

Collection Event Status defines the state of the event. The following diagram shows the possible lifecycle of a collection event:

Collection events are initially created in the pending state.

When the system sees a pending event with a Trigger Date on or before the current date, the system executes the event's activity and completes the event.

You can cancel an individual collection event by setting the status to cancelled .

The Collection Event Type defines the event's activity (e.g., Email sent, a To Do entry is generated, a letter is sent).

Fastpath:

For more information, refer to Setting Up Collection Process Templates.

The Trigger Date defines the date when the system completes (i.e., executes) the event.

Fastpath:

For more information about a collection event's trigger date, see Collection Event Trigger Date.

If the status of the event is complete , the Completion Date is displayed with the date on which the system completes the event. If the status of the event is cancelled , the Canceled Date is displayed with the date on which the event was system canceled.

The Customer Contact information contains information when the event template causes a letter to be generated (because letters are created by customer contacts).

How To Perform Common Collection Process Functions

The topics in this section describe how to perform common collection process maintenance functions. Refer to The Lifecycle Of A Collection Process for more information about collection processes. Refer to The Big Picture Of Collection Processing for high-level information about collection processing.

Contents

How To Create A Collection Process

How To Change Collection Events

How To Cancel A Collection Process

How To Create A Collection Process

99.9% of all collection processes are created by the Account Debt Monitor and require no human intervention before they are executed (refer to How Are Collection Processes Created for information about how the account debt monitor creates collection processes). The other 0.1% are created by users on-line / real time. The following points describe how to create the 0.1%.

- Use Control Central to choose the account that requires a new collection process.

- After the account is populated on Control Central, choose the Collection Process + option on the account context menu to transfer to the collection process transaction in add mode for the account.

- After the Collection Process - Main page appears, specify the appropriate Collection Class Control. Collection Class Control defines the debt class (i.e., the type of debt) associated with the collection process. This is important as it controls which service agreements can be linked to the collection process (every service agreement is associated with a specific debt class). It's important to be aware that if an account's service agreements reference multiple debt classes, a collection process must be created for each debt class that you want to collect. Also be aware that a given debt class for an account may only have one ongoing collection process at any point in time.

- Choose a Collection Process Template. Collection Process Template defines the collection events in the process. You can override these events on the Events page. For more information, refer to Setting Up Collection Process Templates.

- Use Collection Amount Base Date to define the arrears cutoff date that the system uses when it "removes" a SA from a collection process. The system removes a SA from a collection process when its debt older than X is less than or equal to zero. X is the date specified in Collection Amount Base Date. You can have the system calculate this date for you by entering the age of the arrears in the field embedded in Calculate Date Using ___ Days In Arrears.

- Navigate to the SAs page to define the specific service agreement's whose debt is covered by this collection process. You must define at least one service agreement.

- Save the collection process.

How To Change Collection Events

When a collection process is first created, it has one or more collection events. The events are the activities that will be performed to persuade the customer to pay the outstanding debt.

The number and type of events that are created when a collection process is initiated are defined on the collection process's collection process template. The following points describe how to add / change / delete events on a collection process if the defaulted events are not satisfactory.

- Use Control Central to choose the account with the collection process whose events need to be changed.
After the account is populated on Control Central, choose the Collection Process option on the account context menu to transfer to the collection process transaction in update mode for the account.

To add a new event, transfer to the Events tab and press the + button in the Collection Events scroll to add a new event. 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 Collection Event Status of Pending .

- Choose the desired Collection Event Type.

- Use Trigger Date to define the date on which the event should be activated (i.e., completed).
To delete an existing event, transfer to the Events tab and use the scroll arrows to toggle to the desired collection event. When the desired collection event appears, press 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, transfer to the Events tab and use the scroll arrows to toggle to the desired collection event. When the desired collection event appears, make the desired changes.

After all desired changes have been made, save the collection process.

How To Cancel A Collection Process

The Collection Process Monitor will automatically "remove" service agreements from a collection process when their debt has been reduced sufficiently. When all service agreements are "removed" from a collection process, the collection process is canceled. The following points describe how to manually cancel a collection process.

- Use Control Central to choose the account with the collection process to be cancelled.

- After the account is populated on Control Central, choose the Collection Process option on the account context menu to transfer to the collection process transaction in update mode for the account. A list of all collection processes associated with the account appears. If only one collection process exists, it is automatically selected for you.

- On the Main tab, click Cancel.

- When the warning dialog appears, click OK to continue. The collection process and its pending events are canceled.

Severance Process Maintenance

A severance process is a series of events (e.g., field orders, letters, To Do entries) meant to encourage an account to pay its delinquent debt. Linked to the severance process is the specific service agreement being severed. The topics in this section describe the pages on which severance process-related information is maintained.

Fastpath:

For more information about severance processes, refer to The Lifecycle Of A Severance Process And Its Events.

Contents

Severance Process - Main Information

Severance Process - Severance Events

Severance Process - Field Activity/Customer Contact

How To Perform Common Severance Process Functions

Severance Process - Main Information

The Main page contains core severance process information. Open this page using Credit & Collection, Severance Process.

Fastpath:

The Description of Page section below describes the fields on this page. Refer to How To Perform Common Severance Process Functions for more instructions describing how to use this transaction.

Description of Page

The top portion of every page in this page contains the following information:

Severance Process is a concatenation of summary information about this severance process. It is composed of the name of the main customer on the account, the division and SA type, and severance process template code, the process status, the reason code for the process status and the creation date of the process.

Severance Process ID is the unique system-generated identifier for this severance process.

The remaining fields are maintained on the main severance process page.

Service Agreement ID is the system-generated identifier of the service agreement to which the severance process is linked. Adjacent to the ID number is summary information about the SA.

Severance Status defines the state of the severance process. The following values may exist:

Active The system creates a severance process in the Active state. A severance process remains in this state until the last event linked to the process is complete OR the customer pays the collection amount associated with the severance process OR you want to stop the process for whatever reason. The Reason field tells you why a severance process is still in the active state.

Inactive A severance process becomes Inactive when the last event linked to the process is completed OR the customer pays the collection amount on the severance process OR you want to stop the process for whatever reason. The Reason field tells you how a severance process became inactive.

Fastpath:

To completely understand the significance of a severance process' status, refer to The Lifecycle Of A Severance Process And Its Events.

Reason defines how a severance process became Inactive or why a severance process is Active . The following values may exist:

Canceled by User This reason should be used when a user manually inactivates a severance process (for whatever reason).

Canceled by System This reason is specified by the system when it cancels a severance process. The system automatically cancels a severance process when sufficient credits have been posted to the process' service agreement since the process was started.

Events Pending This reason is specified by the system when a process has pending events.

Completed This reason is specified by the system when it completes the last event linked to the severance process.

Severance Process Template defines the severance events in the process. You can override these events on the Severance Events page. If you change the template after events exist, the system will remove the existing events and replace them with the new template's events.

Fastpath:

For more information, refer to Setting Up Severance Process Templates.

Create Date/Time defines the start date/time of the severance process. This is important as it affects the trigger dates of the process' severance events. This field becomes protected after the severance process exists on the database. If you need to change the trigger date on the events you can navigate to the Events tab and change the dates manually. Alternatively, you can perform the following "trick":

- Change the Severance Process Template to something (anything). Doing this causes the Create Date/Time to become unprotected.

- Specify the date of the first severance event in the newly unprotected Create Date/Time.

- Change the Severance Process Template back to the desired value. When you change the template, the system removes the events and creates new ones using the Create Date/Time.

The Collection Amount is the amount of debt that initially triggered the severance process.

The Amount Still Owing is the amount of debt older than the Severance Amount Base Date.

The severance process cancellation logic will cancel a severance process when its SA's debt no longer exceeds a given amount (you define this threshold amount when you set up the system). Rather than compare a SA's total debt to the threshold amount, the cancellation logic compares the SA's debt that is older than X days to the threshold amount. X is the date specified in Severance Amount Base Date. You can have the system calculate this date for you by entering the age of the arrears in the field embedded in Calculate Date Using __ Days In Arrears.

Fastpath:

For more information, refer to How Are Severance Processes (and their Events) Canceled?

Enter any Comments about the severance process.

The tree at the bottom of the page shows a variety of information about the service agreement's account and the severance process including:

- The events linked to the severance process.

- The amount of debt associated with the account's debt classes.

- A summary of other active severance activities (i.e., severance, severance and write-off processes) associated with the service agreement's account.

Severance Process - Severance Events

The events page contains the activities that will be performed to persuade the customer to pay the outstanding debt. Open this page using Credit & Collections, Severance Process, Events.

Fastpath:

The Description of Page section below describes the fields on this page. Refer to How To Perform Common Severance Process Functions for more instructions describing how to use this transaction.

Note:

We strongly recommend that you understand the information described in How Are Severance Events Completed? before using this page.

Fastpath:

The number and type of events associated with a severance process are defined by the process's severance process template (which is defined on the first page). Refer to Setting Up Severance Process Templates for more information.

Description of Page

The top portion of every page in this page contains the following information:

Severance Process is a concatenation of summary information about this severance process. It is composed of the name of the main customer on the account, the SA business unit and SA type, set ID and severance process template name, the process status, the reason code for the process status and the creation date of the process.

ID is the unique system-generated identifier for this severance process.

The Severance Events scroll contains the severance events that comprise the severance process. The grid at the bottom (when visible) shows the events that must be completed before the severance event is triggered. Only one severance event is displayed at a time.

Event Sequence is the unique identifier of the event.

Severance Event Status defines the state of the event.

Fastpath:

For more information, refer to Severance Event Lifecycle.

The Severance Event Type defines the event's activity (e.g., a field order is generated, a To Do entry is generated, a letter is sent).

Fastpath:

For more information, refer to Setting Up Severance Event Templates.

If Dependent on Other Events is turned on, then the event's trigger date is only determined after the event(s) on which it depends are completed. When this switch is on, a grid appears at the bottom of the page in which you define the event(s) on which this event depends.

Fastpath:

For more information about dependent events, see Severance Event Dependencies & Trigger Date.

The Trigger Date defines the date when the system completes (i.e., executes) the event. This field is gray when the event is dependent on the completion of other events.

Fastpath:

For more information about a severance event's trigger date, see Severance Event Dependencies & Trigger Date.

Days After Prev Response defines how a dependent event's trigger date is calculated. The trigger date is set equal to X days after the last dependent event is completed, where X is the number in this field. This field is gray when the event is not dependent on other events.

Fastpath:

For more information about dependent events, see Severance Event Dependencies & Trigger Date.

If the status of the event is complete , the Completion Date is displayed with the date on which the system completes the event. If the status of the event is cancelled , the Canceled Date is displayed with the date on which the event was canceled.

The grid at the bottom of the page contains the events on which this event depends. This grid is only visible when the event is dependent on other events (as defined by the Dependent on Other Events switch). To add additional sequences press the + button (insert row), and define the sequence of the event on which this event depends.

Severance Process - Field Activity/Customer Contact

The Field Activity/Customer Contact page contains information about the objects created when the system completes the event. Open this page using Credit & Collection, Severance Process, FA/CC.

Fastpath:

What happens when a severance event is completed (i.e., executed) is dictated by the severance event's template. Refer to Types Of Severance Events for more information.

Description of Page

The top portion of every page in this page contains the following information:

Severance Process is a concatenation of summary information about this severance process. It is composed of the name of the main customer on the account, the SA business unit and SA type, set ID and severance process template name, the process status, the reason code for the process status and the creation date of the process.

ID is the unique system-generated identifier for this severance process.

The Severance Events scroll contains the severance events that comprise the severance process. The grids show the objects created when the system completes each event.

The Field Activity/SP grid contains information about the field activities that were created when the event was activated. This information will only be populated with the event's event type causes a field activity to be generated.

The Customer Contact area contains information about the customer contacts that were created when the event was activated. This information will only be populated with the event's event type causes a customer contact to be created (note, letters are generated via the creation of a customer contact).

How To Perform Common Severance Process Functions

The topics in this section describe how to perform common severance process maintenance functions. Refer to The Lifecycle Of A Severance Process for more information about severance processes. Refer to The Big Picture Of Severance Processing for high level information about severance processing.

Contents

How To Create A Severance Process

How To Change Severance Events

How To Cancel A Severance Process

How To Create A Severance Process

99.9% of all severance processes are created when a "start severance" collection event is activated by the Collection Event Activator and require no human intervention before they are executed (refer to How Are Severance Processes Created for information about how the account debt monitor creates severance processes). The other 0.1% are created by users on-line / real time. The following points describe how to create the 0.1%.

- Use Control Central to choose the account that requires a new severance process.

- After the account is populated on Control Central, choose the Severance Process + option on the account context menu to transfer to the severance process transaction in add mode for the account. If the account has multiple service agreements, you must select the service agreement to be severed.

- After the Severance Process - Main page appears, specify a Severance Process Template. Severance Process Template defines the severance events in the process. You can override these events on the Events page. For more information, refer to Setting Up Severance Process Templates.

- Use Severance Amount Base Date to define the arrears cutoff date that the system uses when it determines if a severance process can be cancelled. The system cancels a severance process when its SA's debt that is older than X is less than or equal to zero. X is the date specified in Severance Amount Base Date. You can have the system calculate this date for you by entering the age of the arrears in the field embedded in Calculate Date Using ___ Days In Arrears.

- Save the severance process.

How To Change Severance Events

When a severance process is first created, it has one or more severance events. The events are the activities that will be performed to persuade the customer to pay the outstanding debt.

The number and type of events that are created when a severance process is initiated are defined on the severance process's severance process template. The following points describe how to add / change / delete events on a severance process if the defaulted events are not satisfactory.

- Use Control Central to choose the account with the severance process whose events need to be changed.
After the account is populated on Control Central, choose the Severance Process option on the account context menu to transfer to the severance process transaction in update mode for the account.

- To add a new event, transfer to the Events tab and press the + button in the Severance Events scroll to add a new event. 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 Severance Event Status of Pending .

- Choose the desired Severance 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 a) specify the sequences of the dependent events in Event Dependencies and b) specify the number of days after the completion of the last dependent event when the new event should be activated.

- 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, transfer to the Events tab and use the scroll arrows to toggle to the desired severance event. When the desired severance event appears, press 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, transfer to the Events tab and use the scroll arrows to toggle to the desired severance event. When the desired severance event appears, make the desired changes.

After all desired changes have been made, save the severance process.

How To Cancel A Severance Process

The system will automatically cancel a severance process when its service agreement's debt has been reduced sufficiently. Refer to How Are Severance Processes and Events Cancelled for more information.

The following points describe how to manually cancel a severance process.

- Use Control Central to choose the account with the severance process to be cancelled.

- After the account is populated on Control Central, choose the Severance Process option on the account context menu to transfer to the severance process transaction in update mode for the account. A list of all severance processes associated with the account appears. If only one severance process exists, it is automatically selected for you.

- On the Main tab, click Cancel.

- When the warning dialog appears, click OK to continue. The severance process and its events are canceled.

Write-off Process Maintenance

A write-off process is a series of events (e.g., letters, collection agency referrals) meant to encourage an account to pay its unpaid, finaled debt. Linked to the write-off process are the specific service agreements that contributed to the delinquent debt. The topics in this section describe the pages on which write-off process-related information is maintained.

Fastpath:

For more information about write-off processes, refer to The Lifecycle Of A Write Off Process And Its Events.

Contents

Write-off Process - Main Information

Write-off Process - SAs (Service Agreements)

Write-off Process - Events

How To Perform Common Write-off Process Functions

Write-off Process - Main Information

The Main page contains core write-off process information. Open this page using Credit & Collections, Write Off Process.

Fastpath:

The Description of Page section below describes the fields on this page. Refer to How To Perform Common Write-Off Process Functions for more instructions describing how to use this transaction.

Description of Page

The top portion of every page contains the following information:

Write Off Process is a concatenation of summary information about this write-off process. It is composed of the name of the main customer on the account, the write-off status, the reason code for the write-off status, the write-off class control name, and the creation date of the process.

Write Off Process ID is the unique system-generated identifier for this write-off process.

The remaining fields are maintained on the main write-off process page.

Account ID is the system-generated account number. The name of the main customer on the account and its customer class are displayed adjacent.

Write-off Status defines the state of the write-off process. The following values may exist:

Active The system creates a write-off process in the Active state. A write-off process remains in this state until the last event linked to the process is complete OR the finaled debt is paid off OR you want to stop the process for whatever reason.

Inactive A write-off process becomes Inactive when the last event linked to the process is completed OR the finaled debt is paid off OR you want to stop the process for whatever reason. The Reason field tells you how a write-off process became inactive.

Fastpath:

To completely understand the significance of a write-off process' status, refer to The Lifecycle Of A Write Off Process And Its Events.

Reason defines how a write-off process became Inactive or why a write-off process is Active . The following values may exist:

Canceled by User This reason should be used when a user manually inactivates a write-off process (for whatever reason).

Canceled by System This reason is populated by the system when it cancels a write-off process. The system automatically cancels a write-off process when all finaled debt associated with the process' service agreements is paid.

Events Pending This reason is populated by the system when a process has pending events.

Completed This reason is populated by the system when it completes the last event linked to the write-off process.

Write Off Control defines the write-off debt class (i.e., the type of debt) associated with the write-off process. This is important as it controls which service agreements can be linked to the write-off process (every service agreement is associated with a specific write-off debt class). This field is gray when there are service agreements linked to the write-off process.

Note:

Multiple write-off processes may be linked to an account. It's important to be aware that if an account's service agreements reference multiple write-off debt classes, a write-off process is created for each write-off debt class that you want to write-off.

Multiple write-off processes per write-off debt class. A given write-off debt class for an account may have multiple ongoing write-off processes at any point in time. However, a given service agreement may only be on one active write-off process at any point in time.

Write Off Process Template defines the write-off events in the process. You can override these events on the Events page.

Note:

Changing the template. If you change the template when all events are pending , the system will remove the pending events and replace them with the new template's events.

Fastpath:

For more information, refer to Setting Up Write Off Process Templates.

Create Date/Time defines the start date/time of the write-off process. This is important as it affects the trigger dates of the process' write-off events. This field becomes protected after the write-off process exists on the database. If you need to change the trigger date on the events you can navigate to the Events tab and change the dates manually. Alternatively, you can perform the following "trick":

- Change the Write-off Process Template to something (anything). Doing this causes the Create Date/Time to become unprotected.

- Specify the date of the first write-off event in the newly unprotected Create Date/Time.

- Change the Write-off Process Template back to the desired value. When you change the template, the system removes the events and creates new ones using the Create Date/Time.

Enter any Comments about the write-off process.

The tree at the bottom of the page shows a variety of information about the account and the write-off process including:

- The service agreements linked to the write-off process.

- The events linked to the write-off process.

- The amount of debt associated with the account's debt classes.

- A summary of other active collection activities (i.e., collection, severance and write-off processes) associated with the account.

Write-off Process - SAs (Service Agreements)

The SA page contains the service agreements whose unpaid, finaled debt is being managed by the write-off process. Open this page using Credit & Collections, Write Off Process, SAs.

Fastpath:

The Description of Page section below describes the fields on this page. Refer to How To Perform Common Write-Off Process Functions for more instructions describing how to use this transaction.

Description of Page

The top portion of every page in this page contains the following information:

Write Off Process is a concatenation of summary information about this write-off process. It is composed of the name of the main customer on the account, the write-off status, the reason code for the write-off status, the write-off control name, and the creation date of the process.

ID is the unique system-generated identifier for this write-off process.

To modify a service agreement linked to the write-off process, simply move to a field and change its value. To add a new service agreement, press + to insert a row, then fill in the information for each field. The following fields display:

Service Agreement identifies the service agreement being collected. Information about the service agreement is displayed adjacent.

Write Off SA Status defines the state of the service agreement in respect of the write-off process. The following values may exist:

Active An Active service agreement is one currently being collected by the write-off process. The service agreement will remain in this state until the last event linked to the process is complete OR the service agreement is closed (due to payment in full) OR you want to remove the service agreement from the write-off process for whatever reason.

Inactive A service agreement becomes Inactive when the last event linked to the process is completed OR the service agreement is closed (due to payment in full) OR you want to remove the service agreement from the write-off process for whatever reason

The Write Off Amount is the amount of debt that initially triggered the write-off process.

The SA Balances area displays how much is owed for the service agreement. The Days Old and Amount information shows how old the current balance is. This information will be blank if the current balance is a credit.

Current Balance indicates the amount the customer currently owes for the service. Payoff Balance indicates the amount the customer would owe if they wanted to close the service agreement. This value is only displayed when it differs from the current balance.

Fastpath:

Refer to Current Amount versus Payoff Amount for more information.

Write-off Process - Events

The events page contains the activities that will be performed to persuade the customer to pay the outstanding debt. Open this page using Credit & Collections, Write Off Process, Events.

Fastpath:

The Description of Page section below describes the fields on this page. Refer to How To Perform Common Write-Off Process Functions for more instructions describing how to use this transaction.

Note:

We strongly recommend that you understand the information described in How Are Write-off Events Completed? before using this page.

Fastpath:

The number and type of events associated with a write-off process are defined by the process's write-off process template (which is defined on the first page). Refer to Setting Up Write Off Process Templates for more information.

Description of Page

The top portion of every page in this page contains the following information:

Write Off Process is a concatenation of summary information about this write-off process. It is composed of the name of the main customer on the account, the write-off status, the reason code for the write-off status, the write-off class control name, and the creation date of the process.

ID is the unique system-generated identifier for this write-off process.

The Write Off Events scroll contains individual write-off events that comprise the write-off process. Only one event is displayed at a time. The grid contains the customer contacts that were created by the system when a particular write-off event was triggered (if any).

Event Sequence is the unique identifier of the event.

Write Off Event Status defines the state of the event. The following diagram shows the possible lifecycle of a write-off event:

Write-off events are initially created in the pending state.

When the system sees a pending event with a Trigger Date on or before the current date, the system executes the event's activity and completes the event.

You can cancel an individual write off event by setting the status to cancelled .

The Write Off Event Type defines the event's activity (e.g., the related debt is referred to a collection agency, a To Do entry is generated, a letter is sent).

Fastpath:

For more information refer to Setting Up Write Off Process Templates.

The Trigger Date defines the date when the system completes (i.e., executes) the event.

Fastpath:

For more information about a write-off event's trigger date, see Write-off Event Trigger Date.

If the status of the event is complete , the Completion Date is displayed with the date on which the system completed the event. If the status of the event is cancelled , the Canceled Date is displayed with the date on which the event was cancelled.

The Customer Contact information contains information when the event template causes a letter to be generated (because letters are created by customer contacts).

How To Perform Common Write-off Process Functions

The topics in this section describe how to perform common write-off process maintenance functions. Refer to The Lifecycle Of A Write-off Process for more information about write-off processes. Refer to The Big Picture Of Write-off Processing for high level information about write-off processing.

Contents

How To Create A Write-off Process

How To Change Write Off Events

How To Cancel A Write Off Process

How To Create A Write-off Process

99.9% of all write-off processes are created by the Write-Off Monitor and require no human intervention before they are executed (refer to How Are Write-off Processes Created for information about how the account debt monitor creates write-off processes). The other 0.1% are created by users on-line / real time. The following points describe how to create the 0.1%.

- Use Control Central to choose the account that requires a new write-off process.

- After the account is populated on Control Central, choose the Write-off Process + option on the account context menu to transfer to the write-off process transaction in add mode for the account.

- After the Write-off Process - Main page appears, specify the appropriate Write Off Control. Write Off Control defines the debt class (i.e., the type of debt) associated with the write-off process. This is important as it controls which service agreements can be linked to the write-off process (every service agreement is associated with a specific debt class). It's important to be aware that if an account's service agreements reference multiple write-off debt classes, a write-off process must be created for each write-off debt class that you want to collect.

- Choose a Write Off Process Template. Write Off Process Template defines the write-off events in the process. You can override these events on the Events page. For more information, refer to Setting Up Write-off Process Templates.

- Navigate to the SAs page to define the specific service agreement's whose debt is covered by this write-off process. You must define at least one service agreement.

- Save the write-off process.

How To Change Write Off Events

When a write-off process is first created, it has one or more write-off events. The events are the activities that will be performed in the course of the write-off process.

The number and type of events that are created when a write-off process is initiated are defined on the write-off process's write-off process template. The following points describe how to add / change / delete events on a write-off process if the defaulted events are not satisfactory.

- Use Control Central to choose the account with the write-off process whose events need to be changed.
After the account is populated on Control Central, choose the Write Off Process option on the account context menu to transfer to the write-off process transaction in update mode for the account.

To add a new event, transfer to the Events tab and press the + button in the Write Off Events scroll to add a new event. 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 Write Off Event Status of Pending .

- Choose the desired Write Off Type Code.

- Use Trigger Date to define the date on which the event should be activated (i.e., completed).
To delete an existing event, transfer to the Events tab and use the scroll arrows to toggle to the desired write-off event. When the desired write-off event appears, press 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, transfer to the Events tab and use the scroll arrows to toggle to the desired write-off event. When the desired write-off event appears, make the desired changes.

After all desired changes have been made, save the write-off process.

How To Cancel A Write Off Process

The system will automatically "remove" service agreements from a write-off process when the close (i.e., when their balance becomes zero). When all service agreements are "removed" from a write-off process, the write-off process is cancelled. Refer to How Are Write off Processes and Events Cancelled for more information.

The following points describe how to manually cancel a write-off process.

- Use Control Central to choose the account with the write-off process to be cancelled.

- After the account is populated on Control Central, choose the Write Off Process option on the account context menu to transfer to the write-off process transaction in update mode for the account. A list of all write-off processes associated with the account appears. If only one write-off process exists, it is automatically selected for you.

- On the Main tab, click Cancel.

- When the warning dialog appears, click OK to continue. The write off process and its pending events are canceled.

Writing Off Uncollectable Debt

The Write-off pages described in this section describe the transaction used to manually transfer bad debt to a write-off service agreement.

Contents

Write Off - Main

How To Manually Write-Off Debt

Write Off - Write Off SAs

Write Off - Main

Most write-offs happen behind-the-scenes as part of the automated write-off processing. If you need to perform a partial write-off or cannot wait for the automated process, open Credit & Collection, Write Off.

Fastpath:

Refer to The Big Picture of Write Off Processing for background information about the write-off process.

Description of Page

Account contains the name of the main customer on the account. The Account ID is the account whose debt is being written off.

The Candidate SAs scroll contains one row for each of the account's service agreements that is eligible for write-off. The system displays the respective age and amount of each SA's debt. The accumulated total of all such debt appears in Write Off Amount. The checkbox adjacent to this field is used to confirm that you want to write-off the adjacent debt.

When you click the Create button, the system writes off the selected debt by executing the write-off algorithm that's plugged in on the account's customer class. Refer to The Ramifications of Write Offs in the General Ledger for an explanation of how the base-package algorithm works.

How To Manually Write-Off Debt

To manually write-off debt:

- Select the Account in question on Write Off - Main.

- Select the debt to be written off for each Candidate SA. You do this by turning on the checkbox adjacent to Write Off Amount. You can also vary the amount of the Write Off Amount.

- Click the Create button.

Write Off - Write Off SAs

The Write Off SAs page shows all write-off service agreements linked to the account along with their respective current and payoff balance. Use Credit & Collection, Write Off, Write Off SAs to open this page.

Description of Page

Account contains the name of the main customer on the account. The Account ID is the account associated with the WO SAs displayed below.

The grid contains an entry for every write-off service agreement linked to the account. The following information is displayed for each write-off service agreement:

- The service agreement's SA Information is displayed.

- Current Balance contains the WO SA's current balance (i.e., the amount written off).

- Payoff Amount contains the WO SA's payoff balance (i.e., the amount written off).

Note:

Write off SA. There is a field on SA type called Special Role Flag. Only those SA types with a role of Write Off are displayed.

Collection Referral

The Collection Referrals page contains information about an account's debt that has been referred to a collection agency.

Fastpath:

Refer to How Do Collection Agency Referrals Work? for more information about how the system creates and maintains collection agency referrals as part of the automated write off processing. In theory, you need only access this page if you need to override the automated processing.

Open Credit & Collections, 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.

The System Generated switch is on for those collection agency referrals created as part of the automated write-off processing. Refer to How Do Collection Agency Referrals Work? for more information.

Payment Arrangements and Pay Plans

Payment arrangements and pay plans are very similar concepts in that they are both used to payoff debt. This section describes each method.

Note:

To distinguish between payment arrangements and pay plans, it is helpful to understand some terminology: 1) an agreement with a customer to pay off their debt as part of their future bills (sometimes referred to as "current bill plus") is a payment arrangement , 2) an agreement with specifically scheduled payments is called a pay plan .

Contents

Setting Up Payment Arrangements

Setting Up Pay Plans

Setting Up Payment Arrangements

A payment arrangement is an agreement with a customer to payoff severely overdue debt in installments. Bills sent to customers with payment arrangements contain charges for both their current services and their payment arrangement installment amount. Refer to The Big Picture Of Payment Arrangements for information about the financial ramifications of payment arrangements and for a description of how the system monitors payment arrangements.

The topics in this section describe how to set up a payment arrangement and how to break a payment arrangement (if a customer doesn't fulfill their obligations).

Contents

Pay Arrangement - Main

How To Set Up A Payment Arrangement

How To Add Additional Debt To A Payment Arrangement

How To Break A Payment Arrangement

How To Cancel A Payment Arrangement

Pay Arrangement - History

Pay Arrangement - Main

This page allows you to set up a payment arrangement. When you create a payment arrangement, the system performs the following functions:

- It creates a payment arrangement service agreement (PA SA). It sets the installment amount on this service agreement equal to the installment amount specified on this page.

- It transfers delinquent debt from each delinquent service agreement(s) to the new PA SA.

- As it transfers the debt to the PA SA, it creates synchronizing adjustments to reduce the PA SA's current balance by the amount transferred. Why? Because when delinquent debt is transferred to the PA SA, its current balance increases. Because current balance contains the amount the customer currently owes, this balance must be reduced because the customer is going to payoff the debt in installments (and therefore they don't currently owe anything on the PA SA).

Note:

Payment Arrangement Algorithm. The system only performs the above steps if the new PA SA's SA Type does not reference a Payment Arrangement algorithm. If your implementation uses a Payment Arrangement algorithm, then the logic performed when a payament arrangement SA is created will depend on this algorithm.

You could do the above functions by adding a new service agreement (using the service agreement page) and creating transfer adjustments (using the adjustment page). However, this is tedious. Rather, open Credit & Collection, Pay Arrangement to set up or add additional debt to a payment arrangement.

Description of Page

SA (service agreement) Info and SA ID are displayed on every page. These values only appear after the payment arrangement service agreement (PA SA) exists on the database. The ID is a system assigned random number that stays with the payment arrangement service agreement for life. The SA Info is a concatenation of important details about the payment arrangement service agreement and its account.

The Current Balance that appears beneath SA Info contains the PA SA's current balance. When you initially set up a PA SA this balance will be zero. It is only non-zero if the customer has not paid a billed installment.

Payoff Balance beneath SA Info contains the PA SA's payoff balance. The payoff balance is the total amount to be paid off over the PA SA's life. It is only non-zero after delinquent funds have been transferred to the PA SA. This balance is only displayed when it differs from the Current Balance.

Fastpath:

Refer to Current Amount versus Payoff Amount for more information.

Account contains the name of the main customer on the account. Account ID is the account associated with the PA SA.

The occurrences of Current and Payoff Balance below Account are the account's respective balances. These values are displayed to help you confirm exactly how much the customer currently owes versus how much they will have to payoff over time (remember, after you transfer funds to a payment arrangement, the amount transferred is reduced from the account's current balance).

The Candidate SAs scroll contains one row for each of the account's service agreements with aged debt. The system displays the respective age and amount of each SA's debt. All debt that is checked will be transferred to the PA SA when you click Create.

Warning:

The system automatically indicates that all debt that isn't "new" (i.e., debt that the customer has seen on their bills) should be transferred to the payment arrangement. It does this by checking each parcel of aged debt.

Total is the sum of ALL current balances (not just the checked amounts) from all candidate SAs.

The next two fields are used to populate the arrangement amount (i.e., the amount the customer will be billed on each bill).

- The Installments field exists to calculate the Arrange Amount (the next field) when a time period has been stipulated. Simply enter the number of installments and tab out. When you tab out of the field, the system sets the Arrange Amount equal to New Payoff Balance / Installments.

Note:

Arrange Amount may not add up. You will note that the Arrange Amount is rounded up so that if you multiply the number of installments by the calculated installment amount, the result will be greater than the PA SA's payoff amount. Don't worry - only the actual dollar amount of the PA SA's total debt will be billed by the system. The last installment will be slightly lower than the other installments.

- Use the Arrange Amount field to define the payment arrangement's installment amount if a specific dollar amount has been stipulated. For example, if the customer agrees to pay off their delinquent debt by paying an additional $50 on each bill, you'd enter "50" in this field. Note - If you enter a dollar amount in this field and tab out, the system will calculate the number of installments and display the number in the Installments field.

New Payoff Balance contains the PA SA's payoff balance. This is the total amount of debt that will be paid off over the lifetime of the PA SA. This value equals the current payoff balance on the PA SA plus all selected debt from the Candidate SAs scroll.

Define the CIS Division and SA Type of the payment arrangement service agreement.

Note:

Payment arrangement SA types. There is a field on SA type called Special Role Flag. Only those SA types with a role of Payment Arrangement may be selected.

Clicking Create (or Change)causes the system to perform the following:

- It adds / updates a payment arrangement service agreement (PA SA). It sets the installment amount on this service agreement equal to the installment amount specified on the page.

- It transfers delinquent debt from the delinquent service agreement(s) to the PA SA. The adjustment type used to transfer these funds is defined on the PA SA's SA type.

- It reduces the current balance on the PA SA by the amount of debt transferred to the PA SA. Why? Because when delinquent debt is transferred to the PA SA, its current balance increases. Because current balance contains the amount the customer currently owes, this balance must be reduced because the customer is going to pay off the debt in installments (and therefore they don't currently owe anything). The adjustment type used to transfer these funds is defined on the PA SA's SA type.

Note:

Payment Arrangement Algorithm. The system only performs the above steps if the new PA SA's SA Type does not reference a Payment Arrangement algorithm. If your implementation uses a Payment Arrangement algorithm, then the logic performed when a payament arrangement SA is created will depend on this algorithm.

You can transfer to the History page to view the transfer adjustments that were created by the system when it transferred the selected debt to the PA SA.

Clicking Break causes the PA SA to become broken. Please refer to the note below for what transpires when a PA is broken.

Note:

Break logic is in a plug-in. Please be aware that the logic that is executed when a payment arrangement is broken exists in a plug-in algorithm (plugged-in on the PA SA's SA type). An implementation can use either a Break Payment Arrangement algorithm which the system calls when a payment arrangement is broken, or the Payment Arrangement algorithm which the system calls when a payment arrangement is created, canceled or broken. These two algorithms are mutually exclusive on the SA Type.

Break Payment Arrangement Algorithm. The base package algorithm expires the PA SA and cancels all related frozen adjustments, returning the debt to the original service agreements. Because this logic is in a plug-in, you can develop alternative logic and plug it in if the base package logic is not satisfactory.

How To Set Up A Payment Arrangement

To set up a new payment arrangement:

- Select the Account in question.

- Select the debt to be transferred to the payment arrangement (by turning on/off the checkboxes adjacent to the Candidate SA's amounts).

- Enter the number of Installments and the total Arrange Amount.

- Define the CIS Division and SA Type of the new payment arrangement service agreement.

- Click the Create button.

How To Add Additional Debt To A Payment Arrangement

To transfer additional debt to an existing payment arrangement:

- Select the SA ID of the existing payment arrangement.

- Select the debt to be transferred to the payment arrangement (by turning on/off the checkboxes adjacent to the Candidate SA's amounts).

- Enter the number of Installments and the total Arrange Amount.

- Click the Create button.

Note:

After transfer. After transferring the funds to the payment arrangement service agreement, confirm the account's payoff and current balances make sense (the payoff balance is the total amount of debt that the account will eventually have to payoff, the current balance is how much they currently owe, i.e., the amount that credit and collections monitors). The account's payoff and current balances are displayed in the page's second section. If you do not understand the difference between payoff balance and current balance, refer to Current Amount versus Payoff Amount.

How To Break A Payment Arrangement

You would break a payment arrangement when a customer doesn't make the agreed payments. Typically, your credit and collections processes will break a payment arrangement behind-the-scenes. Refer to The Big Picture Of Payment Arrangements for information about how the system monitors payment arrangements.

If you want to manually break a payment arrangement simply select the SA ID of the existing payment arrangement and click the Break button.

How To Cancel A Payment Arrangement

You would cancel a payment arrangement if you made a mistake and never intended to set up the payment arrangement in the first place. To cancel a payment arrangement

- Select the SA ID of the existing payment arrangement and navigate to the History tab.

- Click the Cancel button to cancel the transfer adjustments that were used to transfer debt to the payment arrangement from the customer's regular service agreements.

- Next, navigate to the payment arrangement SA's (PA SA) financial history page (using the service agreement context menu). You will see that there are a few non-canceled adjustments (these were used to change the PA SA's current balance after debt was transferred to the PA SA). Cancel these adjustments by drilling down on these adjustments and then click the Cancel button on the adjustment maintenance transaction.

- Finally, display the PA SA on the service agreement maintenance transaction and cancel the payment arrangement.

Note:

Payment Arrangement Algorithm. If the payment arrangement SA's SA Type references a Payment Arrangement algorithm, then the logic performed when the PA SA is canceled will depend on this algorithm.

Pay Arrangement - History

Open Credit & Collection, Pay Arrangement, History to view the transfer adjustments that were created by the system when it transferred the selected debt to the PA SA.

Description of Page

SA (service agreement) Info and ID are displayed on every page in this page. These values only appear after the payment arrangement service agreement (PA SA) exists on the database. The ID is a system-assigned random number that stays with the service agreement for life. The SA Info is a concatenation of important details about the service agreement and its account.

Current Balance beneath SA Info contains the PA SA's current balance. When you initially set up a PA SA this balance will be zero. It is only non-zero if the customer has not paid a billed installment.

Payoff Balance beneath SA Info contains the PA SA's payoff balance. The payoff balance is the total amount to be paid off over the PA SA's life. It is only non-zero after delinquent funds have been transferred to the PA SA. This balance is only displayed when it differs from the Current Balance.

Fastpath:

Refer to Current Amount versus Payoff Amount for more information.

Account contains the name of the main customer on the account. Account ID is the account associated with the PA SA.

The occurrences of Current and Payoff Balance below Account are the account's respective balances. These values are displayed to help you confirm exactly how much the customer currently owes versus how much they will have to payoff over time (remember, after you transfer funds to a payment arrangement, the amount transferred is reduced from the account's current balance).

The Adjustment Details area contains one row for each transfer adjustment used to transfer delinquent debt to the PA SA. Click the Go To button to transfer to the adjustment page to view the details of an adjustment (or to cancel the adjustment if you want to reinstate the debt on the originating service agreement).

Total Frozen Adj is the total amount of debt transferred to the payment arrangement that has not been canceled.

Clicking Cancel causes the system to cancel all related frozen adjustments, returning the debt to the original service agreements. You must specify the cancel reason by selecting it from the drop down list when Payment Arrangement Cancellation window is displayed.

Total Canceled Adj is the total amount of debt transferred to the payment arrangement that has been canceled.

Setting Up Pay Plans

A pay plan (PP) is an agreement with a customer to make specific payments on specific dates (as opposed to payment arrangements where the customer makes fixed payments as part of their regular bills).

Consider the following situations that would require a pay plan:

- A customer makes a request to payoff severely overdue debt in one or more installments. The existence of the pay plan insulates the portion of the debt covered by the plan from C&C processing (specifically, from the account debt monitor).

- A commercial or industrial customer cannot or will not post a deposit. This type of pay plan is not specifically paying off past debt; rather, it can be viewed as an installment plan to prepay a regular service agreement.

The topics in the following section describe how to set up a pay plan.

Contents

Pay Plan - Main

How To Set Up A Pay Plan

Reviewing Pay Plans

Pay Plan - Main

The pay plan transaction allows you to set up a pay plan. When you create a pay plan, the system performs the following functions:

- It creates an active pay plan using the pay plan type entered.

- It defaults the customer as the payor if no 3 rd party is defined.

Fastpath:

Refer to The Big Picture Of Pay Plans for information about the financial ramifications of pay plans and for a description of how the system monitors pay plans.

Open Credit & Collection, Pay Plan to maintain a customer's pay plans.

Description of Page

Pay Plan and Pay Plan ID only appear after the pay plan is added to the database. Pay Plan ID is a system-assigned random number that stays with the pay plan for life. Pay Plan is a concatenation of important details about the pay plan.

Account ID identifies the account of the customer for which the pay plan exists. This field is protected once the pay plan is Active .

The Status displays the status of the pay plan. Refer to The Lifecycle Of A Pay Plan for more information about a pay plan's status.

Created by displays the id of the user who created the pay plan and the date and time on which it was created.

Clicking the Cancel button causes the pay plan's status to become cancelled .

Last Updated by displays the id of the user who last modified the pay plan and the date and time on which it was changed.

Select a Pay Plan Type. The Pay Plan Type defines the Debt Class whose debt is insulated by the pay plan. The account's Current Balance in this debt class appears beneath as well as the portion that is considered Delinquent Debt.

If a 3 rd party is responsible for the pay plan's payment, Third Party Payor must be checked, and the associated 3 rd party selected.

The Payor Account Id contains the account ID and name of the person responsible for making the pay plan's payments. If a Third Party Payor is responsible, the payor's account appears; otherwise the account whose debt is insulated by the pay plan appears.

The Start Date defines the first day on which the pay plan is tracked; it defaults to the current date.

Pay Method defines the manner in which the customer intends to fulfill payments under this pay plan.

Note:

Significance of payment method. A pay method can have a grace period associated with it. This period controls when a scheduled payment is considered to be missed. For example, a pay method of "postal" might have a grace period of 3 days. This would give the customer 3 extra days to make the scheduled payments before the pay plan is broken.

In addition to grace period, pay method also control if the system will automatically create an automatic payment on the scheduled payment date. If the pay method so indicates AND the account has been set up for automatic payment, the PPAPAY background process will create Automatic Payments on the scheduled payment date.

The Scheduled Payments grid contains the pay plan's scheduled payments. The Scheduled Date and Scheduled Amount must be entered for each scheduled payment. The Total Amount of the scheduled payments is displayed at the bottom.

Free format Comments can be entered to describe any special notes about the pay plan.

How To Set Up A Pay Plan

To set up a new pay plan:

- Select the Account in question on Pay Plan - Main.

- Select the Pay Plan Type for the type.

- Identify a 3 rd Party Payor if there is one.

- Select a Pay Method.

- Enter one or more Scheduled Payments. The Total Amount of the scheduled payments should cover the customer's Delinquent Debt if you want the pay plan to protect the customer from additional credit and collection activity.

- Click the Save button.

Reviewing Pay Plans

In addition to using this maintenance page for reviewing pay plans, Control Central has a pay plan tree that can be used to view pay plan history, including current status. Refer to Control Central Pay Plan Tree for more information.

Financial Transactions

In this section, we describe the financial transactions generated as a result of your bills, payments and adjustments.

Contents

The Big Picture Of Financial Transactions

Financial Transaction

Account Financial History

Account Bill / Payment History

SA Financial History

SA Non-Accrual 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.

Contents

Bill Segment Financial Transactions

Payment Segment Financial Transactions

Adjustment Financial Transactions

Financial Transactions And Aged Debt

Current Balance versus Payoff Balance

The Source Of GL Accounts On Financial Transactions

Obscure Things That Can Happen

The Big Picture of Balance Control

The GL Interface

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 service agreement'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 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 service agreement'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 Payment Details.

Adjustment Financial Transactions

An adjustment has a related financial transaction. The financial transaction contains the financial effects of the adjustment on the service agreement'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 Adjustment Details.

Financial Transactions And Aged Debt

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, its service agreement's debt is impacted. It is important to stress the following in respect of this impact:

- The FT's GL details will be interfaced to the GL when the GL interface next executes.

- If the FT decreases the amount of debt, the customer's aged debt is affected immediately regardless of whether the FT appears on a bill.

- If the FT increases the amount of debt, the amount the customer owes from an aged debt perspective may or may not be affected by the FT. There is a switch on an FT called New Charge that controls the arrears behavior. If this switch is on, the customer's aged debt will not reflect the FT amount until the FT is swept onto a bill. The moment the FT is swept onto the customer's bill, the debt starts aging. If this switch is off, the date on which the FT starts aging must be defined in the Arrears Date field.

- The amount a customer owes in total is immediately affected by the FT regardless of whether the FT appears on a bill. This means that the amount of aged debt may not be in sync with the total amount owed. This seems odd, but is useful from a credit and collections perspective. You see, you probably don't want to start aging a FT until the customer has actually seen it.

Fastpath:

For more information, refer to Financial Transactions Created Between Bills.

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.

Contents

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.

Contents

A Stopped Service Agreement May Be Closed

A Closed Service Agreement May Be Reactivated

A Write-Off Process May Be Deactivated If The SA Is Closed

A Reactivated Service Agreement May Be Closed

A Collection Process May Be Canceled When A Credit FT Is Frozen

A Severance Process May Be Canceled When A Credit FT Is Frozen

One Or More Algorithms May Be Executed

A Stopped Service Agreement May Be Closed

If an FT causes a Stopped SA's current and payoff balances to become zero, the system closes the service agreement (i.e., the service agreement's status becomes Closed ).

A Closed Service Agreement May Be Reactivated

After a service agreement 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 service agreement. These financial transactions could cause the current and/or payoff balances to become non-zero. If this happens, the system reactivates the service agreement (i.e., the service agreement's status becomes reactivated ).

When a service agreement becomes reactivated, it becomes eligible for review by the write-off process monitor (when it next runs). The write-off process monitor will, in all likelihood, start a write-off process for the reactivated service agreement.

Financial events that can be linked to a closed service agreement 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 Write-Off Process May Be Deactivated If The SA Is Closed

When a service agreement becomes Closed , it will be removed from any ongoing write-off processes. This removal could cause the write-off process to become Inactive (if this is the last service agreement linked to the write-off process). The inactivation of the write-off process, could, in turn, cause collection agency referrals associated with the write-off process to be cancelled.

A Reactivated Service Agreement May Be Closed

After a service agreement 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 closes the service agreement (i.e., the service agreement's status becomes Closed ).

All types of financial transactions can be posted to a Reactivated service agreement.

A Collection Process May Be Canceled When A Credit FT Is Frozen

Periodically, the system determines if an account's debt violates your collection criteria. If so, a collection process is created using the violated criteria's collection process template.

The Collection Process Monitor reviews an active collection process whenever one of its service agreements' debt is reduced. Financial events that can cause service agreement debt to be reduced are:

- The cancellation of a bill segment

- The freezing of a payment segment

- The freezing of an adjustment that credits a service agreement

At review time, the Collection Process Monitor removes any service agreement from a collection process when the service agreement has no debt older than the arrears date on the collection process. When all service agreements are removed, the collection process is cancelled.

Fastpath:

Refer to The C&C Monitors for more information about debt monitoring.

A Severance Process May Be Canceled When A Credit FT Is Frozen

If the customer does not respond to a collection process's prodding, the system creates a severance process for each delinquent service agreement associated with the collection process.

The system reviews an active severance process whenever its service agreements' debt is reduced. Financial events that can cause service agreement debt to be reduced are:

- The cancellation of a bill segment

- The freezing of a payment segment

- The freezing of an adjustment that credits a service agreement

At review time, the system determines if the service agreement has no debt older than the arrears date on the severance process. If so, the system looks at the severance process' severance process template:

- If the severance process template indicates that the process can be Used to sever service, the system cancels all pending severance events and deactivates the severance process. Note: the only severance processes that are not used to sever service are those that request reconnection of a cut service.

- If the canceled process has field activities,

- If the field activities are not linked to a field order and are still in the pending status, the system cancels the field activities.

- Otherwise, the system generates worklist entries to alert an operator that field activities have been dispatched. The operator must determine how to handle these activities because they could already be scheduled for dispatch (or completed!).

Note:

Real time cancellation. Unlike collection processes, the system cancels severance processes real time (i.e., there is no equivalent of the collection process monitor for severance processes). Why are severance processes canceled real time? Because a severance process may have events that create field activities to sever service. These events need to be canceled the moment the FT is frozen, we can't wait until a background process runs. This means that if a customer pays in person for a service agreement that is pending severance, the system will cancel the process and its field activities (if any) the moment the payment is entered.

Fastpath:

Refer to The C&C Monitors for more information about debt monitoring.

One Or More Algorithms May Be Executed

If the FT is linked to a service agreement whose SA type has Freeze Algorithms, these algorithms will be executed when the FT is frozen. Because you can code whatever you please in an algorithm, anything could happen. Examples of such algorithm include:

- An algorithm that routes consumption to third party service providers when a bill is frozen (refer to STG SND CONS for more information). This type of algorithm would be plugged in on SA types whose consumption can be interfaced to other service providers.

- A bill message can be added to the account when the system detects that its deposit has been paid in full (refer to DEP PIF MSG for more information). This type of algorithm would be plugged in on deposit SA types.

In addition, FT freeze algorithms can also be defined on an account's customer class. Because you can code whatever you please in an algorithm, anything could happen. An example of such an algorithm is one that cancels match events when an FT is cancelled (refer to CNCL FT MEVT for more information). This type of algorithm would be plugged in on customer classes associated with open item customers.

The Big Picture of Balance Control

The balance control processes are used to check the financial integrity of your system. The contents of this section describe how these processes work.

Contents

The Balance Control Background Processes

Balance Control Information Is Available Online

The Balance Control Background Processes

The following diagram illustrates the balance control background processes:

Contents

BCGNEW - Create A New Balance Control Group

BCASSIGN - Assign New Financial Transactions A Balance Control Group

BCGSNAP - Insert BC Members And Check Financial Integrity Of All FTs

Consider A Backup At This Point

BCGNEW - Create A New Balance Control Group

This process creates a Pending balance control group if one doesn't already exist. You may wonder why an entire process is dedicated to such a trivial task. The reason is because the next process, BCASSIGN, is a multi-threaded (i.e., parallel) process and we only need one Pending balance control group regardless of the number of threads used to assign balance control ID's to financial transactions.

BCASSIGN - Assign New Financial Transactions A Balance Control Group

This multi-threaded (i.e., parallel) process assigns the Pending balance control group to new FTs whose freeze date/time is before the create date/time of the balance control record.

BCGSNAP - Insert BC Members And Check Financial Integrity Of All FTs

This process performs the following two functions:

- It summarizes new financial transactions under the current Pending balance control group as follows:

- It creates a balance control member for every combination of Division, SA Type and FT Type referenced on the financial transactions belonging to the balance control group.

- It updates each balance control member with the following information:

- The number of financial transactions (FTs)

- The sum of the total amounts on the FTs in this balance control group.

- The sum of the current amounts on the FTs in this balance control group.

- The sum of the total amounts from all FTs (in this and all other balance control groups).

- The sum of the current amounts from all FTs (in this and all other balance control groups).

- It sets the status of the balance control group to Complete .

- It checks the integrity of the financial transactions in each historical Balance Control Group. It does this by summarizing EVERY financial transaction throughout time and determining if the sums are in sync with the values maintained on the balance control members. If integrity problems are detected, a detailed error message is displayed on the run control associated with the process.

If you opt to run the balance control processes on a nightly basis, you will find that the verification processing will take longer every night (because there are more financial transactions over time). In order to deal with this issue, the BCGSNAP process has a parameter that allows you to control which of the above functions is implemented (it's call VERIFY-ONLY-SW). In order to speed nightly processing, run this process with the switch set to "G" (this causes new financial transactions to be summarized under a new balance control). Then, once a week (or month), run this process with the switch set to "Y" (this checks the financial integrity of all financial transactions in the system).

If you run the balance control processes less frequently, you can set the VERIFY-ONLY-SW to "N" (this causes both of the above functions to execute).

Consider A Backup At This Point

We recommend you backup your database AFTER you run the above processes. Why? So that if a financial integrity problem is spotted in the future, you can compare the current database against the backup to see what changed.

Balance Control Information Is Available Online

Your internal auditors may be interested in the total number and amount of financial transactions that have been posted since a given point in time. You can use the Balance Control page to see this information.

The GL Interface

The following diagram illustrates the GL Interface.

Contents

GLASSIGN - Assign GL Account Numbers To GL Details

GLS - Prepare FTs for Download

GLDL - Create General Ledger Download Flat File

GLASSIGN - Assign GL Account Numbers To GL Details

The GLASSIGN process assigns GL account numbers to the GL details associated with financial transactions. GL account numbers are assigned as follows:

- Every GL detail references a distribution code.

- Every distribution code references a GL assignment algorithm. The base package algorithm simply uses the default GL account associated with the distribution code. However, you can construct your own algorithm(s) to assemble your GL account numbers in your desired fashion. Refer to Setting Up Distribution Codes for more information about the GL format algorithm.

- The GLASSIGN process simply calls each GL's details distribution code's GL assignment algorithm and updates the GL detail with the result (i.e., the GL account number). This GL account number is then used by the GLDL process when it creates the consolidated journal entry that's interfaced to the GL.

Note:

If incorrect GL account numbers get assigned to GL details... If you do not plug in the correct algorithm or your algorithm is wrong, you can correct the GL account numbers that are assigned to the GL details. How? Write a simple program that resets the GL account numbers on the erroneous GL details. Then run GLASSIGN . GLASSIGN will re-execute the distribution code GL assignment algorithm and refresh the account number accordingly.

GLS - Prepare FTs for Download

The GLS process creates FT download staging records for all FTs that are ready to be posted to the GL (the FT download staging records are stored on the FT/Process table). Each FT download staging record is marked with a batch process ID and run number.

- The batch process ID is the process responsible for creating the flat file that contains the consolidated journal entry that is interfaced to your general ledger. The batch process ID is defined on Installation Options - Financial. The system comes with a single GL download program ( GLDL - Create General Ledger Download Flat File). The GL account numbers are provided by the GL account algorithms that are specified on the distribution codes. Refer to Setting Up Distribution Codes for more information about the GL account algorithm.

- The run number is the batch process ID's current run number.

This process also changes the status of the FT to distributed . You may not change the FT's GL details after this time.

GLDL - Create General Ledger Download Flat File

The GLDL process creates the flat file that contains the consolidated journal entry that is interfaced to your general ledger. One header and multiple detail records are created as described below. At the conclusion of the batch process, a validation is performed to compare debits against credits. If they are not equal, the process terminates with an error.

Contents

Header Record Layout

Detail Record Layout for GLDL

Header Record Layout

Field Name

Format

Source/Value/Description

REC_TYPE

A1

1 ( 1 is used for header records )

BATCH_CD

A8

The code for the batch process that created the file. (This value will always be 'GLDL'.)

BATCH_NBR

N10

The batch process will be run many times. This field indicates which of those runs produced a particular output file. This may be thought of as an instance identifier for the batch process.

BATCH_RERUN_NBR

N10

Any given instance of the GLDL batch process may be re-run at any time. If this instance has been re-run, this field will be populated with a number indicating how often.

EXTRACT_DTTM

A26

The date and time of the run that created a particular output file.

DETAIL_REC_CNT

N12

The number of details records

DETAIL_REC_TOTAL_DR

N13.2

This is the sum of FINANCIAL_AMOUNTs from all detail records that were greater than zero (debits).

DETAIL_REC_TOTAL_CR

N13.2

This is the sum of FINANCIAL_AMOUNTs from all detail records that were less than zero (credits).

Detail Record Layout for GLDL

Note:

A record is created for each unique occurrence of REC_TYPE, GL_DIVISION, CURRENCY_CD, GL_ACCOUNT and ACCT_PERIOD. If a given GL account has debit and credit FINANCIAL_AMOUNTs, two records will be created - one shows the debit amount, the other shows the credit amount.

Field Name

Format

Source/Value/Description

REC_TYPE

A1

2 ( 2 is used for detail records )

GL_DIVISION

A5

This is the GL Division from the CI_FT record. It determines a) which Accounting Calendar will be used to calculate the Accounting Period (below) and b) the currency of the FT.

CURRENCY_CD

A3

The currency in which the Amount is denominated.

GL_ACCOUNT

A254

Contains the GL account number as supplied by the distribution code's GL account algorithm.

ACCT_PERIOD

A6

An accounting period in the format YYYYPP where YYYY is the fiscal year and PP is the accounting period. This is derived from the GL detail's FT's accounting date and GL division.

FINANCIAL_AMOUNT

N13.2

This is the debit or credit amount. Debits are represented by positive numbers; credits are represented by negative numbers. If a given GL account has debit and credit entries, two records will be created - one shows the debit amount, the other shows the credit amount.

STAT_CODE

A8

This is the GL distribution code's statistic code (if any)

STAT_AMOUNT

N13.2

This is the statistical amount from the GL detail lines

Note:

The GLASSIGN process updates an FT's GL details with the appropriate GL account number.

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.

Contents

Financial Transaction - Main

Financial Transaction - FT Process

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 until the FT is swept onto a bill (when the next bill is completed for the FT's account). If New Charge is modifiable and turned off, Arrears Date must be specified.

- 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.

SA ID is the system-assigned, unique identifier of the service agreement 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.

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.

CIS Division is the CIS division associated with the FT. This comes from the CIS division linked to the FT's service agreement's SA type.

GL Division is the GL division associated with the FT. This comes from the GL division linked to the FT's service agreement's SA type.

Show on Bill indicates if the FT will be shown on the customer's bill. You should only turn this off for erroneous FTs that should not be shown to the customer. 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 starts aging when the FT is swept onto the next bill produced for the account. If you turn this switch off, you must enter the date the FT starts aging in Arrears Date.

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.

Arrears Date is the date the FT starts aging. This field is typically blank until the FT is swept onto the account's bill. If you want to start aging an FT on an historical date (for whatever reason), enter the appropriate Arrears Date. (Note - you must uncheck the "New Charge" box first in order to do this.)

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 customer).

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 service agreement.

Transferred Out indicates if the FT has been transferred to a service provider. This could only happen if the FT is associated with a SA that is associated with a "they bill for us" service provider. Refer to They Bill For Us for more information.

The Frozen switch is turned on when the FT has been frozen (i.e., posted to the service agreement's payoff and/or current balances). If this switch is on, both Freeze Date/Time and Frozen By are populated.

Current Amount contains the FT's impact on the service agreement's current amount.

Payoff Amount contains the FT's impact on the service agreement'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 utility service, 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 CIS 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 bill factor (because only bill factor's use characteristic values). Refer to An Illustration Of A Bill 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 a bill segment is frozen, the system executes the freeze algorithms associated with the bill segment's service agreement's SA type. One of these algorithms may check if there are service providers who are interested in the bill segment's consumption, and if so, schedule the consumption to be downloaded by linking the bill segment's financial transaction to the service provider's consumption download process.

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.

Account Financial History

This page shows how an account's current and payoff balance have changed over time. Use Financial Query, Account Financial History to open this page.

Description of Page

This page is dedicated to a grid that shows an account's financial events. These events are grouped together by Arrears Date, Financial Transaction Type and Parent Id (therefore if there were two payments on the same date, two rows would appear).

Note:

Multiple adjustments of the same type on the same date. If multiple adjustments with the same adjustment type exist on the same date, their total amount will appear as a single row on this query.

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:

Arrears 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 Segment , Pay Segment , Bill Segment Cancellation , Pay Segment Cancellation , AdjustmentandAdjustment (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.

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 Financial Query, Bill / Payment History to open this page.

Warning:

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, credit notes, correction notes, 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.

- Credit Note . This option shows all credit notes.

- Correction Note . This option shows all correction notes.

- 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.

Note:

Credit Notes or Correction Notes. The Bill Correction option on the Installation table controls whether Credit Notes or Correction Notes are allowed. The default transaction type filter displayed is for Credit Note. If your implementation uses Correction Notes, you'll need to change the transaction type filter to reflect this. This is done by overriding the label for lookup value CRNT on the customizable lookup field TXN_FLTR_TYPE_FLG .

- 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 customer. 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 arrears date.

Warning:

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.

- Credit notes appear as separate rows and contain the amount of canceled bill segments represented on the credit note.

- Correction notes appear as separate rows and contain the difference between the canceled bill segments amount and the rebilled bill segments amount represented on the correction note.

- 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.

SA Financial History

This page is dedicated to a grid that shows the financial transactions linked to a service agreement. Use Financial Query, SA Financial History to open this page.

Description of Page

This page is dedicated to a grid that shows a service agreement'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:

Arrears 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 Segment Cancellation,Pay Segment Cancellation , AdjustmentandAdjustment (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 service agreement's current balance.

Current Balance This column shows the service agreement's current balance after the financial event.

Payoff Amount This column shows the FT's effect on the service agreement's payoff balance. The value is grayed out if it is the same as the current amount.

Payoff Balance This column shows the service agreement'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.

SA Non-Accrual Accounting Balance

Note:

Only relevant if you practice non-accrual accounting. This transaction is only relevant if you practice non-accrual accounting (e.g., you only pay the taxing authorities when the customer pays you or you defer revenue recognition till a later date or a combination of the two). Refer to Payables Cash Accounting and Deferred Accrual Accounting for more information about non-accrual accounting.

This page displays a grid that shows a service agreement's non-accrual accounting balance for each non-accrual holding distribution code that's been booked to. Use Financial Query, SA Non-Accrual Accounting Balance to open this page.

Description of Page

The following columns are displayed in the grid:

Holding Distribution Code This is a general ledger distribution code used as the holding account for non-accrual accounting. Each holding account that's been used by this service agreement 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 or when the designated revenue recognition date elapses. The system supports revenue recognition on the bill due date.

Fastpath:

For more information on how the distribution codes are set up, refer to Setting Up Distribution Codes.

Payoff Balance This column shows the service agreement's balance for each non-accrual holding account. If this amount is non-zero, it indicates that for this service agreement we are still holding some payables back until payment is received by the customer, at which time some or all of this amount will be transferred to the payable distribution code.

Accounting Method This column shows which accounting method is used for the distribution.

Accounting Priority This column shows the priority level associated with the distribution code. If more than one distribution code is to receive a payable then the priority level, along with debt age, will determine the order in which the transfers are made.

Fastpath:

For information about non-accrual accounting, refer to Payables Cash Accounting and Deferred Accrual 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 Financial Query, 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 SA 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 CIS 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 CIS 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 Segment 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 Segment Cancellation The total number of pay cancellations that belong to this balance control group.

The SA Type scroll summarizes the FTs that belong to a particular SA Type within the balance control group - otherwise all fields are defined as above. You can scroll through all SA Types that belong to the balance control group.

SA Type The SA Type being summarized.

Match Event

Warning:

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 customer'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.

Contents

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 Financial, Match Event to open this page.

Note:

Debit must equal credits. Before a match event impacts a customer's arrearage, its debits and credits must net to zero for every service agreement 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.

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 bill with a credit or correction note, or a payment with a payment cancellation.

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 service agreements.

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.

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 service agreement on the match event. It's worth stressing that a match event may contain financial transactions from many service agreements and each service agreement's financial transactions must sum to zero before the match event can become balanced .

- You may re open 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, credit or correction notes, 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 , Payment Cancellation or CreditorCorrection Note. 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. If sequential bill functionality is enabled, the bill's sequential id is displayed instead.

- 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, credit notes, correction notes 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 , Payment Cancellation,CreditorCorrection Note. 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. If sequential bill functionality is enabled, the bill's sequential id is displayed instead.

- 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.

Note:

Credit Notes or Correction Notes. The Bill Correction option on the Installation table controls whether Credit Notes or Correction Notes are allowed. The default Transaction Type displayed is for Credit Note. If your implementation uses Correction Notes, you'll need to change the transaction type filter to reflect this. This is done by overriding the label for lookup value CRNT on the customizable lookup field TXN_FLTR_TYPE_FLG .

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, credit notes, correction notes 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.

Use Financial, Match Event, FT Details to open this page (note, you can also open this page using many of the hyperlinks on the Main and SA Subtotals tabs).

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).

- Correction Note . This option allows you to view a specific correction note's financial transactions. When this option is selected, an input field appears in which you identify the Bill ID (every correction 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.

Note:

Credit Notes or Correction Notes. The Bill Correction option on the Installation table controls whether Credit Notes or Correction Notes are allowed. The default Transaction Type displayed is for Credit Note. If your implementation uses Correction Notes, you'll need to change the transaction type filter to reflect this. This is done by overriding the label for lookup value CRNT on the customizable lookup field TXN_FLTR_TYPE_FLG .

- 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 SA Filter to define the types of service agreements whose financial transactions appear in the grid. The following options are available:

- Address. Use this option to restrict financial transactions to those whose service agreements are linked to service points associated with a given Address, City and/or Postal code. Note, you can specify any combination of these fields.

- All. Use this option if you do not wish to restrict financial transactions based on service agreement attributes.

- Geographic Type. Use this option to restrict financial transactions to those whose service agreements are linked to service points associated with a given Geo Type and Value.

- SA ID. Use this option to restrict financial transactions to those linked to a specific Service Agreement.

- SA Type. Use this option to restrict financial transactions to those whose service agreements are linked to a given CIS Division and SA Type.

Warning:

Don't forget to click the search button after changing the filters.

The Select All / Clear 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 .

- Arrears Date. This column contains the financial transaction's arrears date.

- SA Information. This column contains a summary of the financial transaction's service agreement.

- 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.

- Premise Information. This column contains a summary of the premise (if any) associated with the financial transaction's service agreement.

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 customer's arrearage, its debits and credits must net to zero for every service agreement referenced on the match event. This page shows the sum of the debits and credits for every service agreement that contributes at least one financial transaction to the match event. Use Financial, Match Event, Subtotals to open this page

Description of Page

This page shows the sum of the debits and credits for every service agreement 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 service agreements 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 SA Filter to define the types of service agreements whose financial transactions appear in the grid. The following options are available:

- Address. Use this option to restrict service agreements to those linked to service points associated with a given Address, City and/or Postal code. Note, you can specify any combination of these fields.

- All. Use this option if you do not wish to restrict service agreements.

- Geographic Type. Use this option to restrict service agreements to those linked to service points associated with a given Geo Type and Value.

- SA ID. Use this option to see a specific Service Agreement.

- SA Type. Use this option to restrict service agreements to those with a given CIS Division and SA Type.

- Use Status Filter to restrict the service agreements 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 service agreements based on this status.

- Balanced . This option shows only service agreements where the sum of debit and credits nets to zero on this match event.

- Unbalanced . This option shows only service agreements where the sum of debit and credits do not net to zero on this match event.

Warning:

Don't forget to click the search button after changing the filters.

The grid that follows contains the service agreements that match your search criteria. The following information appears in the grid:

- SA Information. This column contains a summary of important information about the service agreement.

- 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 service agreement contributes to this match event.

- Matched Credits. This column contains the sum of credit financial transactions that this service agreement contributes to this match event.

- Premise Information. This column contains a summary of the premise (if any) associated with the financial transaction's service agreement.

How To Perform Common Match Event Functions

Contents

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 customer wants to dispute an item:

- 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 customer pays $1993

- An unbalanced match event will result because the customer 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 service agreement 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 customer 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.

Deposits

In this section, we describe how to manage your deposits.

Contents

The Big Picture Of Deposits

Deposit Review

The Big Picture Of Deposits

The topics in this section provide background information about a variety of deposit issues.

Fastpath:

We strongly recommend familiarizing yourself with the topics described in The Financial Big Picture to fully appreciate how deposits fit into the system's financial architecture.

Contents

Cash Deposits

Refunding Deposits

Partial Refunds

Total Amount To Bill

Current Balance versus Payoff Balance

Multiple Deposits Linked To A Single Account

Deposits and Credit & Collections

Deposit Seizures When Other SAs Are Stopped

Non-Cash Deposits

3rd Party Deposits

Deposit Class Controls Everything

Deposit Background Processes

Cash Deposits

Before you can bill a customer for a deposit, there must be a deposit service agreement (SA). Deposit SA's will be created by a CSR using Start/Stop Service (the same page used to create all other types of service agreements).

Deposit SA's behave just like any other service agreement in that:

- A deposit SA must reference an SA type. Refer to Service Agreement Type Controls Everything for information about how SA type controls a service agreement's behavior.

- Bill segments will be produced to bill the customer for a deposit. Note, bill segments associated with deposit SA's will appear on the same bill as other bill segments related to its account (i.e., a bill could contain a combination of utility, deposit, and non-utility bill segments).

- When a customer makes a payment, it will be distributed amongst its account's SAs based on each SA's payment distribution priority. This means a single payment could relieve receivable accounts (associated with utility service agreements) and increase a payable account (associated with the deposit service agreement). Refer to Distributing A Payment Amongst An Account's Service Agreements for more information.

- You can use a transfer adjustment to relieve debt on some other type of service agreement (by transferring all or part of the deposit's credit balance to another service agreement).

- You can use an A/P adjustment to cause a check to be created if you need to manually refund a deposit.

- When you no longer require the deposit, a CSR will stop the deposit SA using Start/Stop Service (the same page used to stop all other types of service agreements). Refer to Refunding Deposits for information about how the refund actually takes place.

Fastpath:

Refer to Deposit Class Controls Everything for information about deposit interest, the recommended deposit amount algorithm, and how deposits are refunded.

Note:

An account can have many deposits. You can view all deposits (both cash and non-cash) linked to an account on Account - Deposits .

Refunding Deposits

To refund a deposit, you simply need to change the deposit SA's state to pending stop . The system does everything else (i.e., calculates interest and refunds the deposit to the customer).

There are three ways in which a deposit SA's state can become pending stop :

- The Deposit Refundbackground process (referred to by the batch control ID DEPRFND ) make a deposit service agreement pending stop when it detects that the customer meets the automatic refund criteria. Refer to Defines The Conditions That Cause The System To Automatically Refund A Deposit for a description of how to define the conditions that control automatic refund.

- An operator, at their discretion, may refund a deposit by stopping the deposit SA using Start/Stop Service (the same page used to stop all other types of service agreements). This page simply changes the deposit SA's state to pending stop .

- The system changes the state of a deposit service agreement to pending stop when it recognizes that all other SA's of its deposit class have also been stopped . This may be necessary, for example, when a customer's utility service agreements have been severed for non-payment. Refer to Deposit Seizures When Other SAs Are Stopped for more information.

The system changes the state of a pending stop SA to stopped when the process responsible for Finalizing Pending Stops next runs.

When a deposit SA becomes stopped , the system calculates interest through the stop date. Refer to Controls Interest Calculation for a description of how interest is calculated.

Note:

If you can't wait for this process to run, simply display the deposit SA on Service Agreement - Main Information and press the stop button.

When the stopped deposit SA is final billed, the system produces a final bill segment that shows the deposit amount being returned to the customer. When the bill segment's bill is completed, the deposit is refunded to the customer as per the deposit refund algorithm on the deposit's deposit class. Refer to Controls How Deposits Are Refunded To A Customer for a description of how a deposit is refunded.

Warning:

None of the base package deposit refund algorithms create an A/P adjustment when the deposit service agreement is final billed. Rather, they depend on the write-off preprocessing to actually refund the deposit to the customer.

Partial Refunds

You can perform a partial refund by creating an adjustment for the deposit SA. If you want to refund the adjustment with a check, this adjustment should be an A/P adjustment (i.e., one that is interfaced to A/P). If you want to refund the adjustment by offsetting some other service agreement's debt, create a transfer adjustment (transferring from the deposit SA to the SA to be relieved).

After creating the adjustment, you'll find that the deposit SA has a positive current amount due (because you debited the deposit SA to refund the credit amount). You should create another adjustment to return the current amount of the deposit to zero. It's important to use an adjustment type that only affects current amount when you do this.

After getting the deposit's current amount back to an expected amount, you will have to change the deposit SA's Total Amount To Bill to reflect the amount of deposit you want to hold for the customer. So, for example, if you were holding a $500 deposit and you want to refund $100, you should change the deposit SA's Total Amount To Bill to be $400.

Total Amount To Bill

Most deposit service agreements contain a "Total Amount To Bill" field. The label for this field is defined on the SA type (on the Billing tab). For deposit SAs, it should be labeled something liked Cash Deposit Amount. This field should reflect the deposit amount you WANT to hold on this service agreement. Please be aware of the following in respect of this field:

- If the payoff balance (i.e., the current deposit held) is less than the Total Amount To Bill, the system will generate a bill segment to charge the customer for the deposit.

- If the deposit service agreement uses a recurring charge (i.e., you bill the total amount in installments), the amount billed to the customer will not exceed the recurring charge amount (unless the bill segment is prorated).

- If the deposit service agreement does not use a recurring charge, the amount billed will equal the difference between Total Amount To Bill and the service agreement's payoff balance.

- If you need to bill an incremental deposit on an existing deposit service agreement, simply change the deposit service agreement's Total Amount To Bill.

- If the payoff balance (i.e., the current deposit held) is greater than the Total Amount To Bill, the system will NOT refund the excess deposit.

Note:

SA Type and Total Amount to Bill. A deposit service agreement's SA type controls if the deposit service agreement uses Total Amount to Bill. Typically, the only SA types that indicate this field can be used are loan and deposit service agreements.

Current Balance versus Payoff Balance

Warning:

If you do not understand the difference between payoff balance and current balance, refer to Current Amount versus Payoff Amount.

The current balance on a deposit SA contains the amount of the deposit that has been billed, but not paid. The payoff balance on a deposit SA contains the amount of deposit being held. The payoff balance is a negative number because your company owes this money to the customer.

The financial ramifications of a deposit SA are predictable (if you're an accountant). The following table outlines the different financial events and their impact on the general ledger, arrearage history, and the amounts due (both current and payoff).

Note:

It's important to be aware that everything that is shown in this table is controlled by how you set up the deposit SA type's bill segment type, payment segment type, and adjustment types. Refer to Service Agreement Type Controls Everything for how to do this.

Event

GL Accounting

Arrearage Rule

Effect On Payoff Amt

Effect On Current Amt

Payoff Balance

Current Balance

Deposit billed

N/A - the GL is not affected when a deposit is billed

$100 starts aging

0

+100

0

100

Payment received

Cash 100

Deposit Payable <100>

$100 relieved accordingly

-100

-100

-100

0

Interest calculated

Interest Exp 5

Deposit Payable <5>

N/A

-5

0

-105

0

The following points describe the events in the above table:

- Deposit billed. In this example, the customer is billed for $100 deposit.

- The customer really thinks they owe the billed amount, $100. Therefore, current amount is affected. However, if the customer was to cash out, they wouldn't owe your organization anything, therefore payoff amount is not affected.

- Notice that the GL is not affected when the deposit is billed. This is because most organizations do not show a receivable for billed deposits (as it's not a true receivable).

- Because current amount changed by $100, arrearage history is affected accordingly.

- Payment received. With any luck, the client will pay the $100 that was billed.

- The payment has a normal affect on the GL (debit cash, credit deposit payable). The deposit payable GL account is defined as the deposit SA type's Distribution Code.

- The amount the customer thinks they owe decreases by $100, therefore current amount is affected by the payment amount. And, if the customer was to cash out, your organization would owe the customer $100, therefore payoff amount is affected by the payment amount.

- Because current amount changed by $100, arrearage history is affected accordingly.

- Interest calculated. In this example, the system calculates interest of $5.

- The interest is posted to the GL (the interest expense distribution code is defined on the respective adjustment type).

- The interest amount didn't affect how much the customer thinks is due them. Therefore current amount is unaffected. However, if the customer was to cash out, your organization would owe them $100 + $5 (the interest) therefore payoff amount is affected by $5.

- Because current amount is not changed, arrearage history is not affected.

Multiple Deposits Linked To A Single Account

The system has been designed to allow your customers to have multiple deposits. This is necessary when a deposit is restricted to a specific type of debt. For example, if separate deposits are held for regulated and unregulated debt (and a customer could hold a combination of regulated and unregulated debt), you'd need one deposit for regulated debt and another for unregulated debt.

Note:

Deposit class. A deposit's deposit class controls the service agreements that are covered by a given deposit. A deposit's deposit class is defined on its SA type. Refer to Designing Your Deposit Classes for more information.

It's important to be aware that if your company has multiple classes of deposits, the system will recommend and refund deposits for each individual deposit class. For example, if you have both regulated and unregulated deposit classes, the system will recommend separate deposits for each class. And at refund time, a deposit will be distributed to only those service agreements associated with its deposit class (i.e., a regulated deposit will not be used to satisfy unregulated debt).

Deposits and Credit & Collections

The account debt monitor monitors deposit service agreements just as it monitors every other service agreement for overdue debt. If the amount of debt on the deposit SA violates your collection criteria, a collection process will start.

Fastpath:

Refer to The Lifecycle Of A Collection Process And Its Events for more information.

It's important to be aware that deposit debt can be treated differently from other types of debt linked to an account by creating a specific debt class for the deposit SA type.

Fastpath:

Refer to Designing Your Collection Procedures for more information about how to have different collection criteria for different debt classes.

The type of severance process associated with a deposit SA is probably rather simple - you probably will want a To Do entry generated to advise an operator that a customer hasn't paid their deposit.

Fastpath:

Refer to The Lifecycle Of A Severance Process And Its Events for more information.

Please see Deposit Seizures When Other SA's Are Stopped for a description of how the system seizes an active deposit service agreement when normal (i.e., non-cash deposit) service agreements are stopped.

After a deposit SA is stopped , it will be "final billed" the next time the account is billed. Refer to Refunding Deposits for more information about how deposit refunds are "final billed". If a credit balance remains on the deposit SA after it is final billed, the Write-Off Monitor will process the deposit SA just like it processes all unpaid and final billed service agreements. If you set up the deposit SA's write-off controls properly (i.e., you plug in the appropriate refund and write-down algorithms), the write-off monitor will refund / write-down the credit balance (thus causing the deposit SA to close).

Deposit Seizures When Other SAs Are Stopped

Consider the situation when a severance process cuts a service due to non-payment. At some point, if the customer doesn't pay, you'll want to seize the deposit and apply it to the overdue debt. To implement this, the system simply stops the deposit SA when it stops the last SA in its deposit class (refer to Finalizing Pending Stops for more information about stopping service agreements). Then, when the account is next billed, the standard deposit refund process will offset outstanding debt before it is refunded to a customer.

Refer to Refunding Deposits for a complete description of how the system refunds a stopped deposit SA's balance to other service agreements in its deposit class.

Note:

Deposit class refund method is the key. It's important to stress that the only way the system will use a deposit to offset overdue debt is if the deposit's deposit class has a refund method that does this. If you've set up a deposit class' refund method to cut a check for the entire deposit amount, the system will not offset outstanding debt. Refer to Deposit Class - Refund Method for more information.

Non-Cash Deposits

When an account is required to post a deposit, they can remit cash or some other type of surety (e.g., letters of credit, surety bonds, 3 rd party deposits). When cash is remitted, a deposit service agreement is used. When some other type of surety is used, a non-cash deposit must be created.

Non-cash deposits are held in respect of an account and an account may have an unlimited number of non-cash deposits (note: cash deposits are held in respect of a deposit service agreement that is linked to remitting account). Refer to Account - Deposits for more information.

Each non-cash deposit must reference a non-cash deposit type. Besides defining the type of surety, the non-cash deposit type also controls:

- Whether such types of non-cash deposits can be highlighted when they are due to expire via the creation of a To Do entry (refer to TD-NCDEX for more information about this To Do entry).

- Whether a reference to a cash-deposit (i.e., service agreement) must be specified. Refer to 3rd Party Deposits for more information about how a cash deposit can be referenced by another party.

Fastpath:

Refer to Setting Up Non-Cash Deposit Types for more information.

In addition to non-cash deposit type, each non-cash deposit must reference a deposit class. Why? Because the system amalgamates cash and non-cash deposits when it determines if an account is holding an adequate deposit.

Fastpath:

Refer to What Do Deposit Classes Do? for more information.

If you need to use a non-cash deposit to satisfy an account's debt, you must "cash in" the non-cash deposit. When the cash arrives, create a payment and apply it to the customer's outstanding service agreements.

3rd Party Deposits

A 3 rd party deposit arises when a 3rd party remits cash to cover the deposit needs of one or more accounts. Both cash and non-cash deposits must be created to record a 3rd party deposit. The following example will explain how to do this.

Assume the Salvation Army remits $5,000 on behalf of 50 customers (where each customer's account is allocated $100). In this situation, you'd create the following information in the system:

- The Salvation Army must have an account with a deposit service agreement.

- When the Salvation Army remits the funds:

Warning:

If you do not understand the difference between payoff balance and current balance, refer to Current Amount versus Payoff Amount.

- Create an adjustment to "bill" the deposit service agreement (causing the deposit SA's current balance to be $5,000 and the payoff balance to be 0).

- Add a payment for the $5,000 against the Salvation Army's account. This payment will cause the deposit SA's current balance to be 0 and the payoff balance to be -$5,000. Note, if you don't mind the Salvation Army's current balance to be -$5,000 after the payment is made, you wouldn't have to create the adjustment to "bill" the deposit.

- Create a non-cash deposit for each of the 50 accounts being covered by the cash deposit. On each non-cash deposit, define the appropriate non-cash deposit type (e.g., 3 rd party deposit) and amount $100 each.

- Interest will be applied to the Salvation Army's deposit service agreement as per the interest algorithm on the deposit SA's deposit class.

- If you need to use the Salvation Army's payment to payoff overdue debt, you will use a transfer adjustment(s) to transfer from the deposit service agreement to the respective overdue service agreement(s).

Important:

Be aware that the system will allow the sum of 3rd party deposits to exceed the amount of the cash deposit (in our previous example, the system would allow you to create $6,000 worth of 3rd party non-cash deposits even though only $5,000 of cash was remitted).

Deposit Class Controls Everything

A deposit service agreement's SA type references a deposit class. The topics in this section describe how deposit class controls the behavior of a deposit SA.

Fastpath:

Refer to Setting Up Deposit Classes for a complete description of the business rules governed by a deposit class.

Contents

Controls Interest Calculation

Controls The Recommended Deposit Amount

Defines The Conditions That Cause The System To Recommend A New or Additional Deposit

Defines Automatic Refund Conditions

Controls How Deposits Are Refunded To A Customer

Controls Interest Calculation

Interest is applied to a deposit SA when:

- A deposit SA is stopped . Refer to Refunding Deposits for a description of how a deposit SA can be stopped.

- The Apply Interest background process (referred to by the batch control ID DEPINTRF ) determined that sufficient time has passed since interest was last calculated. The amount of time between interest calculations is defined on the deposit class.
A deposit SA's deposit class controls the following interest calculation functions:

- The frequency of interest calculation.

- The algorithm used to calculate the amount of interest (note, the interest rate is defined using a bill factor plugged in on this algorithm).

- The method used to refund the interest.

Note:

Adjustments are used to apply interest. Interest is applied to a deposit SA using an adjustment (the adjustment type is also defined on the deposit class).

Controls The Recommended Deposit Amount

The following events cause the calculation of the recommended deposit amount:

- The Deposit Review background process (referred to by the batch control ID DEPRVW ) compares an account's existing deposit (if any) to the recommended amount.

- A user requests a deposit calculation for a new deposit service agreement by pressing the button on the Start Confirmation.

A deposit service agreement's deposit class controls the algorithm used to derive the suggested deposit amount.

Defines The Conditions That Cause The System To Recommend A New or Additional Deposit

The Deposit Review background process (referred to by the batch control ID DEPRVW ) will recommend an additional deposit be billed if the customer doesn't satisfy the definition of a good customer.

It's important to be aware that if your company has multiple classes of deposits, the system will recommend deposits for each individual deposit class used by an account. For example, if an account has both regulated and unregulated deposit classes, the system will recommend separate deposits for each class.

When the Deposit Review process analyzes an account's debt, it uses the following deposit class attributes:

- The definition of a good customer (the system only recommends deposits for bad customers).

- The tolerance percent that must be exceeded before the system will recommend an additional deposit for a customer. This tolerance percent prevents the recommendation of small amounts.

- The method used to derive the recommended deposit amount.

Assuming the C1-CR-UP-DRR review method algorithm is specified on the deposit class, the system does not automatically produce bills when an additional deposit is needed. Rather, the system's recommendations appear on the Deposit Review page. To implement a recommendation, an operator should change the deposit SA's Total Amount To Bill or add a new deposit SA.

Note:

Non-cash deposits are included. It's important to be aware that the system compares the recommended deposit amount against the sum of deposits on hand for a given deposit class. When amalgamating the total deposit on hand, the system includes both cash (i.e., deposit SA's payoff balance) and non-cash deposits.

Defines Automatic Refund Conditions

The Deposit Refundbackground process (referred to by the batch control ID DEPRFND ) will refund a deposit to a customer when conditions defined on the deposit SA's deposit class are met. For example, a deposit's deposit class may indicate the system should automatically refund a deposit after the deposit has been held for 6 months and the customer is a good customer (the definition of a "good customer" is also on the deposit class).

Controls How Deposits Are Refunded To A Customer

The method used to refund a deposit to a customer is defined on the deposit SA's deposit class. For example, a deposit's deposit class may indicate the system will first apply the deposit to outstanding debt first and, if funds remain, cut a check.

It's important to be aware that if your company refunds deposits by first offsetting outstanding debt, the system will only offset debt within an individual deposit class. For example, if a customer has two deposits - one for regulated debt, the other for unregulated debt - the regulated deposit will only be used to offset regulated debt.

Deposit Background Processes

The topics in this section describe the background processes that automate deposit processing.

Contents

Deposit Interest

Deposit Refund

Review Deposits

Deposit Interest

The Deposit Interest background process (referred to by the batch control ID DEPINTRF ) examines all cash deposit service agreements (i.e., service agreements with a SA type with a special role of Cash Deposit ). If enough time has passed since interest was last calculated, interest will be calculated using the service agreement's deposit class' Interest Refund Algorithm. Note: interest will be automatically calculated every X months where X is defined in the deposit class' Months Between Interest Refund.

Deposit Refund

The Deposit Refund background process (referred to by the batch control ID DEPRFND ) examines all cash deposit service agreements (i.e., service agreements with a SA type with a special role of Cash Deposit ). If the account meets the service agreement's deposit class' Refund Criteria Algorithm, the system changes the service agreement's state to Pending Stop . Refer to Refunding Deposits for a description of what happens next.

Review Deposits

The Review Deposits background process (referred to by the batch control ID DEPRVW ) examines all accounts with service agreements that are governed by a deposit class (i.e., service agreements with an SA type that references a deposit class). If the account fails the deposit class' Good Customer Algorithm, the system calculates the recommended deposit amount (using the deposit class' Deposit Recommendation Algorithm). If the recommended amount exceeds the amount of deposit currently requested, the system will request an additional deposit. The deposit class' Review Method Algorithm is used to determine what action to take if the system requests an additional deposit. The system's recommendations appear on the Deposit Review page.

You may optionally provide a Deposit Class as input to restrict the review to account whose service agreements reference that deposit class.

Note:

Preventing small recommendations. The system uses the deposit class's Review Tolerance Percentage to prevent the recommendation of small deposits by the Deposit Review background process. For example, if this field contains 10(%), the system would only recommend an additional deposit if the existing requested deposit amount is less than 90% of the recommended amount.

Multiple deposits could be recommended for an account. Because an account can have service agreements that belong to multiple deposit classes, it is possible for a multiple recommendations to be generated for an account.

Deposit Review

The Deposit Review page shows all accounts for which an additional deposit is recommended.

Note:

The Review Deposits background process inserts rows on this query.

Multiple deposits could be recommended for an account. Because an account can have service agreements that belong to multiple deposit classes, it is possible for a multiple recommendations to be generated for an account.

Open this page using Financial Query, Deposit Review.

Description of Page

Use Account ID and / or Deposit Class to filter the rows. Each row displays and account / deposit class that holds an inadequate deposit.

Note:

Rows are also displayed for errors. Please be aware that if the Recommend Additional Deposit background process encounters an error when it attempts to calculate an account's recommended deposit, these errors also appear as rows in this query.

Press the button to add a new deposit SA for the customer. Pressing this button causes Start/Stop Service to open. When this page opens, you should create a new deposit service agreement for the customer (by referencing the appropriate division / SA Type).

If the customer has one or more deposit service agreements, the drill button will be enabled. Pressing it will cause the Service Agreement - Main Information page to open. When this page opens, you can change Total Amount To Bill to reflect the total amount of deposit you want to hold. When billing next runs, it will bill the customer for the marginal difference between the current deposit held and the deposit amount to bill.

Fastpath:

Refer to Defines The Conditions That Cause The System To Recommend A New or Additional Deposit for how rows are added to this query.

Interval Billing

The interval billing functional area is responsible for managing the following:

- Collecting interval data. Any time increment can be supported. For example, electrical meter read data might be recorded in 10 minute, 15 minute, 30 minute, ... intervals; whereas daily gas consumption may have intervals that span 24 hours.

- Maintaining interval prices. Again, any time increment can be supported.

- Deriving billable interval consumption from multiple interval consumption sources. For example, actual interval consumption can be compared against a customer-specific "maximum demand" profile to derive an "excess demand" profile.

- Deriving time-of-use consumption by applying time-of-use maps to a customer's interval consumption.

This chapter describes the above points in detail.

Note:

The transactions described in this document are available only if the interval billing modules are not turned off.

Contents

Interval Pricing Background Topics

The Big Picture of Raw Data Collection and Aggregation

Time of Use Mapping Background Topics

Contract Option Background Topics

Maintaining Interval Data

Interval Billing Examples

Interval Pricing Background Topics

The topics in this section provide background information about a variety of interval billing issues.

Contents

Billable Interval Quantities for a Service Agreement

Interval Quantities are Stored in Data Sets

Fixing Errors with Complete Data Sets

Algorithms Find the Most Up To Date Data

Time Issues

Interval Data Serves a Role for a Service Agreement

Common Profiles vs. SA Owned Profiles

Flexibility of SA / Profile Link

The Link between Profile and SA is Effective Dated

Creation of Profile Data through Data Derivation

Validation of Profile Data

Auditing Your Interval Pricing Bill Lines

Billable Interval Quantities for a Service Agreement

Billable interval quantities are linked to the service agreement. These quantities are linked through an Interval Profile. The interval data that is received over time is linked to the service agreement in one of the following ways:

- It is uploaded from an external source. Refer to Upload Interval Data for more information.

- It may be created in the system through data derivation algorithms. Refer to Creation of Profile Data through Data Derivation for more information.

All the data received throughout time could be plotted as a curve. For interval quantities, the curve is referred to as an Interval Profile.

The profile references a Profile Type that defines the physical attributes of the data curve. It defines the unit of measure, the interval size and may also contain data derivation algorithms, which actually populate the profile with data based on other information. Refer to Designing Interval Profile Types and Creation of Profile Data through Data Derivation for more information.

Interval Quantities are Stored in Data Sets

Interval data in the system may have many different origins.

- It may be contract-related data that is set up at the beginning of the contract or contract year.

- It may be data that is periodically interfaced from an external source.

- It may be data that is derived and created through a system algorithm.

Regardless of the origin of the data, all data has similar characteristics:

- Data is received by the system or created by the system periodically. The system stores whatever new data needs to be stored.

- The period represented by the batch of new data is variable.

- New data may be an update to previously received data.

The system accepts the new batches of data for a given profile and stores the data grouped together by a data set.

There are two effective dates referenced in the interval pricing information: Set Date/Time and Interval Value Date/Time. Think of the Set Date/Time as the effective date of the entire set of interval data. Think of Interval Date/Time as the effective date of the associated piece of data.

Refer to Algorithms Find the Most Up To Date Data for information about processing this data.

Fixing Errors with Complete Data Sets

If a data set is complete, but the values are incorrect, you are not able to cancel the data set. In order to reverse the effect of a completed data set, you must create a new completed data set with corrected data.

What happens if no previous values exist for the incorrect data? There are no values available to replace the incorrect values. You essentially want to indicate to the system that no data exists for this interval. To do this, you create a data set with a special data set type of No Data .

The system provides a Revert button on the appropriate interval data pages to help the user to reverse the effect of a data set. When reverting, the system creates a new data set and populates the intervals with the most recent values for those intervals, ignoring the values in the data set being reverted. If there are no other values for any of the interval, then a "No Data" data set is created for these intervals.

Fastpath:

Refer to Interval Data Maintenance, TOU Data Maintenance and Interval Register Data Maintenance for more information about setting the data set type flag and using the Revert button.

Algorithms Find the Most Up To Date Data

Any algorithm that must retrieve interval data, whether it is bill factor interval values or time of use map data or interval profile data, needs to ensure that it accesses the most up to date data. This includes algorithms used by the rates to process interval data and any derivation algorithm.

Refer to Interval Quantities are Stored in Data Sets for information about how interval data is stored.

The following diagram illustrates data retrieved by rates to use for billing a customer on a given date.

The following diagram illustrates what happens when data is received by the system that is a correction of previously received data. A bill produced after this data is received uses the most up to date values.

Whenever a collection of interval data needs to be accessed, the system checks the following:

- As of what date? This enables the system to find the data sets that existed in the system on that date. It looks for the appropriate data within these data sets.

- What is the time period? This enables the system to get the correct collection of interval data.

If you want to verify the data used to produce a bill,

- The "as of what date" is the bill segment creation date

- The bill segment start and end dates define the time period

Time Issues

Contents

Start and End Times for Billing

Time Zone and Time Changes

Start and End Times for Billing

As you know, there is logic in billing to determine the start date and end date for a bill segment. Refer to Ways to Control The End Date Of A Bill for more information. When billing for a customer with interval data, the system also needs to know the time.

The time used by billing, referred to as the cutoff time, is stored on the service agreement. There is also a control on the service agreement called Start Day Option that determines which day to use for the start time. Billing algorithms use the billing date, the cutoff time, and the start day option to determine the correct interval data to process.

Contents

Billing Time Examples

First and Last Bill Segment Considerations

Defaulting Service Agreement Time Options

Changing Service Agreement Time Options

Billing Time Examples

Let's look at some examples.

Contents

Current Day Option

Previous Day Option

First Bill Segment

C urrent Day Option

- Assume that the consumption period is from the 1 st of October through the 29 th of October.

- Assume the cutoff time on the service agreement is 2 a.m. and the start day option is Current Day.

To determine the starting interval, the system finds the first interval after the cutoff time on the billing start date. The system uses all the intervals up to and including the cutoff time for the DAY AFTER the billing end date.

P revious Day Option

- Assume that the consumption period is from the 1 st of October through the 29 th of October.

- Assume the cutoff time on the service agreement is 10 p.m. and the start day option is Previous Day.

To determine the starting interval, the system finds the first interval after the cutoff time on the DAY BEFORE the billing start date. The system uses all the intervals up to and including the cutoff time for the billing end date.

Fastpath:

Refer to Bill Period and Seasonal Time Shifts for more information about the effect of time shifting on determining the bill period.

F irst Bill Segment

When billing calculates the consumption period for the very first bill segment for your service agreement, it uses a flag on your SA type to correctly calculate the initial consumption period . For your interval billing service agreements, you typically configure your SA types to indicate that the start of the consumption period for the first bill should include the SA start date unless this is a 'back-to-back' situation (i.e., a previous customer was already billed for that day as its end date).

Let's look at an example. Imagine your SA type is configured to Add 1 Day for Back-to-back and this is not a back-to-back situation. Also imagine that your service agreement has the following defined:

- Start Date: April 1, 2003

- Start Day Option: Current

- Cutoff Time: 2am

The start period for the consumption period would be set to April 1, 2003; 2am .

Imagine the same SA exists, but this is a back-to-back situation. In other words, the previous customer ended service on April 1, 2003. Assuming the previous customer has the same start day option and cutoff time, they are billed through April 2, 2003; 2am . Refer to Current Day Option for more information. In this case, billing calculates the start period for the consumption period as April 2, 2003; 2am .

First and Last Bill Segment Considerations

Billing provides the consumption period used for defining the start and ending intervals by the interval pricing and TOU pricing algorithms.

However, for the very first bill segment for the customer, perhaps your business practice dictates that the first interval is at some time other than the cutoff time. For example, rather than billing from 2 a.m. on the first day, perhaps the meter is only installed at 3 p.m. and that is when billing should begin. Similarly, for the final interval on the last bill segment for your service agreement, you may require billing to end when the meter is removed at 4 p.m., rather than through 2 a.m. on the day after the end date.

To accomplish this functionality, follow these guidelines:

- When starting or stopping a service agreement, navigate to the service agreement interval info tab to define the appropriate starting or ending interval for each interval profile or TOU map linked to the service agreement using the start and end date/times in the profile or map collection.

Note:

If the start/end intervals are defined based on the date/time a meter was installed or removed, the recommendation is to design a mechanism for updating the SA/profile and SA/TOU map date/times via an interface. For example, perhaps a field activity completion algorithm could update the profile and/or map date/times according to when the meter was installed. Or perhaps a notification & workflow process is designed to update this information.

- Design your interval pricing and/or TOU pricing algorithms to override the consumption period information passed in for the first interval of the first bill segment or for the last interval for the final bill segment. These algorithms receive the service agreement effective dates so that your algorithms can easily detect whether it is the first or last bill segment for your SA. If the algorithm detects that this is the first or last bill segment for the service agreement, it can use the profile and/or TOU map start and end date/times on the service agreement rather than the calculated consumption period passed in.

Note:

The interval pricing and TOU pricing algorithms provided with the product use the consumption period calculated and passed in from billing for the first and last bill segment.

Defaulting Service Agreement Time Options

In order to facilitate setup of your service agreements with their appropriate time options, cutoff time and start day option may be defined on an SA Type Start Option.

Cutoff time and start day option must also be defined on the installation option record. If your service agreement is not created with a start option, the values on the installation record are used.

Changing Service Agreement Time Options

As described above, billing uses the service agreement's cutoff time and start day option to calculate the consumption period to the interval pricing algorithms. The system currently allows you to change the cutoff time and start day option in the middle of a contract, but this is very unusual. In fact, for a given company, these settings are often the same for all interval billing customers (or at least the same for an entire class of customers). For example, a company may designate that all transportation gas customers bill from 11pm to 11pm and all other interval billing customers bill from 2 a.m. to 2 a.m..

If this information changes in the middle of a contract and non-canceled bills exist, a warning is issued. Changing either of these fields after a bill segment has been generated will cause either a gap or an overlap in intervals billed for the next bill segment. A user must manually adjust the charges accordingly.

Time Zone and Time Changes

This section describes interval data considerations when operating in different time zones and when handling seasonal time changes, such as daylight savings time.

Contents

Data is Stored in the Base Time Zone

Seasonal Time Shifts

Data is Stored in the Base Time Zone

With data stored at an interval level, provisions need to be made to cater for data captured from other time zones.

- On the installation record, you indicate the base time zone for your company data.

- ALL data must be stored in Standard time for this base time zone.

In order to help interfaces to adjust data received from a different time zone, you may store the customer's time zone on its Premise. The interface may be written to check the premise's time zone, compare it to the base time zone, and shift the data accordingly.

Fastpath:

Refer to Designing Your Time Options for more information.

Seasonal Time Shifts

A more common problem related to interval data is the problem of adjusting time for seasonal time changes. Interval data cannot be stored in "legal" time (i.e., in the summer, storing data in daylight savings time or summer time) because the shift from summer time back to standard time causes a duplicate hour. For example, in the United States, the 2 a.m. hour is repeated when shifting from Daylight Savings Time (DST) back to standard time.

To avoid the problem of duplicate records, all data must be stored in standard time. However, when entering and viewing data online, users probably want to see the data in the current "legal" time (i.e., in the summer, data is shown in daylight savings time or summer time).

Contents

Logical Time versus Server Time

Bill Period and Seasonal Time Shifts

Interval Time Display

Evenly Sized Intervals

Logical Time versus Server Time

Fields may be defined as being system date / time stamps or logical data to be captured in standard time.

In the case of interval data:

- Each interval record has a Set Date / Time, which is considered server or physical time and uses the time shift information defined on the base time zone.

- The interval date/time is considered logical time and the time shift information is defined on the related "type" entity for the interval data.

Bill Period and Seasonal Time Shifts

As described in Start and End Times for Billing, the service agreement cutoff time is used to determine the start and end times for billing.

This time is assumed to be in legal time, according to the seasonal time shift linked to the time zone for the service agreement's characteristic premise. It means that when this service agreement is billed, the system adjusts the cutoff time to standard time prior to accessing the appropriate intervals. The diagram below illustrates this point.

Interval Time Display

By default, the system displays interval data in legal time.

- For server related time fields, the time is displayed according to the seasonal time shift record on the base time zone.

- For interval related data, the time is displayed according to the seasonal time shift record on the interval entity's type.

- For the effective date/time links between a service agreement and its interval collections, the time is displayed according to the seasonal time shift record on the SA's characteristic premise's time zone.

A message indicates this to the user, for example, "Date /Time Info is expected in local legal time". The user can opt to change the display to show the data in standard time.

When entering new data, the user is expected to enter data in the same time that is displayed. If the message states that intervals are expected in legal time, the system assumes that the user enters new values in the legal time and converts them to standard time for storing.

Note:

If seasonal time shift information is missing for an entity or for the base time zone, data is always displayed and expected in standard time.

Evenly Sized Intervals

As mentioned earlier, the main drive behind shifting data to standard is to counter the effect of missing and duplicate intervals at entry to and exit from a seasonal time shift period. Storing data shifted to standard time ensures all interval records for a given curve are of equal size, which allows for simpler business logic, ignorant of seasonal time shifts considerations.

While this is obvious for hourly or less than an hour interval sizes, we would like to stress that the same concept applies to all interval sizes. If the legal time of an interval shifts during a seasonal time shift you should "counter-shift" it to standard time. If its legal time does not shift year-round, no shifting is needed.

For example, let's assume interval data being recorded in 1440 minute intervals (each read spans a full day).

- If when entering a seasonal time shift period, the legal time for these intervals shifts, say from midnight to 1 am, then when interfaced to the system data should be shifted back to standard to achieve evenly sized intervals.

- However, if the legal time does not shift, i.e. reads are taken at the same legal time, shifting is not applicable. As a matter of fact, shifting in this case causes the stored intervals to be of un-even size, thus complicating the logic that processes the data.

Note:

Base Plug-ins. If you decide to configure the system to not follow the evenly sized interval concept described above you may not be able to use the base sample plug-ins and common routines as they assume interval data is stored in evenly sized intervals.

If you are using the interval entities but your interval data have interval sizes larger than hourly (for example, daily), you may decide not to use any seasonal time shift logic. You may set a switch on the installation record to indicate whether or not your interval data should observe seasonal time shifting. Refer to Installation Options - Billing for more information.

Interval Data Serves a Role for a Service Agreement

All interval quantities are linked to an Interval Profile. An interval profile may be linked to a service agreement to serve a variety of purposes, for example:

- It is used by rates algorithms to produce bill calculation lines.

- It is used by data derivation algorithms to produce other interval data.

- It is available to the company for statistical analysis or reports.

When linking an interval profile to a service agreement, the role that it is serving must be indicated. The "role" is specified using a profile relationship type. Refer to Physical Attributes of Interval Data vs. Its Role for more information.

The following diagram illustrates one service agreement with three different profiles linked to it. One profile is serving the role of Consumption, one is serving the role of Maximum High Demand, and one is serving the role of Maximum Low Demand.

If the rate for this service agreement bills for consumption, there is a rate component that references the CONS profile relationship type. Refer to Setting Up Interval Pricing Rate Component for more information.

Note:

Profiles linked to a service agreement may or may not be billable. How do we know which ones are billable? We know because for billable profiles, the rate component for the SA's rate will indicate its profile relationship type.

It is also likely that data derivation algorithms will be written use the profile relationship type as parameters for determining the correct data to process.

Common Profiles vs. SA Owned Profiles

Interval Profiles are segregated into two categories:

- Profiles that are SA Owned are linked to a single "owner" SA. For example data related to the SA's interval meters. This data may be available for calculations on other service agreements. For example, maybe you have separate service agreements for distribution and transportation and both service agreements use the same data for calculations.

- Profiles that are Common typically contain data that is not related to a specific SA and can be used by many SAs. Some examples are:

- Contract Demand or Subscribed Demand

- Hedge Cover

- Maximum Demand

- Deemed (estimated) Profile

SA owned profiles reference a service agreement that is considered the owner of that data. Only SA owned profiles may reference data derivation algorithms. These algorithms are run for the owner SA.

Refer to Interval Profile Maintenance to understand how profiles are created and maintained.

Flexibility of SA / Profile Link

The flexibility of the system allows for many combinations of profiles and service agreements:

- One profile may be linked to the same service agreement serving two different roles. Using the Profile Relationship Type to define the role, one profile could be, for example, the "Maximum Demand" and the "Minimum Demand" for a service agreement. This profile may be common or may be SA owned .

- One profile may be linked to two different service agreements. This profile may be common or may be SA owned . This profile may serve the same role for two different service agreements, or it may serve two different roles.

The Link between Profile and SA is Effective Dated

An SA /Profile link is effective dated. Therefore, the data serving a given role may change over time. To be more explicit, a service agreement may have the data for Profile A serving as the Maximum Demand interval values at the beginning of the contract, then after a few months, perhaps Profile B's data may be used instead. This scenario assumes that the contract itself did not need to change.

Why would there be a need to change the profile being used for a given role (especially when the data itself changes every few minutes anyway)? There could be several reasons:

- Using the Maximum Demand example, perhaps the customer's usage profile has changed and this change warrants a different Maximum Demand curve (although, the rate does not change). A different common profile needs to be linked to the service agreement.

- Perhaps the interval size of the data for the customer has changed. If the rate linked to the customer can cater for the new interval size, a new profile with a different profile type needs to be linked to the service agreement.

- Recall that a profile's type contains the creation and validation algorithms. Perhaps algorithms needed to create or validate this profile have changed. To cater for this a new profile with a different profile type must be linked to the service agreement.

This design also applies to the link between an SA and a TOU map.

Note:

All algorithms that access profile and TOU map data must cater for the possibility of the profile or map changing during the desired period.

Creation of Profile Data through Data Derivation

As mentioned earlier, interval data linked to a profile may be interfaced to the system from an external source or it may be created by the system through a data derivation algorithm.

Contents

The Big Picture of Data Derivation

Determining What Interval Data To Derive

Force Derivation of Interval Data

Process IB-SPDB - SA Interval Profile Data Creation

The Big Picture of Data Derivation

Data derivation algorithms are used when a customer's contract requires interval data that is created based on other interval data in the system.

Some examples may include:

- Adjusting measured demand to account for loss factors to produce an adjusted billable data curve

- Comparing measured data to a contract demand curve to produce an adjusted billable data curve

- Comparing measured data to a maximum demand curve to produce an excess load curve

- Aggregating raw interval data from multiple interval registers linked to the service agreement's service points

- And more...

How is this set up in the system? Using the above loss factor example, let's make the following assumptions:

- The ½ Hourly MWh curve is an SA Owned profile linked to the service agreement. Its data is interfaced into the system from an external source. Refer to Upload Interval Data for more information.

- The ½ Hourly % loss are common for a group of customers and are stored as bill factor interval values. Refer to Bill Factor Interval Values for more information.

- The Adjusted MWh curve is an SA Owned profile linked to the service agreement. Its data is created by the system through a Creation data derivation algorithm linked to the profile type.

The creation algorithm (that would need to be written to handle this example) would be provided with the profile relationship type of the ½ Hourly MWh curve and the Bill Factor for the loss factors. It applies the percentage loss factor for each interval and stores the result for each interval as a new data set for the Adjusted MWh curve.

These algorithms may be executed in one of the following ways:

- Through a background process that finds every SA that has an interval profile whose profile type indicates a creation algorithm. Refer to Process IB-SPDB - SA Interval Profile Data Creation for more information.

- There is a button available on the SA Interval Info page that allows a user to execute the data derivation algorithms for a single SA.

- There is a button available on the Account Interval Info page that allows a user to execute the data derivation algorithms for all the service agreements for an Account. The service agreements are processed in the billing processing sequence order defined on their SA type.

Determining What Interval Data To Derive

Contents

Preventing Gaps in Data

Using The Latest Updates to Source Data

Preventing Gaps in Data

How do the derivation algorithms know what data needs to be derived? A simple answer is any data received since the last time data was derived should be included in the new derivation. This answer sounds good, but it's not as simple as that. Although we know the date and time of the last derivation, we don't know the date range of the data that was derived. A user may ask for data to be derived only through a certain date, even though data exists after that date. The next time data derivation runs, it may need to include the data that was after the cutoff for the previous derivation.

To illustrate this point, let's look at an example. Assume that a derivation algorithm takes a source curve and applies a value from a bill factor to arrive at the new curve. In the illustration below, data for the source curve exists up to 29 th of October 2000 at 4 a.m. When deriving new data, the user enters a cutoff date of the 29 th of October. The time used is the Cutoff Time on the service agreement, which in this case is 2 a.m. Refer to Start and End Times for Billing for more information.

The user runs the data derivation on the 31 st of October at 10:02. That date and time are the Set Date /Time for the newly created data set.

The next time data derivation runs, it is not possible for the algorithm to simply derive data that has been received since the last time data derivation was run. In the above example, only data received after the 31 st of October will be derived. However, the last two intervals for the source data received on the 30 th of October also need to be included.

The following diagram illustrates how the next derivation should behave.

Because users have control over what data may be derived (using the cutoff date), the algorithms cannot rely on data received since the last derivation.

To be safe and ensure that no gaps exist in the derived data, the algorithms should look for each interval from either the start of the SA or the start of the SA/Profile relationship through to the cutoff date/time to determine if new data should be derived. However, for performance reasons (and practical reasons) the algorithms supplied with the base product only look for new data to derive starting 45 days prior to the cutoff date. This is a soft parameter to the algorithms called Number of Days to Process and may be changed. Implementation specific algorithms may choose not to follow this example, but you must be sure to consider the performance implications.

Note:

The derivation algorithms are provided both the SA start date and cutoff time and the SA/Profile date/time. The base algorithms derive data from the SA start date/cutoff time. Implementation specific algorithms have the option of deriving data from SA/profile date/time.

Fastpath:

Refer to interval profile type for more information about the sample data derivation algorithms provided with the base product.

Using The Latest Updates to Source Data

As described in Algorithms Find the Most Up To Date Data, the data derivation algorithms must also detect whether new data has been received for a given source interval that has already been used in derivation. For these cases, the more up-to-date data for the source interval should be used to re-derive the target curve.

Force Derivation of Interval Data

Derivation algorithms base their calculations on data from other profiles, TOU maps, registers, bill factors, contract options and so on. These may be referred to as the algorithms' source data.

Ideally, derivation algorithms should be able to detect changes made to their source data since the last derivation and re-derive values for the relevant periods if any changes are detected. Refer to Using the Latest Updates to Source Data for more information.

As long as the source data has means of recording changes (e.g. an update date/time stamped on the new records), the algorithm can detect the changes and trigger re-derivation. However, not all objects in the system have this recording mechanism, making automatic detection of changes for re-derivation impossible.

Consider the sample derivation algorithm in Preventing Gaps in Data. This algorithm used a bill factor to apply a constant to the source curve to arrive at a derived curve. Imagine that the users discover that the bill factor value was incorrect and that once this value is fixed, the data needs to be re-derived. The algorithms have no way of knowing that this bill factor has changed. In such cases, the user may run derivation and specify a period for which to force derivation, so that re-derivation with new values may take place. Refer to the background processes Process IB-SPDB - SA Interval Profile Data Creation and Process IB-STDB - SA TOU Data Creation for information about running derivation through batch. Refer to Service Agreement - Interval Info for information about running derivation online.

Note:

The base derivation algorithms only support force derivation when there is source data other than interval data, such as a bill factor.

Process IB-SPDB - SA Interval Profile Data Creation

This process derives interval data for accounts in the system. Only accounts that have at least one interval service agreement with derivable profiles linked to it are processed. A 'derivable' profile is an SA Owned profile where this SA is the owner AND the profile type indicates an "Interval Data Creation" derivation algorithm. Interval data for service agreements linked to the account are derived in billing processing sequence order as defined on their SA type.

Refer to Determining What Interval Data To Derive and Start and End Times for Billing for information about which records are processed by the algorithm.

For each service agreement, the interval data creation algorithms are executed in creation priority order. Refer to Setting Up Interval Profile Types for more information about defining Interval Data Creation algorithm for an interval profile type.

This process supports Force Derivation and passes the related input parameters to the data derivation algorithms.

Note:

This process is designed to run in parallel threads. Every thread processes a range of accounts.

Any errors detected during this process cause the new data set to be created in Error status and an entry to be written to the Interval Data Exception table. You can fix these errors by canceling the newly created data set and fixing the source of the problem. Refer to How to Correct a Data Set in Error for more information.

Validation of Profile Data

In addition to specifying algorithms to create data for an interval profile, you may also create algorithms to validate interval profile data. As with the creation algorithms, your validations algorithms are specified on the interval profile type. An interval profile type may specify more than one validation algorithm. If so, they are executed in priority order.

Any errors detected by the validation algorithms cause the invalid data set to be marked in Error status and an entry to be written to the Interval Data Exception table. You can fix these errors by fixing the source of the problem. Refer to How to Correct a Data Set in Error for more information.

These algorithms may be executed in one of two ways:

- Through a background process that finds every interval profile whose interval profile type specifies a validation algorithm. If multiple validation algorithms exist for a given profile type, they are executed one after the other in their predefined sequence order. Refer to Process IPDSDVB - Interval Profile Data Validation for more information.

- There is a button available on the Interval Profile page that allows a user to execute the validation algorithms for a single profile. If multiple validation algorithms exist for a given profile type, they are executed one after the other in their predefined sequence order.

Process IPDSDVB - Interval Profile Data Validation

The IPDSDVB background process is used to validate interval profile data. It processes pending interval profiles that were created up to the cutoff date/time and executes their validation algorithms, if any, defined on the profile type. The algorithms are executed in their predefined sequence order.

The standard business date is used together with the installation base time to derive the cutoff date/time that is passed to the validation algorithms. For example, if the batch business processing date is 09/08/2003 and the installation base time is 2:00AM, the cutoff date/time is calculated as 09/08/2003 02:00AM. When no business date is specified, it is set to current date.

It is important that ALL validation algorithms are provided with the same cutoff date/time as their referenced date/time. This identifies the collection of pending interval profiles to be processed as of a given date/time. This way even if a new profile is created after one validation algorithm is executed but before a subsequent validation algorithm is executed, the new profile is still not processed because it was not created by the cutoff date/time.

Refer to Setting Up Interval Profile Types for more information about defining Interval Data Validation algorithm for an interval profile type.

Note:

This process is designed to run in parallel threads. Each thread processes a range of profiles.

Fastpath:

Refer to Validation of Profile Data for more information.

Auditing Your Interval Pricing Bill Lines

Given the amount of data used to produce a bill calculation line for an interval pricing rate component, how can a customer service representative audit this bill line to understand how it was calculated? Interval pricing rate components allow you to set up an Audit Algorithm. This audit algorithm retrieves the records used to produce the bill line. As a result, the audit algorithm should take advantage of the logic used in the calculation algorithm that produced the bill line. The relevant code should be shared between the two algorithms.

Refer to Interval Billing Calculation Details to view the results of calling an audit algorithm.

Refer to Setting Up Interval Pricing Rate Components for more information related to linking an audit algorithm to your rate component.

Warning:

Snapshots of the data used to generate a bill are not taken. Rather, auditing your interval pricing bill lines rely on the interval data tables. As a result, data records should not be changed. To correct an interval, you should add a new interval data set to correct the interval data. Refer to How To Correct a Data Set in Error for more information.

The Big Picture of Raw Data Collection and Aggregation

The topics in this section describe the ability of the system to collect raw interval data, provide the ability to run validation algorithms on this data, and aggregate data for use on interval profiles used for billing. This functionality is sometimes referred to as "meter read pretreatment".

Some organizations use an external system to collect and aggregate the raw interval data. This information is interfaced directly to the SA interval profiles as billable data. From there, contract based adjustments may be applied.

Some organizations use Oracle Utilities Customer Care and Billing to collect and aggregate their raw interval data. This information is interfaced to interval registers linked to the service point's meter. Validation algorithms may be applied against this data to ensure that the data is valid. Interval profile creation algorithms for the SA may aggregate the raw data from the appropriate service points to prepare for billing.

Note:

If your organization uses an external system for this functionality, skip this section.

Contents

Interval Channels and Index Channels

Installation of Interval and Index Channels

Validation of Register Data

Process IREGDVB - Interval Register Data Validation

Processing Raw Data

Interval Channels and Index Channels

Channel is a term often used for devices that may store data for complex metering customers. A physical channel may contain interval data or index readings:

- Index channels are a collection of time-of-use readings.

- The information is often considered more accurate than interval data.

- Index Channels are typically set up as a meter, where each register in the meter configuration represents a time of use code. Refer to The Structure Of A Meter for more information.

- Interval channels contain collections of interval data. This interval data follows the same logic as interval profile data. Refer to Interval Quantities are Stored in Data Sets, Fixing Errors with Complete Data Sets and Algorithms Find the Most Up To Date Data for more information. An interval channel is set up as a register that is marked as "interval". Interval register data may be linked to this interval register.

Your setup of meters, meter configurations, and registers is very flexible:

- The meter in the system doesn't have to represent a physical meter.

- The meter represents a single channel or a collection of channels.

- Any of the following meter configurations are possible:

- A single interval channel

- Multiple interval channels

- A collection of TOUs for an index channel

- A combination of interval registers and TOUs for an index channel

Fastpath:

Refer to Maintaining Meter Configurations for more topics related to meter configurations.

Note:

In Oracle Utilities Customer Care and Billing, the term "channel" is only used for the Channel ID on the register, which is used as an external ID. In the system, you will use meters, meter configurations and registers to model your channels.

No special logic is required for index channels. The reads for the time of use collection for an index channel require the same logic that exists for standard non-interval registers.

Installation of Interval and Index Channels

Installing a configuration for an index or interval channel to a service point is the same procedure as installing a configuration of standard registers.

- You must define the meter configuration that is being installed.

- The installation is effective-dated. There must be a meter read on the install date.

Note that for interval registers, register reads are not allowed. However, you may create meter reads without register reads in order to install a meter configuration with interval registers on a service point.

Fastpath:

Refer to SP/Meter Installation for more information about installing meters at service points.

Validation of Register Data

You may create algorithms to validate interval register data. Your validations algorithms are specified on the interval register type. An interval register type may specify multiple validation algorithms that are executed in priority order.

Any errors detected by the validation algorithms cause an invalid data set to be marked in Error status and an entry to be written to the Interval Register Data Exception table. You can fix these errors by fixing the source of the problem. Refer to How to Correct a Register Data Set in Error for more information.

These algorithms may be executed in one of two ways:

- Through a background process that finds every interval register with an interval register type that specifies a validation algorithm. If multiple validation algorithms exist for a given interval register type, they are executed in their predefined sequence order. Refer to Process IREGDVB - Interval Register Data Validation for more information.

- There is a button available on the Meter Configuration page that allows a user to execute the validation algorithms for all the interval registers linked to the meter configuration. If multiple validation algorithms exist for a given interval register type, they are executed one after the other in their predefined sequence order. Refer to Meter Configuration for more information.

Process IREGDVB - Interval Register Data Validation

The IREGDVB background process is used to validate interval register data. It processes pending interval registers that were created up to the cutoff date/time and executes their validation algorithms, if any, defined on their register type. The algorithms are executed one after the other in their predefined sequence order.

The standard business date is used together with the installation base time to derive the cutoff date/time that is passed to the validation algorithms. For example, if the batch business processing date is 09/08/2003 and the installation base time is 2:00AM, the cutoff date/time is calculated as 09/08/2003 02:00AM. When no business date is specified, it is set to current date.

It is important that ALL validation algorithms are provided with the same cutoff date/time as their referenced date/time. This identifies the collection of pending data sets to be processed as of a given date/time. This way even if a new data set is created after one validation algorithm is executed but before a subsequent validation algorithm is executed, the new data set is still not processed because it was not created by the cutoff date/time.

Refer to Setting Up Interval Register Types for more information about defining Interval Register Data Validation algorithm for an interval register type.

Note:

This process is designed to run in parallel threads. Every thread processes a range of registers.

Fastpath:

Refer to Validation of Register Data for more information.

Processing Raw Data

The raw interval data linked to your registers is not used directly by rate algorithms. The rate algorithms only process profile data linked to the service agreement. Valid interval register data is available for use by the profile data derivation algorithms to produce billable profile data for a service agreement. For example, a profile data derivation algorithm may aggregate the register data from multiple registers to produce a new load curve.

A challenge for the aggregation algorithms is to determine which register data is applicable for a given profile. The service agreement may be linked to multiple service points, each with many different possible configurations. Because the derivation algorithm is on the interval profile type, you cannot explicitly tell the algorithm which registers to use. The following information may be useful to the algorithms to determine the appropriate registers:

- Service points linked to the service agreement. First and foremost, the algorithms restrict the selection of registers to those for the service points linked to the service agreement.

- UOM and SQI. Each interval register type indicates a unit of measure and an optional SQI that may be used by algorithms. For example, the base algorithm, which performs aggregation, finds interval registers with a UOM that matches that of the interval profile type. This algorithm also has soft parameters to indicate whether the SQI codes on the interval register type and interval profile type should match.

- If these attributes are not enough to indicate the correct registers to the algorithms, characteristics are also available for use. There are characteristics on the service point, the SA/SP and the meter that may all be used to capture information available to the processing algorithms to determine the appropriate registers.

Fastpath:

Refer to Designing Interval Profile Types for more information about the aggregation algorithm provided with the system.

Applying Adjustments To Raw Data Prior to Aggregation

It is common for a contract to require adjustments to raw data prior to aggregating the data onto a profile. For example, perhaps all the data for a given register should be adjusted by 5% based on contract requirements. These adjustments may be applicable to only certain interval registers for the contract. In addition, it is common for more than one contract to use the same register data and perhaps only certain contracts require an adjustment to that data.

To satisfy this requirement, characteristics on the SA/SP may be used to indicate adjustment factors. The appropriate derivation algorithms may then apply the adjustment factors while aggregating the data.

Note:

The aggregation algorithm provided with the system does not apply any adjustment factors.

Fastpath:

Refer to Service Agreement - SA/SP for more information about SA/SP characteristics.

Time of Use Mapping Background Topics

This section describes information related to how data is stored for TOU Maps and how TOU Maps are linked to service agreements. For information about defining time of use codes and other related topics, refer to Time of Use Billing.

For information about defining time of use rate components, refer to Designing Your Time Of Use Rate Components. For information about defining TOU prices and values, refer to Bill Factor TOU Values .

Contents

Time Period Definitions are Stored in Data Sets

Sharing TOU Map Data

TOU Maps Linked to a Service Agreement

Customer Specific TOU Values

Generating Data for a TOU Map

Automatic Creation of TOU Map Data

Auditing Your TOU Pricing Bill Lines

Time Period Definitions are Stored in Data Sets

The time period definitions for a TOU map may have many different origins.

- It may be contract-related data that is set up at the beginning of the contract or contract year

- It may be interfaced from an external source periodically. This can occur when a customer's TOU map is defined dynamically based on information received from a third party.

- It may be that data needs to be overwritten for a given day. Perhaps the company has a planned interruption that changes the time period definitions for a given day. New data for the TOU map for that day needs to be linked to the map.

Regardless of the origin of the data, all data have similar characteristics:

- Data is received or created by the system periodically. The system stores whatever new data needs to be stored.

- The period represented by the batch of new data is variable.

- New data may be an update to previously received data.

Fastpath:

Refer to Interval Quantities are Stored in Data Sets for more information about how interval data is stored. This same model is used for TOU data. There is no difference.

Refer to Fixing Errors with Complete Data for information about how to distinguish fixing errors with complete data by creating new data sets. This same model is used for TOU data.

Note:

The system is able to generate data for a TOU map based on predefined templates. Refer to Generating TOU data for a TOU Map for more information.

Sharing TOU Map Data

TOU mapping data may be shared by more than one service agreement. There are several ways to accomplish this and your business rules will dictate the best way to do this.

Contents

TOU Map Common To All SAs on the Rate

TOU Map Common To a Subset of Service Agreements

TOU Map Owned by a Service Agreement

TOU Map Common To All SAs on the Rate

If a TOU pricing rate component on the service agreement's rate performs TOU mapping and/or pricing, it is possible that all service agreements for the rate use the same common TOU map. In this case, you indicate the TOU map to use directly on the rate component. In this scenario, no map information is needed for the service agreement. Refer to Designing Your Time Of Use Rate Components for more information.

TOU Map Common To a Subset of Service Agreements

If not all service agreements linked to your rate use the same TOU map for a TOU pricing rate component, it may still be the case that a subset of those service agreements use the same TOU map. In this case, the appropriate TOU map for each service agreement must be linked to the appropriate common TOU map.

To set up these types of service agreements correctly, the appropriate start option should indicate the common TOU map to link to the SA. Refer to Designing Your IB Start Options for more information.

TOU Map Owned by a Service Agreement

Some of your service agreement may require unique map data. These types of TOU maps are typically used for customers whose map data is determined by factors related to the specific contract. It is possible for SA owned TOU map types to reference data creation algorithms. This allows the TOU map data to be overridden or determined dynamically.

While SA Owned TOU maps are linked to a single "owner" SA, it's possible for this TOU map to be used by other service agreements (typically ones that are linked to the same account.)

To set up these types of service agreements correctly, the appropriate start option should indicate the TOU map type to use when creating a new SA Owned TOU map to link to the SA. Refer to Designing Your IB Start Options for more information.

TOU Maps Linked to a Service Agreement

As mentioned above, if a service agreement's rate performs TOU mapping and/or pricing and the TOU map to use varies for different service agreements, the appropriate map must be linked to the service agreement.

There may be other reasons to link a TOU map to a service agreement. For example, a data derivation algorithm may require a TOU map for the service agreement.

The topics in this section describe other logic related to linking a TOU map to a service agreement.

Contents

TOU Maps Serve a Role for a Service Agreement

The Link between TOU Map and SA is Effective Dated

TOU Maps Serve a Role for a Service Agreement

A TOU map may be linked to a service agreement to serve a variety of purposes, for example:

- Rate algorithms map interval quantities in order to apply prices for each TOU.

- Data derivation algorithms compare quantities to TOU values in order to validate the data or produce a new curve.

When linking a TOU map to a service agreement, the role that it is serving must be indicated. The "role" is specified using a TOU Map Relationship Type.

This is the same model as the one used to link interval profiles to service agreements. Refer to Interval Data Serves a Role for a Service Agreement for more information.

If a TOU pricing rate component indicates a TOU map relationship type, it is used to find the correct TOU map for the service agreement for mapping the interval data. Refer to Setting Up TOU Mapping Rate Components for more information.

The Link between TOU Map and SA is Effective Dated

An SA /TOU Map link is effective dated. Therefore, the TOU map serving a given role may change over time.

This is the same model as the one used to link interval profiles to service agreements. Refer to The Link between Profile and SA is Effective Dated for more information.

Customer Specific TOU Values

As described in Bill Factor TOU Values , a bill factor may define prices or values for a collection of time of use codes. A TOU bill factor may also indicate that the value can be found in a contract term. This enables you to define customer specific time-of-use prices or contract values.

The TOU Contract Values page enables you to define a set of values for a collection of time-of-use codes. The collection is effective dated. This data is available for use by rate component algorithms that apply prices for time-of-use quantities or data derivation algorithms that need contract based TOU values to perform derivation. Refer to Service Agreement - TOU Contract Values for more information about defining TOU Contract Values.

Generating Data for a TOU Map

The data for a TOU map is a collection of date and time intervals and their corresponding time-of-use codes. Even though you may have several consecutive time periods referencing the same time-of-use code, each interval must be separately defined.

In order to facilitate the creation of data for a TOU map, the system enables you to define TOU map templates and provides you with the ability to generate data for a TOU map based on this template.

Actually, you may define a series of templates that work together to produce data for a TOU map. For example:

- Use a daily template to define time period ranges in a day with their associated TOU codes.

- Use a weekly template to define days of the week and the appropriate daily templates to use for each day.

- Use calendar template to define the weekly and daily templates applicable for actual dates in a year.

The following diagram illustrates a simple example of a collection of templates you may define for a summer period.

In the above example, a US resident may notice that no holiday is defined for the 4 th of July. One would expect that if a holiday falls on a weekday, the typical weekday time period definitions may not apply.

The system is designed so that you don't have to define holidays in a TOU map template with their explicit dates.

- You have already defined which days of the year are holidays on the Calendar table.

- If all your holidays follow the same time period definition requirements, define a daily template that should be used for holidays.

When generating data for a TOU map, you are asked for:

- The appropriate calendar where your holidays are defined

- The holiday template

The TOU data generator automatically uses the holiday map for holidays defined in the calendar table.

Fastpath:

Refer to Setting up TOU Map Templates for more information about defining your TOU map templates.

Refer to TOU Map Generation for more information about generating data for a TOU map based on a template.

Automatic Creation of TOU Map Data

The section Generating Data for a TOU Map describes how TOU map templates may be set up and used to generate TOU map data. When defining the appropriate TOU map for a given contract, you typically generate the TOU map data at the beginning of the contract year.

However, for many contracts, you may define special situations, such as interruptions, when an override TOU map is applicable for a certain time period. In fact, you may have a group of customers, who are all affected by the same interruption. The system allows you to configure your interval billing options such that once your interruption period has been defined an override TOU map for that interruption period can be generated for all customers.

In order to generate TOU map data, you need to design and create an appropriate algorithm. TOU map creation algorithms are linked to the TOU map type. You also need to define the "special situation", for example, the interruption.

Refer to Contract Option Background Topics for more information about special events that may alter the rate calculations.

In addition, refer to Interval Billing Examples - Override Maps for an example of how to set up an interruption example.

TOU map creation algorithms may be executed in one of the following ways:

- Through a background process that finds every SA that has a TOU map with a TOU map type that indicates a creation algorithm. Refer to Process IB-STDB - SA TOU Data Creation for more information.

- There is a button available on the SA Interval Info page that allows a user to execute the TOU data derivation algorithms for a single SA.

- There is a button available on the Account Interval Info page that allows a user to execute the TOU data derivation algorithms for all the service agreements for an account. The service agreements are processed in the billing processing sequence order defined on their SA type.

Contents

Determining What TOU Data To Derive

Force Derivation for TOU Map Data

Process IB-STDB - SA TOU Data Creation

Determining What TOU Data To Derive

Refer to Determining What Interval Data To Derive for detail about ensuring that no gaps exist and ensuring that the algorithms are always using the latest data for derivation.

Note:

one difference between the base TOU creation algorithms and the base interval derivation algorithms is that the TOU creation algorithms do not use a Number of Days to Process. This is because the base algorithm processes contract option events and the volume of contract option events in the system is not as high as the volume processed by the interval data derivation algorithms.

Force Derivation for TOU Map Data

Refer to Force Derivation of Interval Data for information on how the system may allow a user to force derivation for situations where the system may not be able to detect that source data has changed. The same logic is available for TOU map creation algorithms.

Note:

The source data for the base TOU map creation algorithms is always contract option data and as a result, there is no need to support Force Derivation in those algorithms.

Process IB-STDB - SA TOU Data Creation

This process derives TOU map data for accounts in the system. Only accounts that have at least one interval service agreement with derivable TOU maps linked to it are processed. A 'derivable' map is an SA Owned map where this SA is the owner AND the map type indicates a "TOU Data Creation" algorithm. TOU map data for service agreements linked to the Account are derived in billing processing sequence order as defined on their SA type.

For each service agreement, the TOU Map Creation algorithms are executed in creation priority order. Refer to Setting Up TOU Map Types for more information about defining a TOU Data Creation algorithm for a TOU map type.

This process supports Force Derivation and passes the related input parameters to the data creation algorithms.

Note:

This process is designed to run in parallel threads. Each thread processes a range of accounts.

Any errors detected during this process cause the new data set to be created in Error status and an entry to be written to the TOU Data Exception table. You can fix these errors by canceling the newly created data set and fixing the source of the problem. Refer to How to Correct a TOU Data Set in Error for more information.

Auditing Your TOU Pricing Bill Lines

Just as with interval pricing rate components, TOU pricing rate components may also use an audit algorithm to enable a user to view the details of the calculations.

Refer to Interval Billing Calculation Details to view the results of calling an audit algorithm.

Refer to Setting Up TOU Pricing Rate Components for more information related to linking an audit algorithm to your rate component.

Warning:

Snapshots of the data used to generate a bill are not taken. Rather, auditing your TOU pricing bill lines rely on the interval data and TOU mapping data tables. As a result, data records should not be changed. To correct data, you should add a new data set. Refer to How To Correct a Data Set in Error for more information.

Contract Option Background Topics

ontract Option Background Topics

This section describes information related to contract options under which certain calculations supporting a contract's rate may be overridden or altered occasionally for specific periods of time. Also refer to Designing Your Contract Options for more information .

Contents

Overview

A Contract Option Has Events

Options and Events May Have Characteristics

SA May Override a Shared Event

Validation of Events

Overview

For some of your interval billing customers, you may define additional options under which certain calculations supporting the customer's rate may be overridden or altered occasionally for specific periods of time. Some examples of such options are:

- Special days throughout the year on which the contract's TOU map is overridden with a special predefined TOU pattern specified for that type of day

- Periods of time during which customers are required to lower their demand by a predefined contractual amount of power

- Occasional offers to pay a special price for energy falling within a specific demand range

A Contract Option Has Events

A contract option must be defined for each special option on a given rate. The contract option is linked to every service agreement eligible for this option.

The option may be related to a given service agreement or may be linked to many service agreements.

Fastpath:

Refer to Contract Option Maintenance for more information about creating contract options and refer to Service Agreement - Contract Option for more information about linking contract options to service agreements.

Each contract option contains a collection of contract option events. The events are the individual instances of the special option. Each event indicates its effective period. A given contract option may define different types of events. For example, perhaps you have several types of interruptions that should cause different overrides to occur. It is the responsibility of your data derivation algorithms and/or your rate algorithms to know how to process these events for a customer who may have contract options.

Fastpath:

Refer to Contract Option Event Maintenance for more information about creating contract option events.

The following are some examples of algorithms that may process contract option events:

- You may have a TOU map creation algorithm that creates override TOU map data for the period defined on a contract option event. This override map may define different time-of-use codes for a certain time period, where different prices are applicable or may alter the time period definitions for this special time periods. The standard TOU pricing rate component would then apply the appropriate prices for this override time period.

- You may have a TOU pricing rate component that only applies a charge if contract option events exist for billing period. For example, it may calculate a special charge based on whether a customer reduced their demand during a specific period.

Fastpath:

For more examples, refer to Interval Billing Examples.

Options and Events May Have Characteristics

It is possible that your algorithms require extra information related to a contract option or a contract option event. For example, perhaps the customer's demand during a contract option event period must be compared to a subscribed demand. Perhaps the subscribed demand is applicable to all customers linked to this contract option. Or perhaps the subscribed demand changes for each instance of the option, in other words for each event.

Characteristics are used to define this extra information. Your algorithms would then use the information in the characteristic collection for either the contract option or the contract option event during its processing.

SA May Override a Shared Event

There may be cases where an individual customer wants to override the effects of a shared contract option event. If a given contract option event is not applicable to one of the service agreements linked to the contract option, a contract option event override may be created for this service agreement. The existence of an override cancels the effects of the shared contract option event for that SA.

You may also cancel an override, which essentially reinstates the specific event for the service agreement.

Note:

Algorithms that process contract option events must process the service agreement overrides as well. This includes processing overrides that are subsequently canceled.

Fastpath:

Refer to Service Agreement - Contract Option for more information about entering contract option overrides.

Validation of Events

The system provides you with the ability to run validation algorithms to validate your events. The validation algorithms may be used, for example, to validate the characteristics linked to your events. You may define separate validation algorithms that are executed based on the status:

- Pending algorithms are executed when adding or changing a record in Pending status.

- Freeze algorithms are executed when attempting to change the status from Pending to Freeze .

- Cancel algorithms are executed when attempting to change the status from Freeze to Cancel .

Fastpath:

Refer to Designing Your Contract Option Types for more information about contract option event algorithms.

Maintaining Interval Data

In this section, we describe the pages that maintain interval billing and TOU mapping information.

Contents

Account Interval Info Maintenance

Interval Profile Maintenance

Maintaining Interval Profile Data

Maintaining Interval Register Data

TOU Map Maintenance

Maintaining TOU Map Data

Contract Option Maintenance

Maintaining Contract Option Events

Interval Billing Calculation Details

Account Interval Info Maintenance

Open Main Menu, Customer Information, Account Interval Information to view interval profiles and TOU maps for service agreements linked to the account.

Note:

This page is only available if the Complex Billing module is not turned off.

Description of Page

The Account Info displays information about the account. The Account ID for this account is displayed.

Use the Derive Interval Data button to create profile data through data derivation. If clicked, the Derive Interval Data dialog opens.

In the resulting dialog, turn on Force Derivation and enter a Force Derivation Start Date if you want the system to re-derive data for a period that may have already been derived.

Note:

Not all algorithms necessarily support force derivation. It depends on whether or not the algorithm can detect changes in the source data.

Enter the Cutoff Date to indicate date until which to generate data.

After clicking Process, the system processes all service agreements for the account that have an SA Owned profile where this SA is the owner AND the profile type indicates an "Interval Data Creation" derivation algorithm. Interval data for service agreements linked to the Account are derived in billing processing sequence order as defined on their SA type. For each service agreement, the Interval Data Creation algorithms are executed in creation priority order as defined on their profile type.

The interval profile tree displays information about profiles linked to service agreements for this account.

- A node appears for each profile linked to more than one service agreement for the account. The profile may be common or SA owned . Expanding this node displays each service agreement linked to the shared profile.

- A node appears for each service agreement linked to the account that has interval profiles linked to it. Expanding this node displays each profile linked to the service agreement.

Use the Derive TOU Data button to automatically create TOU map data. If clicked, the Derive Interval Data dialog opens.

In the resulting dialog, turn on Force Derivation and enter a Force Derivation Start Date if you want the system to re-derive data for a period that may have already been derived.

Note:

Not all algorithms necessarily support force derivation. It depends on whether or not the algorithm can detect changes in the source data.

Enter the Cutoff Date to indicate the date until which to generate data.

After clicking Process, the system processes all service agreements for the account that have an SA Owned TOU map where this SA is the owner AND the TOU map type indicates a "TOU Data Creation" derivation algorithm. Interval data for service agreements linked to the Account are derived in billing processing sequence order as defined on their SA type. For each service agreement, the TOU Data Creation algorithms are executed in creation priority order as defined on their TOU map type.

The TOU map tree displays information about TOU maps linked to service agreements for this account.

- A node appears for each TOU map linked to more than one service agreement for the account. This TOU map may be common or SA owned . Expanding this node displays each service agreement linked to the shared TOU map.

- A node appears for each service agreement linked to the account that has TOU maps linked to it. Expanding this node displays each TOU map linked to the service agreement.

If a seasonal time shift record is linked to the base time zone and each time zone on the characteristic premise for each service agreement uses the same seasonal time shift record, the common Seasonal Time Shift for the time zones on the characteristic premises is displayed. Refer to Time Zone and Time Changes for more information.

The Seasonal Time Shift Remark indicates whether the data is displayed in legal time or standard time. If the seasonal time shift record on the base time zone and for the time zone for each characteristic premise linked to each SA are the same, the dates are displayed in legal time, according to this seasonal time shift record. Otherwise, the data is displayed in standard time.

Fastpath:

Refer to Seasonal Time Shifts for more information.

Interval Profile Maintenance

Use this page to view information about a profile, its data sets and its service agreements.

Contents

Interval Profile - Main

Interval Profile - Related SAs

Interval Profile - Main

Open Main Menu, Interval Billing, Interval Profile to maintain interval profiles.

Note:

This page is only available if the Complex Billing module is not turned off.

Description of Page

The Interval Profile Info contains important information about the interval profile. These values only appear after the interval profile exists on the database. The Interval Profile ID is a system-assigned number.

Enter the Description of the Interval Profile.

Indicate the Interval Profile Type that defines this interval profile.

The External ID is available for cross-referencing this interval profile with an external source.

If this profile is SA Owned , the SA ID linked to this profile is displayed along with information about the SA.

Use the Complete Data Sets button if you have any pending data sets for your profile and you would like the system to complete them. When clicking this button, if the profile type contains any validation algorithms, they are executed. If no errors are detected from the profile type's validation algorithms OR if the profile type does not contain any algorithms, the pending data sets are marked as complete . Refer to Validation of Profile Data for more information about the validation algorithms.

The tree at the bottom of this page shows information about data sets linked to the profile.

- The Pending Data Sets node displays if any of the data sets linked to the profile are pending . Expanding this node displays each pending data set.

- The Error Data Sets node displays if any of the data sets linked to the profile are in error . Expanding this node displays each error data set.

- The Data Created Through node displays the date of the latest complete interval as of the current date. Expanding this node displays the last 10 complete data sets.

Interval Profile - Related SAs

Open Main Menu, Interval Billing, Interval Profile and navigate to the Related SAs tab to view service agreements to which this profile is linked.

Note:

This page is only available if the Complex Billing module is not turned off.

Description of Page

The Interval Profile Info contains important information about the interval profile. These values only appear after the interval profile exists on the database. The Interval Profile ID is a system-assigned number.

Note:

If the profile is linked to more than 25 service agreements, the search criteria are intentionally left blank in order to avoid retrieving all service agreements (with the resultant slow response times). You must therefore use the SA Filter to define the type of service agreements that should be retrieved. See the below for more information about this page's search criteria.

Use the SA Filter to define the service agreements to appear in the grid. The following options are available:

- Account. Use this option to restrict service agreements to those linked to a given Account ID.

- Address. Use this option to restrict service agreements to those linked to service points associated with a given Address, City and/or Postal code. You can specify any combination of these fields.

- All. Use this option if you do not want to filter service agreements.

- Person Name. Use this option to restrict service agreements to those whose account indicates the given Name as the main person.

- SA Type. Use this option to restrict service agreements to those linked to a given CIS Division and SA Type.

Don't forget to click the search button after changing the SA Filter.

The grid that follows contains the Accountsand Service Agreements that match your search criteria.

Maintaining Interval Profile Data

In this section, we describe information related to maintaining interval data. This information includes where to maintain the data, the life cycle that this data may go through, uploading data from an external source and handling exception conditions.

Contents

Life Cycle of Interval Profile Data Sets

Interval Data Maintenance

Interval Data Query

Upload Interval Data

Process IPDSIDB - Determine Profile For Profile Datasets

Interval Data Exception

Life Cycle of Interval Profile Data Sets

The following diagram shows the possible lifecycle of an interval profile data set.

Pending Use this status for data, added to the system, that requires validation to occur before it is available for further processing. Validation is handled through an algorithm linked to the profile type for this data set's profile. Refer to Setting Up Interval Profile Types for more information. When creating a data set, the system automatically sets the status to Pending when the profile type indicates a validation algorithm or if an interval profile has not been identified.

Canceled A user can cancel a Pending or Error data set if the data set should not be used for further processing. Refer to Interval Data Maintenance for more information. Additionally, algorithms may be designed to cancel data sets in certain situations.

Error A validation or derivation algorithm may set this status for a data set if it detects an error condition. Data sets in this status are also written to the Interval Data Exception table. Refer to How To Correct a Data Set in Error. When a validation error has been corrected, change the status of the data set back to Pending so it will be reprocessed.

Complete Only complete data sets are used by rate application and derivation algorithms. If data being added to the system has already been validated, it may be uploaded to the system in this status. Data derivation algorithms may create a data set in Complete status or change the status of a data set to Complete if no error conditions are detected. Data validation algorithms may change the status of a data set to Complete if no error conditions are detected. When creating a data set, the system automatically sets the status to Complete when the profile type for the interval profile does not indicate a validation algorithm.

A data set is created either in Pending status or Complete status, depending on the existence of a validation algorithm on the profile type. A user can cancel a dataset. Other status changes may depend on how your validation and creation algorithms are written.

- The base validation algorithm only processes Pending data sets. As a result, a user is expected to change the status of an error data set back to pending when the error condition has been fixed. When the data is clean, the algorithm changes the status to Complete .

- The base creation algorithms automatically delete any Error data sets and start over in an attempt to produce a Complete data set. This is similar to the billing process, which deletes error bill segments and tries from the beginning to produce an error free segment. Another alternative is for a user to Cancel any data sets in Error to keep a record of the incorrect data.

For more information about data derivation and validation algorithms, refer to Setting Up Interval Profile Types.

Interval Data Maintenance

The Interval Data page is used to create and maintain collections of interval data, grouped together by an interval data set, for a given interval profile. The data that is maintained here may be for a common interval profile or for an SA owned interval profile.

Open Main Menu, Interval Billing, Interval Data to maintain interval data.

Note:

This page is only available if the Complex Billing module is not turned off.

Description of Page

Interval Data Set is a concatenation of important information about the data set. The Interval Data Set ID is a system-assigned random number.

Indicate the Interval Profile ID to which this data set is linked.

Note:

It is possible that the profile cannot be identified when adding interval data. If the Interval Profile is not populated, the Data Set External ID must be populated. Refer to Upload Interval Data for more information.

The Owner SA indicates the SA that "owns" this data. This information is only populated for SA owned profiles. This field is useful if the data set you are viewing contains an error and the error is related to a different source profile for the service agreement. You may use the context button to quickly navigate to the service agreement to view other profiles related to the service agreement. Refer to how to correct a data set in error for more information.

The Data Set External ID is the external identifier of the interval profile. It may be used when a profile cannot be found for data interfaced from outside the system. Refer to Upload Interval Data for more information.

The Set Date/Time of the Interval Data Set represent when this collection of data was entered or received. This is considered a server date and follows the seasonal time shifting as defined on the base time zone. Refer to Seasonal Time Shifts for more information.

Fastpath:

Refer to Algorithms Find the Most Up-To-Date Data for more information about the Set Date /Time and its use in algorithms.

The Data Set Type is available for classification of the data set in some way. The value currently available with the system is No Data . Refer to Fixing Errors with Complete Data for more information about using this data set type.

Note:

The values for Data Set Type are customizable using the lookup table. This field name is INTV_DS_TYPE_FLG.

The Status indicates the status of the interval profile data set. Click the Cancel DS button to cancel a Pending or Error data set.

Fastpath:

Refer to Lifecycle of Interval Profile Data for more information about interval data set status.

Use the Revert button to reverse the effect of a Complete data set.

Fastpath:

Refer to Fixing Errors with Complete Data for more information.

Use the Start Date/Time to indicate the starting point for the display of the interval data.

At least one interval data record must exist in the collection of interval data. For each interval data record, the Interval Data Date/Time and the Interval Data value are captured. This date is considered a logical date and follows the seasonal time shifting as defined on the interval profile type. Refer to Seasonal Time Shifts for more information.

If the data set is in Error status, a Message that provides the error information is displayed below the interval data collection.

If seasonal time shift records are linked to both the base time zone and the interval profile type, the Seasonal Time Shift associated with your interval profile type is displayed. Refer to Setting Up Interval Profile Types for more information.

Refer to Interval Time Display for more information. If the data is displayed in legal time use the Show in Standard button to toggle to standard time. If the data is displayed in standard time use the Show in Legal button to toggle to legal time. If either the bill factor/characteristic or the base time zone does not indicate a seasonal time shift record, the toggle button is not visible and data is displayed and expected in standard time.

If seasonal time shift records are linked to both the base time zone and the interval profile type, the Seasonal Time Shift Remark indicates whether the data is displayed and should be entered in legal time or standard time. Refer to Interval Time Display for more information. If the data is displayed in legal time use the Show in Standard button to toggle to standard time. If the data is displayed in standard time use the Show in Legal button to toggle to legal time. If either the interval profile type or the base time zone does not indicate a seasonal time shift record, the toggle button is not visible and data is displayed and expected in standard time.

Interval Data Query

This query shows the most recent interval profile data for a profile and a time period as of a given time.

Open Main Menu, Interval Billing, Interval Data Query to display interval data.

Note:

This page is only available if the Complex Billing module is not turned off.

Description of Page

The Interval Profile ID is the identifier of the profile whose data should be displayed.

Use the Start Date/Time and End Date/Time if you want to limit the query to a specific time period.

Use the Set Date/Time to indicate the "as of what date" to use for retrieving interval data. Only data sets with a set date/time prior to this date/time are accessed.

The Selection Type is used to determine what data to show:

History This option displays all interval data for the profile and time period, if specified. It includes data in data sets of any status value.

Most Recent Comp. Exc. No Data This option finds the most recent interval value for each interval from completed data sets only. If the most recent interval is in a No Data data set, that interval does not appear.

Most Recent Complete Data This finds the most recent interval value for each interval from completed data sets only. If the most recent interval is in a No Data data set, that interval appears with "No Data" displayed in the Data Set Type column.

Fastpath:

Refer to Fixing Errors with Complete Data for more information about No Data interval data sets.

Once you have selected your criteria, use the search button to display the data. The interval data collection contains the following information:

The Interval Data Date/Time and Interval Data value for each interval is displayed. Adjacent, information about the data set to which this interval is linked is displayed, including the Data Set Type, Set Date/Time and Interval Data Set ID.

If seasonal time shift records are linked to both the base time zone and the interval profile type, the Seasonal Time Shift associated with your interval profile type is displayed.

If seasonal time shift records are linked to both the base time zone and the interval profile type, the Seasonal Time Shift Remark indicates whether the data is displayed and should be entered in legal time or standard time. Refer to Interval Time Display for more information. If the data is displayed in legal time use the Show in Standard button to toggle to standard time. If the data is displayed in standard time use the Show in Legal button to toggle to legal time. If either the interval profile type or the base time zone do not indicate a seasonal time shift record, the toggle button is not visible and data is displayed and expected in standard time.

Upload Interval Data

The following diagram illustrates the processes involved in the uploading of interval data into the system.

The topics in this section describe how these processes work.

Contents

Process X - Populate Interval Data

Interval Data Set

Interval Data

Interval Data Set Key

Process X - Populate Interval Data

Process X refers to the mechanism used by your organization to populate the Interval Data tables. Process X has the following responsibilities:

- It attempts to determine the appropriate profile to which this data belongs using the external ID. If a profile with this external ID is not found, the data set is created without being linked to a profile and the external ID is stored on the data set.

- It creates a new interval data set with the current date and time.

- If the interval data is from a different time zone, or is not in standard time for the base time zone, the time of each interval must be converted to standard time in the base time zone. Refer to Time Zone and Time Changes for more information.

- All quantities being uploaded for the same profile should be inserted into the Interval Data table and should reference the same interval data set.

- Set the status of the new data set:

- If the data set is not linked to a profile, set the status to pending.

- If the profile type has a validation algorithm, set the status to pending.

- If the profile type does not have a validation algorithm, this data should be clean. Set the status to complete.

- Inserts a record in the interval data set key table.

The topics in this section describe the tables to populate.

Interval Data Set

You must create a data set for each batch of records being uploaded in the system for the same profile. The name of this table is CI_INTV_DATA_SET . The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

INTV_DATA_SET_ID

12

Y

A/N

This is a unique key. This key is referenced on the interval data record.

It's suggested that this key is built as follows:

- • The first five digits are the first five digits of the INTV_PF_ID

- • The last seven digits are randomly generated.
This facilitates set based processing of the data. If your process that inserts records on this table is capable of calling a COBOL routine, call CIPZKEYG passing the first five digits and it supplies a seven digit random number.

INTV_PF_ID

12

N

A/N

This is a foreign key reference to the interval profile to which this set is linked. It is required if an external ID is not specified.

INTV_DS_EXT_ID

60

N

A/N

This is the external identifier of the profile to which this data belongs. It is required if profile ID is not specified.

SET_DTTM

26

Y

DateTime

This is the date/time that the data set was received. This must be populated with the current date/time. This is considered a server date and follows the seasonal time shifting as defined on the base time zone. Refer to Seasonal Time Shifts for more information.

Refer to Algorithms Find the Most Up-To-Date Data for information about why this date/time is important.

SET_STATUS_FLG

2

Y

A/N

Set this value based on whether it will be validated in the system.

Set to P for Pending if the profile ID is blank or if the profile's profile type indicates a validation algorithm.

Set to C for Complete if the data should not go through any further validation.

Refer to Life Cycle of Interval Profile Data for more information

Interval Data

Each piece of interval data for the profile is stored as an Interval Data record linked to the newly created data set. The name of this table is CI_INTV_DATA . The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

INTV_DATA_SET_ID

12

Y

A/N

This is a foreign key reference to the Interval Data Set that groups the interval values together. This should be your newly created ID from above.

INTV_DATA_DTTM

26

Y

DateTime

This is the date and time of the interval value. This must be stored in standard time for the base time zone. Refer to Time Zone and Time Changes for more information.

INTV_DATA

18.7

Y

N

This is the quantity for the interval.

Interval Data Set Key

When a system-generated key value is assigned to a record, you need to also store the key value in a key table that corresponds to the record's database table. The name of this table is CI_INTV_DATA_SET_K . The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

INTV_DATA_SET_ID

12

Y

A/N

This should be your newly created Interval Data Set ID from above.

ENV_ID

6

Y

N

This is the environment id defined on the installation options.

Process IPDSIDB - Determine Profile For Profile Datasets

This process finds pending profile datasets that are not linked to a profile and attempts to determine the appropriate profile by making a match on the external ID.

Note:

. The status of the profile dataset is set to Pending or Complete by the system based on whether or not validation algorithms exist for the profile type. Refer to Life Cycle of Interval Profile Data Sets for more information.

Interval Data Exception

If a validation algorithm or data derivation algorithm finds an error with interval data, a record is written to the interval data exception table with a message indicating the nature of the severe error.

To view the messages associated with the exception records, you must schedule an appropriate To Do entry creation background process. This process generates a To Do entry for every record in the interval data exception table.

The following section describes steps to take to correct the data in error.

How To Correct a Data Set in Error

A data set is in error only if an error is found by a validation algorithm or by a data derivation algorithm. Because there is no limit to the number of validation and data derivation algorithms that you create, there may be just as many ways to resolve these errors. This section describes a typical situation.

Contents

Resolving a Derivation Error

Resolving a Validation Error

R esolving a Derivation Error

Because the derivation algorithms are creating new data sets, the error is not with the data set being created, but with source data that the algorithm is using to create the new data set.

The following describes the steps involved with fixing an error found by a creation algorithm ( IPFCSACS ) supplied with the system.

- Review the To Do entries generated as a result of interval data exceptions.

- The information displayed with the To Do entry provides details of the error. You may also drill down to the Data Set page to view the error.

On the Data Set page, the status is Error and the error message is displayed at the bottom. You probably have to fix a source interval data curve. This is common source of errors in derived data. One possible error is that data is missing from a source curve.

The following describes the steps to fix a source interval data profile:

- The error indicates that the problem is with the DEMANDKW profile relationship type. Use the context menu button adjacent to the owner SA to Go To Service Agreement. You are taken directly to the Service Agreement Interval Info page. Determine the profile associated with the DEMANDKW relationship type.

- Choose Go To Interval Data from the context menu for the appropriate Interval Profile ID and find the data set with the missing interval. Verify all the missing intervals that need to be fixed. (Note that the error message only reports the first missing interval it finds. There may be more.)

- Once you have determined the missing intervals, create a new data set for the profile, and enter the missing interval data.

Warning:

Existing completed data records should not be changed. If an existing data record is incorrect, you should always add a new data set, with the current date and time, and enter the corrected value for the interval. This is important because the interval data records are the audit records for an existing bill. Refer to Auditing Your Interval Pricing Bill Lines for more information.

- Once you have filled in the missing intervals, you may navigate back to the Service Agreement Interval Info page to run the data derivation again. (Note, you may also wait for the SA Interval Profile Creation background process to run.)

- When the Data Derivation is finished, view the Interval Data page for the profile with the derived data. You should notice that your Error data set is no longer there.

R esolving a Validation Error

The validation algorithms are validating data in existing data sets. The data set in error is marked and the chances are great that the error is with this data.

The following describes the steps involved with fixing an error found by the validation algorithm ( IPFVDS-SMP) supplied with the system.

- Review the To Do entries generated as a result of interval data exceptions.

- The information displayed with the To Do entry provides details of the error. Drill down to the detail of the record on the Interval Data.

- Fix the error and change the status of the data set to Pending . The next time the validation algorithm runs, it revalidates this data.

Maintaining Interval Register Data

In this section, we describe information related to maintaining interval register data. This information includes where to maintain the data, the life cycle that this data may go through, uploading data from an external source, and handling exception conditions.

Contents

Life Cycle of Interval Register Data Sets

Interval Register Data Maintenance

Interval Register Data Query

Upload Interval Register Data

Process IREGIDB - Determine Register For Register Datasets

Interval Register Data Exception

Life Cycle of Interval Register Data Sets

The following diagram shows the possible lifecycle of an interval register data set.

Pending Use this status for data, added to the system, that requires validation to occur before it is available for further processing. Validation is handled through an algorithm linked to the interval register type for this data set's register. Refer to Setting Up Interval Register Types for more information. When creating a data set, the system automatically sets the status to Pending when the interval register type indicates a validation algorithm.

Canceled A user can cancel a Pending or Error data set if the data set should not be used for further processing. Refer to Interval Register Data Maintenance for more information. Additionally, algorithms may be designed to cancel data sets in certain situations.

Error A validation algorithm may set this status for a data set if it detects an error condition. Data sets in error are also written to the Interval Register Data Exception table. Refer to How To Correct a Register Data Set in Error. When a validation error has been corrected, change the status of the data set back to Pending so it will be reprocessed.

Complete Only complete data sets are used by derivation algorithms. If data being added to the system has already been validated, it may be uploaded to the system in this status. Validation algorithms may change the status of a data set to Complete if no error conditions are detected. When data sets are created, their status is set to Complete if the interval register type does not indicate a validation algorithm. For more informationabout validation algorithms, refer to Setting Up Interval Register Types.

Interval Register Data Maintenance

The Interval Register Data page is used to create and maintain collections of interval register data, grouped together by a data set, for a given interval register.

Open Main Menu, Interval Billing, Interval Register Data to maintain interval register data.

Note:

This page is only available if the Meter Data Management module is not turned off.

Description of Page

Register Data Set is a concatenation of important information about the data set. The Register Data Set ID is a system-assigned random number.

Indicate the Register ID to which this data set is linked.

Note:

It is possible that the register cannot be identified when adding interval register data. If the Register ID is not populated, the Data Set External ID must be populated. Refer to Upload Interval Register Data for more information.

The Data Set External ID is the external identifier of the interval register. It will correspond to the channel ID on the interval register. It may be used when a register cannot be found for data interfaced from outside the system. Refer to Upload Interval Register Data for more information.

The Set Date/Time of the Register Data Set represent when this collection of data was entered or received. This is considered a server date and follows the seasonal time shifting as defined on the base time zone. Refer to Seasonal Time Shifts for more information.

Fastpath:

Refer to Algorithms Find the Most Up-To-Date Data for more information about the Set Date /Time and its use in algorithms.

The Data Set Type is available for classification of the data set in some way. The values currently available with the system are:

No Data Refer to Fixing Errors with Complete Data for more information about using this data set type.

Estimation Use this value if the data set contains estimated values based on a validation algorithm. Refer to IRVA-CLN for an example of an algorithm that creates estimated interval register values.

Note:

The values for Data Set Type are customizable using the lookup table. This field name is REG_DS_TYPE_FLG.

The Status indicates the status of the interval profile data set. Click Cancel DS to cancel a Pending or Error data set.

Fastpath:

Refer to Lifecycle of Interval Register Data for more information about interval data set status.

Use the Revert button to reverse the effect of a Complete data set.

Fastpath:

Refer to Fixing Errors with Complete Data for more information.

Use the Start Date/Time to indicate the starting point for the display of the interval data.

At least one interval data record must exist in the collection of interval data. For each interval data record, the Interval Register Date/Time and the Interval Register Data value are captured. This date is considered a logical date and follows the seasonal time shifting as defined on the interval register type. Refer to Seasonal Time Shifts for more information.

If the data set is in Error status, a Message that provides the error information is displayed below the interval data collection.

If seasonal time shift records are linked to both the base time zone and the interval register type, the Seasonal Time Shift associated with your interval register type is displayed. Refer to Setting Up Interval Register Types for more information.

If seasonal time shift records are linked to both the base time zone and the interval register type, the Seasonal Time Shift Remark indicates whether the data is displayed and should be entered in legal time or standard time. Refer to Interval Time Display for more information. If the data is displayed in legal time use the Show in Standard button to toggle to standard time. If the data is displayed in standard time use the Show in Legal button to toggle to legal time. If either the interval register type or the base time zone do not indicate a seasonal time shift record, the toggle button is not visible and data is displayed and expected in standard time.

Interval Register Data Query

This query shows the most recent interval register data for a register and a time period as of a given time.

Open Main Menu, Interval Billing, Interval Register Data Query to display interval register data.

Note:

This page is only available if the Meter Data Management module is not turned off.

Description of Page

The Register ID is the identifier of the register whose data should be displayed.

Use the Start Date/Time and End Date/Time if you want to limit the query to a specific time period.

Use the Set Date/Time to indicate the "as of what date" to use for retrieving interval data. Only data sets with a set date/time prior to this date/time are accessed.

The Selection Type is used to determine what data to show:

History This option displays all interval data for the register and time period, if specified. It includes data in data sets of any status value.

Most Recent Comp. Exc. No Data This option finds the most recent interval value for each interval from completed data sets only. If the most recent interval is in a No Data data set, that interval does not appear.

Most Recent Complete Data This finds the most recent interval value for each interval from completed data sets only. If the most recent interval is in a No Data data set, that interval appears with "No Data" displayed in the Data Set Type column.

Fastpath:

Refer to Fixing Errors with Complete Data for more information about No Data interval data sets.

Once you have selected your criteria, use the search button to display the data. The interval data collection contains the following information:

The Interval Register Date/Time and Interval Register Data value for each interval is displayed. Information about the data set to which this interval is linked is displayed, including the Data Set Type, Set Date/Time and Register Data Set ID.

If seasonal time shift records are linked to both the base time zone and the interval register type, the Seasonal Time Shift associated with your interval register type is displayed.

If seasonal time shift records are linked to both the base time zone and the interval register type, the Seasonal Time Shift Remark indicates whether the data is displayed and should be entered in legal time or standard time. Refer to Interval Time Display for more information. If the data is displayed in legal time use the Show in Standard button to toggle to standard time. If the data is displayed in standard time use the Show in Legal button to toggle to legal time. If either the interval register type or the base time zone do not indicate a seasonal time shift record, the toggle button is not visible and data is displayed and expected in standard time.

Upload Interval Register Data

The following diagram illustrates the processes involved in the uploading of interval register data into the system.

The topics in this section describe how these processes work.

Contents

Process X - Populate Interval Register Data

Register Data Set

Register Data

Register Data Set Key

Process X - Populate Interval Register Data

Process X refers to the mechanism used by your organization to populate the Interval Register Data tables. Process X has the following responsibilities:

- It attempts to determine the appropriate Register to which this data belongs using the channel ID. If a register with this channel ID is not found, the data set is created without being linked to a register and the channel ID is stored as the external ID on the data set.

- It creates a new Register Data Set with the current date and time.

- If the interval data is from a different time zone or is not in standard time for the base time zone, the time of each interval must be converted to standard time in the base time zone. Refer to Time Zone and Time Changes for more information.

- All quantities being uploaded for the same register should be inserted into the interval register data table and should reference the same register data set.

- Set the status of the new data set:

- If the data set is not linked to a register, set the status to pending.

- If the register type has a validation algorithm, set the status to pending.

- If the register type does not have a validation algorithm, this data should be clean. Set the status to complete.

- Inserts a record in the register data set key table.

The topics in this section describe the tables to populate.

Register Data Set

You must create a data set for each batch of records being uploaded in the system for the same register. The name of this table is CI_REG_DATA_SET . The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

REG_DATA_SET_ID

12

Y

A/N

This is a unique key. This key is referenced on the register data record.

It's suggested that this key is built as follows:

- • The first five digits are the first five digits of the REG_ID.

- • The last seven digits are randomly generated.
This facilitates set based processing of the data. If your process that inserts records on this table is capable of calling a COBOL routine, call CIPZKEYG passing the first five digits and it supplies a seven-digit random number.

REG_ID

10

N

A/N

This is a foreign key reference to the interval register to which this set is linked. It is required if an external ID is not specified.

REG_DS_EXT_ID

60

N

A/N

This is the external identifier of the register to which this data belongs. It should correspond to the channel ID of its register. It is required if register ID is not specified.

SET_DTTM

26

Y

DateTime

This is the date/time that the data set was received. This must be populated with the current date/time. This is considered a server date and follows the seasonal time shifting as defined on the base time zone. Refer to Seasonal Time Shifts for more information.

Refer to Algorithms Find the Most Up-To-Date Data for information about why this date/time is important.

REG_DS_STATUS_FLG

2

Y

A/N

Set this value based on whether it will be validated in the system.

Set to P for Pending if the register ID is blank or if the register's register type indicates a validation algorithm.

Set to C for Complete if the data will not go through any further validation.

Refer to Life Cycle of Interval Register Data for more information

Register Data

Each piece of interval data for the register will be stored as an Interval Register Data record linked to the newly created data set. The name of this table is CI_REG_DATA . The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

REG_DATA_SET_ID

12

Y

A/N

This is a foreign key reference to the Register Data Set that groups the interval values together. This should be your newly created ID from above.

REG_DATA_DTTM

26

Y

DateTime

This is the date and time of the register data. This must be stored in standard time for the base time zone. Refer to Time Zone and Time Changes for more information.

INTV_REG_DATA

18.7

Y

N

This is the quantity for the interval.

Register Data Set Key

When a system-generated key value is assigned to a record, you need to also store the key value in a key table that corresponds to the record's database table. The name of this table is CI_REG_DATA_SET_K . The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

REG_DATA_SET_ID

12

Y

A/N

This should be your newly created Register Data Set ID from above.

ENV_ID

6

Y

N

This is the environment id defined on the installation options.

Process IREGIDB - Determine Register For Register Datasets

This process finds pending register datasets that are not linked to a register and attempts to determine the appropriate register by making a match on the external ID of the data set to the channel ID for the register.

Note:

. The status of the register dataset is set to Pending or Complete by the system, based on whether or not validation algorithms exist for the register type. Refer to Life Cycle of Interval Register Data Sets for more information.

Interval Register Data Exception

If a validation algorithm finds an error with interval register data, a record is written to the interval register data exception table with a message indicating the nature of the severe error.

To view the messages associated with the exception records, you must schedule an appropriate To Do entry creation background process. This process generates a To Do entry for every record in the interval register data exception table.

The following section describes steps to take to correct the data in error.

How To Correct a Register Data Set in Error

The validation algorithms are validating data in existing data sets. The following describes the steps involved with fixing an error found by the validation algorithm ( IRGVDS-SMP) supplied with the system.

- Review the To Do entries generated as a result of interval register data exceptions.

- The information displayed with the To Do entry provides details of the error. You may also drill down to the Data Set page to view the error.

- Fix the error and change the status of the data set to Pending . The next time the validation algorithm runs, it revalidates this data.

TOU Map Maintenance

The following section describes the pages related to maintaining a TOU map.

Contents

TOU Map - Main

TOU Map - Related SAs

TOU Map - Main

The TOU Map page is used to create and maintain Time of Use Maps. Open this page using Main Menu, Interval Billing, TOU Map.

Note:

This page is only available if the Complex Billing module is not turned off.

Description of Page

The TOU Map Info contains important information about the TOU map. These values only appear after the TOU map exists on the database. The TOU Map ID is a system-assigned random number.

Enter the Description of the TOU Map.

Indicate the TOU Map Type that defines this TOU map.

The External ID is available for cross-referencing this TOU map with an external source.

If this map is SA Owned , the SA ID linked to this map is displayed along with information about the SA.

Use the Generate button to generate data for this TOU map based on a TOU map template. Refer to TOU Map - Generate for more information.

The tree at the bottom of this page shows information about data sets linked to the TOU map.

- The Error Data Sets node displays if any of the data sets linked to the TOU map are in Error . Expanding this node displays each error data set.

- The Data Created Through node displays the date of the latest complete interval as of the current date. Expanding this node displays the last 10 Complete data sets.

TOU Map - Generate

The TOU Map Template dialog opens when you click Generate on the TOU map page:

Description of Page

Indicate the TOU Map Template that you want the system to use as your template for the new data.

The Set Date/Time is used for the set date/time on the newly created data set.

Indicate the Data Set Type,if applicable.

Indicate the first TOU interval to create by entering the Start Date/Time to use for creating the TOU data. Enter either the End Date/Time or a value in Recurring Patterns to indicate how much data the system should generate.

The holiday fields indicate if and how the system should handle holidays differently from standard days.

Holiday Template This is the daily template to use for all holiday days in the period, instead of the TOU map template entered above. Notice that a single daily Holiday template is used for the period you're generating data for. In other words, the system assumes all holiday days to have the same TOU pattern, i.e. template, throughout the period. If you need to use different TOU patterns for different holiday days you would need to generate data in several steps.

Holiday Shift in Minutes If the time period covered by a holiday is not 12AM to 12AM, indicate the number of minutes, positive or negative, to shift the holiday. For example, if the holiday is considered 7pm on the eve of the holiday until 7pm on the day of the holiday, enter -300 (i.e. 5 hours) for the shift in minutes.

Calendar This is the Calendar where the holidays applicable for this time period are defined.

When you click the Generate button, the system creates a new TOU map data set for this TOU map based on the information provided.

The Seasonal Time Shift associated with the TOU map type is displayed.

In the Seasonal Time Shift Remark, you are reminded that the system expects that the values you enter for the date and time are in local legal time as defined by your TOU map type.

Note:

The times on the TOU map components are in legal time. During this generation process the system converts the time definitions into standard time, taking daylight savings into account. Time shifting is based upon the Seasonal Time Shift defined on the template's TOU map type. Refer to Time Zone and Time Changes for more information.

TOU Map - Related SAs

Open Main Menu, Interval Billing, TOU Map and navigate to the Related SAs tab to view service agreements that reference the TOU map.

Note:

This page is only available if the Complex Billing module is not turned off.

Description of Page

The TOU Map Info contains important information about the TOU map. These values only appear after the TOU map exists on the database. The TOU Map ID is a system-assigned random number.

Note:

If the map is linked to more than 25 service agreements, the search criteria are intentionally left blank in order to avoid retrieving all service agreements (with the resultant slow response times). You must therefore use the SA Filter to define the type of service agreements that should be retrieved. See below for more information about this page's search criteria.

Use the SA Filter to define the service agreements to appear in the grid. The following options are available:

- Account. Use this option to restrict service agreements to those linked to a given Account ID.

- Address. Use this option to restrict service agreements to those linked to service points associated with a given Address, City and/or Postal code. You can specify any combination of these fields.

- All. Use this option if you do not want to filter service agreements.

- Person Name. Use this option to restrict service agreements to those linked to accounts that indicate the given Name as the main person.

- SA Type. Use this option to restrict service agreements to those linked to a given CIS Division and SA Type.

Don't forget to click the search button after changing the SA Filter.

The grid that follows contains the Accountsand Service Agreements that match your search criteria.

Maintaining TOU Map Data

In this section, we describe information related to maintaining time of use data. This information includes where to maintain the data, the life cycle that this data may go through, uploading data from an external source, and handling exception conditions.

Contents

Life Cycle of TOU Data Sets

TOU Data Maintenance

TOU Data Query

Upload TOU Map Data

TOU Data Exception

Life Cycle of TOU Data Sets

The following diagram shows the possible lifecycle of a TOU data set.

Error A creation algorithm may set this status for a data set if it detects an error condition. Data sets in this status are also written to the TOU Data Exception table. Refer to How To Correct a TOU Data Set in Error.

Canceled A user can cancel an Error data set if the data set should not be used for further processing. Refer to TOU Data Maintenance for more information. Additionally, algorithms may be designed to cancel data sets in certain situations.

Complete Only complete data sets are used by rate application and derivation algorithms. Data creation algorithms may create a data set in Complete status or change the status of a data set to Complete if no error conditions are detected. Data sets created online are set to Complete .

A user can only change the status of a data set to Canceled . All other state transitions are done by an algorithm. For more information about data creation algorithms, refer to Setting Up TOU Map Types.

Note:

Creation algorithms may be written to automatically delete any Error data sets and start over in an attempt to produce a Complete data set. This is similar to the billing process, which deletes error bill segments and tries from the beginning to produce an error free segment. Another alternative is to Cancel any data sets in Error rather than deleting them.

TOU Data Maintenance

The TOU Data page is used to create and maintain collections of time period definitions, grouped together by a data set, for a given TOU Map. Open Main Menu, Interval Billing, TOU Data to maintain TOU data.

Note:

This page is only available if the Complex Billing module is not turned off.

Description of Page

TOU Data Set is a concatenation of important information about the data set. The TOU Data Set ID is a system-assigned random number.

Indicate the TOU Map ID to which this data set is linked.

The Owner SA indicates the SA that "owns" this data. This information is only populated for SA owned TOU maps. This field is useful if the data set you are viewing contains an error and the error is related to a different source data linked to the service agreement. You may use the context button to quickly navigate to the service agreement to view other interval entities related to the service agreement. Refer to how to correct a TOU data set in error for more information.

The Set Date/Time of the TOU Data Set represent when this collection of data was entered or received. This is considered a server date and follows the seasonal time shifting as defined on the base time zone. Refer to Seasonal Time Shifts for more information.

Fastpath:

Refer to Algorithms Find the Most Up-To-Date Data for more information about the Set Date/Time and its use in algorithms.

The Data Set Type is available for classification of the data set in some way. The value currently available with the system is No Data . Refer to Fixing Errors with Complete Data for more information about using this data set type.

Note:

The values for Data Set Type are customizable using the lookup table. This field name is TOU_DS_TYPE_FLG.

The Status indicates the status of the TOU data set. Click Cancel DS to cancel an Error data set.

Fastpath:

Refer to Lifecycle of TOU Data for more information about interval data set status.

Use the Revert button to reverse the effect of a Complete data set.

Fastpath:

Refer to Fixing Errors with Complete Data for more information.

Use the Start Date/Time to indicate the starting point for the display of the interval data.

At least one TOU data record must exist in the collection of TOU time period definitions. For each TOU data record, the TOU Data Date/Time and the Time of Use code are captured. This date is considered a logical date and follows the seasonal time shifting as defined on the TOU map type. Refer to Seasonal Time Shifts for more information.

If the data set is in Error status, a Message that provides the error information is displayed below the TOU data collection.

If seasonal time shift records are linked to both the base time zone and the TOU map type, the Seasonal Time Shift associated with your TOU map type is displayed. Refer to Setting Up TOU Map Types for more information.

If seasonal time shift records are linked to both the base time zone and the TOU map type, the Seasonal Time Shift Remark indicates whether the data is displayed and should be entered in legal time or standard time. Refer to Interval Time Display for more information. If the data is displayed in legal time use the Show in Standard button to toggle to standard time. If the data is displayed in standard time use the Show in Legal button to toggle to legal time. If either the TOU map type or the base time zone do not indicate a seasonal time shift record, the toggle button is not visible and data is displayed and expected in standard time.

TOU Data Query

This query shows the most recent interval data for a TOU Map and a time period as of a given time.

Open Main Menu, Interval Billing, TOU Data Query to display TOU map data.

Note:

This page is only available if the Complex Billing module is not turned off.

Description of Page

The TOU Map ID is the identifier of the TOU map whose data should be displayed.

Use the Start Date/Time and End Date/Time if you want to limit the query to a specific time period.

Use the Set Date/Time to indicate the "as of what date" to use for retrieving interval data. Only data sets with a set date/time prior to this date/time will be accessed.

The Selection Type is used to determine what data to show:

History This option displays all TOU map data for the TOU map and time period, if specified. It includes data in data sets of any status value.

Most Recent Comp. Exc. No Data This option finds the most recent interval value for each interval from completed data sets only. If the most recent interval is in a No Data data set, that interval does not appear.

Most Recent Complete Data This finds the most recent interval value for each interval from completed data sets only. If the most recent interval is in a No Data data set, that interval appears with "No Data" displayed in the Data Set Type column.

Fastpath:

Refer to Fixing Errors with Complete Data for more information about No Data data sets.

Once you have selected your criteria, use the search button to display the data. The TOU map data collection contains the following information:

The TOU Data Date/Time and Time of Use code for each interval is displayed. Information about the data set to which this interval is linked is displayed, including the Data Set Type, Set Date/Time and TOU Data Set ID.

If seasonal time shift records are linked to both the base time zone and the TOU map type, the Seasonal Time Shift associated with your TOU map type is displayed.

If seasonal time shift records are linked to both the base time zone and the TOU map type, the Seasonal Time Shift Remark indicates whether the data is displayed and should be entered in legal time or standard time. Refer to Interval Time Display for more information. If the data is displayed in legal time use the Show in Standard button to toggle to standard time. If the data is displayed in standard time use the Show in Legal button to toggle to legal time. If either the TOU map type or the base time zone do not indicate a seasonal time shift record, the toggle button is not visible and data is displayed and expected in standard time.

Upload TOU Map Data

The following diagram illustrates the processes involved in the uploading of TOU map data into the system.

The topics in this section describe how these processes work.

Contents

Process X - Populate TOU Map Data

TOU Data Set

TOU Data

TOU Data Set Key

Process X - Populate TOU Map Data

Process X refers to the mechanism used by your organization to populate the TOU Map Data tables. Process X has the following responsibilities:

- It determines the appropriate TOU map to which this data belongs. (Recall that the TOU map can hold an external ID.)

- It creates a new TOU data set with the current date and time.

- If the TOU map data is from a different time zone or is not in standard time for the base time zone, the time of each interval is converted to standard time in the base time zone. Refer to Time Zone and Time Changes for more information.

- All quantities being uploaded for the same TOU map should be inserted into the TOU map data table and should reference the same TOU map data set.

- Inserts a record in the TOU data set key table.

The topics in this section describe the tables to populate.

TOU Data Set

You must create a data set for each batch of records being uploaded in the system for the same TOU Map. The name of this table is CI_TOU_DATA_SET . The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

TOU_DATA_SET_ID

12

Y

A/N

This is a unique key. This key is referenced on the TOU Data record.

It's suggested that this key is built as follows:

- • The first five digits are the first five digits of the TOU MAP_ID.

- • The last seven digits are randomly generated.
This facilitates set based processing of the data. If your process that inserts records on this table is capable of calling a COBOL routine, call CIPZKEYG passing the first five digits and it supplies a seven-digit random number.

TOU_MAP_ID

12

Y

A/N

This is a foreign key reference to the TOU map to which this set is linked.

Refer to TOU Map Maintenance for more information.

SET_DTTM

26

Y

DateTime

This is the date/time that the data set was received. This must be populated with the current date/time. This is considered a server date and follows the seasonal time shifting as defined on the base time zone. Refer to Seasonal Time Shifts for more information.

Refer to Algorithms Find the Most Up-To-Date Data for information about why this date/time is important.

TOU Data

Each time period definition for the TOU map will be stored as a TOU Data record linked to the newly created data set. The name of this table is CI_TOU_DATA . The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

TOU_DATA_SET_ID

12

Y

A/N

This is a foreign key reference to the TOU Data Set that groups the TOU definitions together. This should be your newly created ID from above.

TOU_DATA_DTTM

26

Y

DateTime

This is the date and time of the time period definition. This must be stored relative to the base time zone. Refer to Time Zone and Time Changes for more information.

TOU_CD

8

Y

A/N

This is the TOU code that this time period shall be mapped to.

TOU Data Set Key

When a system-generated key value is assigned to a record, you need to also store the key value in a key table that corresponds to the record's database table. The name of this table is CI_TOU_DATA_SET_K . The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

TOU_DATA_SET_ID

12

Y

A/N

This should be your newly created TOU Data Set ID from above.

ENV_ID

6

Y

N

This is the environment id defined on the installation options.

TOU Data Exception

If a derivation algorithm finds an error while creating TOU data, a record is written to the TOU data exception table with a message indicating the nature of the severe error.

To view the messages associated with the exception records, you must schedule an appropriate To Do entry creation background process. This process generates a To Do entry for every record in the TOU data exception table.

The following section describes steps to take to correct the data in error.

How To Correct a TOU Data Set in Error

Because derivation algorithms are creating new data sets, the error is not with the data set being created, but with source data that the algorithm is using to create the new data set.

The following describes the steps involved with fixing an error found by a creation algorithm ( ITMCCOPT) supplied with the system. This algorithm attempts to create TOU map data based on a TOU map template and contract option event information.

- Review the To Do entries generated as a result of TOU data exceptions.

- The information displayed with the To Do entry provides details of the error. Drill down to view more details on the TOU Data page.

On the TOU data page, the status is Error and the error message is displayed at the bottom. In this scenario, the time period covered by the contract event does not overlap with the time period covered by the override TOU map template. This is a shared contract option, but this particular event does not apply to this service agreement. The suggested solution for this case is to cancel the TOU data set in error and to create an override event for the service agreement.

- Cancel the TOU data set record in error.

- Use the context menu button adjacent to the owner SA to Go To Service Agreement. You are taken to the interval info tab on the service agreement page.

- Navigate to the Service Agreement - Contract Option page and add an override for this event.

The next time the creation algorithm runs, it detects the override event and it does not attempt to create TOU data for this scenario.

Contract Option Maintenance

Contract options are used to define special rate options applicable to a customer or a group of customers.

Contents

Contract Option - Main

Contract Option - Related SAs

Contract Option - Main

Open Main Menu, Customer Information, Contract Option to maintain contract options data.

Note:

This page is only available if the Complex Billing module is not turned off.

Description of Page

The Contract Option Info displays important information about the contract option. The Contract Option ID is a system-assigned random number.

Indicate the Contract Option Type for this contract option along with a Description.

If this contract option is linked to only one service agreement, indicate the Create For SA ID.

The characteristic collection is used to indicate additional information related to your contract option.

Note:

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

To modify a characteristic, move to a field and change its value. To add a new characteristic, click + to insert a row then fill in the information for each field. The following fields display:

Effective Date Define the date on which the characteristic becomes effective.

Characteristic Type Indicate the type of characteristic.

Characteristic Value Indicate the value of the characteristic.

Contract Option - Related SAs

Open Main Menu, Customer Information, Contract Option and navigate to the Related SAs tab to view service agreements that reference the contract option.

Note:

This page is only available if the Complex Billing module is not turned off.

Description of Page

The Contract Option Info displays important information about the contract option. The Contract Option ID is a system-assigned random number.

Note:

If the contract option is linked to more than 25 service agreements, the search criteria are intentionally left blank in order to avoid retrieving all service agreements (with the resultant slow response times). You must therefore use the SA Filter to define the type of service agreements that should be retrieved. See below for more information about this page's search criteria.

Use the SA Filter to define the service agreements to appear in the grid. The following options are available:

- Account. Use this option to restrict service agreements to those linked to a given Account ID.

- Address. Use this option to restrict service agreements to those linked to service points associated with a given Address, City and/or Postal code. You can specify any combination of these fields.

- All. Use this option if you do not want to filter service agreements.

- Person Name. Use this option to restrict service agreements to those linked to accounts that indicate the given Name as the main person.

- SA Type. Use this option to restrict service agreements to those linked to a given CIS Division and SA Type.

Don't forget to click the search button after changing the SA Filter.

The grid that follows contains the Accountsand Service Agreements that match your search criteria.

Maintaining Contract Option Events

In this section, we describe information related to maintaining contract option events. This information includes where to maintain the data, the life cycle that this data may go through, and handling exception conditions.

Contents

Life Cycle of Contract Option Events

Contract Option Event Maintenance

Contract Option Event Exception

Life Cycle of Contract Option Events

The following diagram shows the possible lifecycle of a contract option event.

Pending A contract option event may be created in pending status and transition to frozen to be used by processing algorithms. Events in this status may be deleted if they are incorrect.

Error A pending or frozen validation algorithm defined on the contract option type may set this status for an event if it detects an error condition. Events in this status also appear on the Contract Option Event Exception query.

Frozen Only frozen events are processed by rate algorithms and data derivation algorithms.

Canceled A frozen event may be canceled if it is incorrect.

Note:

Algorithms that process these events need to undo the effect of canceled events.

Contract Option Event Maintenance

Contract option events record the event of a contract option, including its effective period and any characteristic values related to the event. Open Main Menu, Interval Billing, Contract Option Event to maintain event data.

Note:

This page is only available if the Complex Billing module is not turned off.

Description of Page

The Contract Option Event ID is a system-assigned random number.

Indicate the Contract Option ID to which this event is linked.

Indicate the Contract Option Event Type for this event.

The Start Date/Time and End Date/Time of the contract option event represent when this event is effective. These are considered logical date/times and follow the seasonal time shifting as defined on the contract option type. Refer to Seasonal Time Shifts for more information.

The Status indicates the status of the contract option event. Use the Freeze button to change the status of the record from Pending to Frozen . Use the Cancel button to change the status of the record from Frozen to Canceled .

Note:

Any change in status causes the appropriate validation algorithm on the contract option event type, if any, to be executed.

When the pending or frozen validation algorithms find an error, the status of the record is changed to Error and an exception record is created. If the cancel validation algorithm finds an error, the error message is displayed to the user. No exception record is created.

Fastpath:

Refer to Lifecycle of Contract Option Events for more information.

The Status Date/Time indicates when the record's status changed to its current value. Algorithms that process these events use this information to determine whether the status change affects their processing. For example, if the status is Canceled and the status date/time is more recent than the last time the algorithm processed the events, the algorithm may need to reverse the effect of this event. This date/time is considered a server date and follows the seasonal time shifting as defined on the base time zone. Refer to Seasonal Time Shifts for more information.

The characteristic collection is used to indicate additional information related to your contract option event.

Note:

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

To modify a characteristic, move to a field and change its value. To add a new characteristic, click + to insert a row then fill in the information for each field. The following fields display:

Characteristic Type Indicate the type of characteristic.

Characteristic Value Indicate the value of the characteristic.

Contract Option Event Exception

If a validation algorithm finds an error in contract option event data, a record is written to the contract option event exception table with a message indicating the nature of the severe error.

To view the messages associated with the exception records, you must schedule an appropriate To Do entry creation background process. This process generates a To Do entry for every record in the contract option event exception table.

The following section describes steps to take to correct the data in error.

How To Correct a Contract Option Event in Error

Errors in contract option events are a result of errors detected in a validation algorithm. The validation algorithms provided by the system check for overlap of other events for contract options with the same contract option type.

- Review the To Do entries generated as a result of contract option event exceptions.

- The information displayed with the To Do entry provides details of the error. Drill down to view more details on the Contract Option Event page.

- Fix the error by resolving the overlap and change the status of the data set to Pending . The next time the validation algorithm runs, it revalidates this data.

Interval Billing Calculation Details

When a bill is produced with calculation lines resulting from interval pricing rate components or TOU Pricing rate components, it's likely that a CSR may want to view the calculation detail to verify that this was done correctly.

Fastpath:

In order to view the details of the calculation of a bill, the interval pricing rate component and TOU pricing rate components must indicate an audit algorithm. Refer to Auditing Your Interval Pricing Bill Lines for more information.

Once you have a bill generated, go to Main Menu, Financial, Bill Segment and navigate to the Calc Lines tab. Locate the lines that were produced as a result of an interval pricing rate component. A drill down button appears in the first column.

When you click the drill down for a given line, you are taken to a page that shows details for the calculation of this line. If your bill line was calculated using an interval pricing rate component, you are taken to the interval pricing details page. If your bill line was calculated using a TOU pricing rate component, you are taken to the TOU pricing details page.

Contents

Interval Pricing Details - Main

Interval Pricing Details - Details

Interval Pricing Details - SA Information

TOU Pricing Calc Details - Main

TOU Pricing Calc Details - Details

TOU Pricing Calc Details - SA Information

Interval Pricing Details - Main

To navigate to this page, you must first go to Main Menu, Financial, Bill Segment and display a bill segment with interval data in its calculation lines. From the Calc Lines tab, you may choose to audit a bill line that is the result of an interval pricing rate component that has an audit algorithm. Choosing the drill down button for an interval pricing calculation line will bring you to the Interval Pricing - Calc Details - Main page.

Description of Page

Identifiers and descriptions are shown for the Account, SA and Premise linked to this bill segment.

The Bill Seg ID, Bill Seg Header and Calc Line identify the bill calculation line currently displayed. The Description on Bill displays the description of the bill line that is printed on the customer's bill.

The date and time covered by the Consumption Period are displayed.

Fastpath:

Refer to Bill Period and Seasonal Time Shifts for more information.

The Quantity Billed displays the quantity, followed by a description of the unit of measure, followed by a description of the SQI, if applicable.

The Total Amount of the bill line is displayed, followed by the date and time this line was Calculated On.

If you click Rate Info, a dialog opens displaying information about the rate. The information includes the rate schedule and version, the rate component sequence and description, the interval profile relationship type and bill factor information.

The Start Date/Time and End Date/Time indicate the range of the data that is currently displayed. To limit the amount of data displayed, enter a different start and end date and time and click Zoom. Use Refresh to display all the data linked to the bill segment calculation line.

The Interval Billing Graph displays three sets of data and uses color to distinguish between them. Red is used for the interval quantities. The Y-axis shows the range of values plotted under the column UOM. Blue is used for the prices that are coming from the interval billing factor values. The Y-axis shows the range of values plotted under the column Price. Green is used for the resulting calculation at each interval of quantity multiplied by price. The Y-axis shows the range of values plotted under the column Cost. For all three curves, the X-axis shows the date for each interval.

Controlling Which Graphs Are Displayed

All three sets of data are displayed initially, however, you may control which sets of data are displayed by clicking the UOM, Price or Cost buttons to the left of the interval graph. For example to view only the Price graph, click the UOM and Cost buttons.

To redisplay the UOM and Cost graphs, click the respective buttons again.

Drilling Down In the Graph

While the graph is displayed, you may click on a section of the graph to drill down into more detail. For example, clicking in the middle of the graph will drill down to a small number of days.

You can display hour-by-hour information by clicking further.

At this point, if you click on one of the bars, you will be taken to the appropriate interval data set page to view the interval data itself.

Interval Pricing Details - Details

To navigate to this page, you must first go to Main Menu, Financial, Bill Segment and display a bill segment with interval data in its calculation lines. From the Calc Lines tab, you may choose to audit a bill line that is the result of an interval pricing rate component that has an audit algorithm. Once on the Calc Details page, you may navigate to the Details tab.

Description of Page

The top section of this page is the same as the main page.

Use the Start Date/Time and End Date/Time to indicate a range of data to display.

The detailed grid displays the Date/Time for each interval and the Quantity, Price and resulting Amount. Use the context menu button at the right of the amount column to navigate to either the Interval Value page or the Interval Data page to view the source data.

Below the grid, the Total Billable SQ and the Total Amount for the bill segment calculation line are displayed.

The Seasonal Time Shift Remark indicates whether the data is displayed in legal time or standard time. If the seasonal time shift record on the interval profile type of the first profile matches the seasonal time shift record on the bill factor/characteristic for the price, the intervals are displayed in legal time, according to this seasonal time shift record. Otherwise, the data is displayed in standard time.

Fastpath:

Refer to Seasonal Time Shifts for more information.

Interval Pricing Details - SA Information

To navigate to this page, you must first go to Main Menu, Financial, Bill Segment and display a bill segment with interval data in its calculation lines. From the Calc Lines tab, you may choose to audit a bill line that is the result of an interval pricing rate component that has an audit algorithm. Once on the Calc Details page, you may navigate to the SA Information tab.

Description of Page

The top section of this page is the same as the main page.

The tree structure on this page shows the profiles found for this service agreement and interval profile relationship type for the time period.

TOU Pricing Calc Details - Main

To navigate to this page, you must first go to Main Menu, Financial, Bill Segment and display a bill segment with TOU pricing data in its calculation lines. From the Calc Lines tab, you may choose to audit a bill line that is the result of a TOU pricing rate component that has an audit algorithm. Choosing the drill down button for a TOU pricing calculation line takes you to the TOU Pricing Calc Details - Main page.

Description of Page

Refer to Interval Pricing Details - Main for information about the information displayed in the top portion of the page. The one difference with the information displayed on this page is that the Quantity Billed includes the description of the time-of-use code along with the UOM and SQI.

The TOU Consumption Graph displays in Red the interval quantities that were mapped to the time-of-use code represented by the line. The Y-axis shows the range of values plotted under the column UOM. The X-axis shows the date for each interval.

Fastpath:

Refer to Interval Pricing Details - Main for information about drilling down into the graph.

TOU Pricing Calc Details - Details

To navigate to this page, you must first go to Main Menu, Financial, Bill Segment and display a bill segment with TOU data in its calculation lines. From the Calc Lines tab, you may choose to audit a bill line that is the result of a TOU pricing rate component that has an audit algorithm. Once on the Calc Details page, you may navigate to the Details tab.

Description of Page

The top section of this page is the same as the main page.

Use the Start Date/Time and End Date/Time to indicate a range of data to display.

The detailed grid displays the Date/Time and the Quantity for each interval that was mapped to the time of use code associated with this bill line. Use the context menu button at the right of the amount column to navigate to either the Interval Data page or the TOU Data page to view the source data.

The Seasonal Time Shift Remark indicates whether the data is displayed in legal time or standard time. If the seasonal time shift record on the interval profile type of the first profile matches the seasonal time shift record on the TOU map type of the first TOU map for the period, the intervals are displayed in legal time, according to this seasonal time shift record. Otherwise, the data is displayed in standard time.

Fastpath:

Refer to Seasonal Time Shifts for more information.

TOU Pricing Calc Details - SA Information

To navigate to this page, you must first go to Main Menu, Financial, Bill Segment and display a bill segment with TOU data in its calculation lines. From the Calc Lines tab, you may choose to audit a bill line that is the result of a TOU pricing rate component that has an audit algorithm. Once on the Calc Details page, you may navigate to the SA Information tab.

Description of Page

The top section of this page is the same as the main page.

This page displays two tree structures. The first tree structure shows the interval profiles found for this SA and interval profile relationship type for this time period. The second tree structure is only visible if the rate component references a TOU map relationship type. It shows the TOU maps found for this SA and TOU map relationship type for this time period.

Interval Billing Examples

Contents

How to Link Common Profiles to a Service Agreement

How to Link SA Owned Profiles to a Service Agreement

Hedge Cover

Tunnel Option

Override Maps

How to Link Common Profiles to a Service Agreement

The system automatically links common profiles to your service agreement if you set up the appropriate start options for your service agreement type. You may also link common profiles to your service agreement manually:

- Create the profile (refer to Interval Profile Maintenance for more information).

- Go to the Service Agreement - Interval Info tab to link this profile to your service agreement.

- Choose the appropriate profile relationship type for this SA/Profile link. This profile relationship type may be the link to a rate component if this profile is getting billed.

- Indicate the Interval Profile ID that you want to link to the service agreement.

- Save your record.

How to Link SA Owned Profiles to a Service Agreement

Contents

For The SA That Is The Owner

For The SA That Is Not The Owner

For The SA That Is The Owner

If this service agreement is the owner SA, the system automatically creates SA owned profiles for your service agreement if you set up the appropriate start options for your service agreement type. You may also create SA owned profiles for your service agreement manually:

- Create the profile (refer to Interval Profile Maintenance for more information). Be sure to choose your Service Agreement ID when creating the profile.

Note:

If you are on the Service Agreement Interval Info page, you may navigate to Interval Profile page by choosing Go To Interval Profile +. This brings your service agreement ID to the interval profile page and populates the service agreement field.

- Go to the Service Agreement - Interval Info tab to link this profile to your service agreement.

- Choose the appropriate Profile Relationship Type for this SA/Profile link. This Profile Relationship Type may be the link to a Rate Component if this profile is getting billed.

- Indicate the Interval Profile ID that you want to link to the service agreement.

- Save your record.

For The SA That Is Not The Owner

This assumes that the profile already exists and is linked to the owner SA. If not, follow the steps above.

- Go to the Service Agreement - Interval Info tab to link this profile to your service agreement.

- Choose the appropriate Profile Relationship Type for this SA/Profile link. This Profile Relationship Type may be the link to a Rate Component if this profile is getting billed.

- Indicate the Interval Profile ID that you want to link to the service agreement.

- Save your record.

Hedge Cover

Assume your organization has some interval rates with the following conditions. The customer will pay for an agreed upon amount of usage at a fixed price. We will call this amount of usage the hedge cover. It is also known as a "reference curve". If actual usage falls above the hedge cover, the customer pays the difference at the market price. If the actual usage falls below the hedge cover, the customer receives a credit for the difference at the market price.

In this example, we assume that the actual usage, the hedge cover, the strike price and the market price are all interval curves with the same interval size.

Contents

Hedge Cover - Bill Factors

Hedge Cover - Profile Relationship Types

Hedge Cover - Profile Types

Hedge Cover - Rate Schedule and Rate Components

Hedge Cover - Common Profile

Hedge Cover - SA Type

Hedge Cover - Start Option

Hedge Cover - Service Agreements

Hedge Cover - Typical Business Flow

Hedge Cover - Bill Factors

Strike Price

Set up a bill factor for the Strike Price. On the bill factor indicate that it:

- Has a bill factor type of Interval .

- Uses an appropriate characteristic. For the purposes of this example, let's assume that the strike price does not vary by any characteristic and set the value to N/A .

- Has a value type of Unit Rate .

- Should generate an error if it finds no value.

Set up characteristics for the Strike Price bill factor. On the characteristic indicate:

- Minutes Per Interval of 30 minutes.

- External ID, if applicable, for use by an interface that populates the interval data.

Populate the interval value sets and interval values for the Strike Price bill factor. These values will probably be determined at the time the contract is negotiated. However, they will probably not be entered manually. Rather, your implementers provide an interface that populates this data from an external source. Refer to Upload Interval Values for information about how this interface should work.

Market Price

Set up a bill factor for the Market Price. On the bill factor indicate that it:

- Has a bill factor type of Interval .

- Uses an appropriate characteristic. For the purposes of this example, let's assume that the market price does not vary by any characteristic and set the value to N/A .

- Has a value type of Unit Rate .

- Should generate an error if it finds no value.

Set up characteristics for the Market Price bill factor. On the characteristic indicate:

- Minutes Per Interval of 30 minutes.

- External ID for use by the interface that populates the interval data.

Set up the interface that periodically populates the interval value sets and interval values for the Market Price bill factor. These values are received from an external source and are uploaded via an interface provided by the implementers. Refer to Upload Interval Values for information about how this interface should work.

Hedge Cover - Profile Relationship Types

Set up Profile Relationship Types for the following interval profile curves:

- Hedge Cover ( HEDGE )

- Measured usage ( MEASUSAGE )

- Difference between Measured and Hedge ( OVRUNDHDG )

Later we will populate the valid profile types for each relationship type.

Hedge Cover - Profile Types

Create Profile Types

Set up a Profile Type HEDGE30 for the Hedge Cover, with the following attributes:

- Subtype is Common

- Minutes Per Interval is 30 minutes

- Specify an appropriate UOM/SQI

Set up a Profile Type MEAS30 for the Measured Usage, with the following attributes:

- Subtype is SA Owned

- Minutes Per Interval is 30 minutes

- Specify an appropriate UOM/SQI

Set up a Profile Type OVRUND30 for the Difference between Measured and Hedge, with the following attributes:

- Subtype is SA Owned

- Minutes Per Interval is 30 minutes

- Specify an appropriate UOM/SQI

- Profile Algorithm Type is Creation with an appropriate creation algorithm. The algorithm type IPFCSACS (supplied with the product) adds or subtracts two curves. The new algorithm should set up the two source Relationship Type parameters as HEDGE and MEASUSAGE and should indicate " - " for the Add/Subtract parameter.

Update Profile Relationship Types

Now that you have created profile types, go back to each profile relationship type and link the appropriate profile type as valid.

Hedge Cover - Rate Schedule and Rate Components

Create a Rate Schedule for your rate.

For the rate components, let's assume the charges are as follows:

- A bill line with the charges for the hedge cover at the strike price

- A bill line showing the measured usage over the hedge cover at the market price

- A bill line showing the measured usage under the hedge cover at the market price

Note that this rate may contain other charges that are not illustrated here.

The above line items require algorithms to perform the interval pricing calculations. The product is shipped with the algorithm type RCIPRS, which applies an interval pricing curve to an interval profile curve assuming that the interval size is the same.

Seq #

RC Type

Description

Profile Relationship Type

Algorithm

Bill Factor

10

Interval Pricing

Hedge cover at the strike price

HEDGE

Algorithm to apply prices to an interval profile curve

Strike Price

20

Interval Pricing

Measured usage over hedge at market price

OVRUNDHDG

Algorithm that applies prices to positive values in an interval profile curve (data does not need to be continuous)

Market Price

30

Interval Pricing

Measured usage under hedge at market price

OVRUNDHDG

Algorithm that applies prices to negative values in an interval profile curve (data does not need to be continuous)

Market Price

Hedge Cover - Common Profile

Create the common profile that contains the hedge cover data. On the common profile, populate:

- Interval profile type of HEDGE30

- External ID, if applicable, for use by an interface that populates the interval data.

Populate the interval profile sets and interval profile data for the hedge cover. These values are probably determined at the time the contract is negotiated. However, they will probably not be entered manually. Rather, your implementers provide an interface that populates this data from an external source. Refer to Upload Interval Data for information about how this interface should work.

Hedge Cover - SA Type

Determine the SA Type that is used by customers who opt for the hedge cover rate. It may be necessary to set up a new SA type. The SA type chosen must include the following:

- The rate defined above must be linked to the SA type as one of the valid rates.

- The three profile relationship types defined above must be linked to the SA type as valid profile relationship types.

Hedge Cover - Start Option

Create a start option for your SA type. It should set up the hedge cover scenario for a CSR.

- Set the rate for this start option to the hedge cover rate

- Set the default interval profile information as shown in the table below

Profile Relationship Type

Profile Type

Profile

HEDGE

Link the profile created above for the hedge cover

OVRUNDHDG

OVRUND30

MEASUSAGE

MEAS30

Hedge Cover - Service Agreements

When starting service for a customer, choose the appropriate SA Type and start option. Upon creation of the SA, the following occurs:

- The appropriate rate is linked.

- The common profile created above is linked to the SA.

- Two new SA owned profiles are created for the SA using the profile types defined in the start option for measured usage and amount over /under the hedge.

Hedge Cover - Typical Business Flow

Once all the control table data is set and a customer's service agreement has been activated, here is what typically happens in the course of a month:

- Market prices are received periodically and interfaced into the system.

- The customer's measured data is received periodically and interfaced into the system.

- The data derivation background process runs periodically and creates new "over under hedge" data.

- When billing executes, it bills the hedge cover and "over under hedge" data according to the rate algorithms.

Tunnel Option

Let's build on the hedge example. For this example, rather than comparing the measured usage to a single reference curve, the usage will be compared to a range of values at each interval to see if it falls within the range or outside the range. This is sometimes known as a "tunnel" option or a hedge option with "flex" parameters.

Assume that the interval rate for this option has the following conditions.

- For each interval, if the measured usage falls WITHIN the tunnel, the measured amount will be priced at a fixed price.

- For each interval, if the measured usage falls BELOW the LOW tunnel value, the customer will pay the low tunnel value at the fixed price AND will receive a credit for the difference between the low value and the measured amount at a market price.

- For each interval, if the measured usage falls ABOVE the HIGH tunnel value, the customer will pay the high tunnel value at the fixed price AND will pay for the measured amount over the high tunnel value at a market price.

Before we start looking at the data setup, let's talk about how the "tunnel" will be defined. In most cases, each customer does NOT have their own high and low tunnel curves defined. Instead, customer has a "reference curve" (also called "hedge cover") and the high and low values are defined as standard values for your company. These are percentages.

In this example, we assume that the actual usage, the hedge cover, the strike price and the market price are all interval curves with the same interval size.

Contents

Tunnel Option - Bill Factors

Tunnel Option - Profile Relationship Types

Tunnel Option - Profile Types

Tunnel Option - Data Derivation Algorithm

Tunnel Option - Rate Schedule and Rate Components

Tunnel Option - Common Profile

Tunnel Option - SA Type

Tunnel Option - Start Option

Tunnel Option - Service Agreements

Tunnel Option - Typical Business Flow

Tunnel Option - Bill Factors

Prices

This example uses the same bill factors for prices as the simple Hedge Cover example. It has a Strike Price bill factor and a Market price bill factor. Refer to Hedge Cover - Bill Factors for more information.

Tunnel Percentages

We will also use bill factors to define the tunnel percentages. The easiest thing to do is create a separate bill factor for the High Tunnel Percentage and the Low Tunnel Percentage. These will be simple bill factors with a characteristic of N/A .

Tunnel Option - Profile Relationship Types

This scenario is similar to the simple Hedge Cover scenario. We still need Profile Relationship Types for the following interval profile curves:

- Hedge Cover ( HEDGE )

- Measured usage ( MEASUSAGE )

However, instead of a curve that contains the difference between Measured and Hedge, we need the following profile relationship types:

- Amount of Measured Usage that falls within the Tunnel ( INTUNNEL )

- Amount of Measured Usage that does not fall within the Tunnel ( OUTTUNNEL )

Later we will populate the valid profile types for each relationship type.

Tunnel Option - Profile Types

Create Profile Types

This example will use the HEDGE30 and MEAS30 Profile Types that were created for the simple Hedge Cover example.

Instead of the profile type for the Difference between Measured and Hedge, this example needs the following profile types.

Set up a Profile Type INTUN30 for the Amount of Measured Usage that Falls Within the Tunnel, with the following attributes:

- Subtype is SA Owned

- Minutes Per Interval is 30 minutes

- Specify an appropriate UOM/SQI

- Profile Algorithm Type is Creation with an appropriate creation algorithm. A new algorithm type will need to be created by the implementers. See Tunnel Option - Data Derivation Algorithm for information about this algorithm.

Set up a Profile Type OUTTUN30 for the Amount of Measured Usage that Falls Outside the Tunnel, with the following attributes:

- Subtype is SA Owned

- Minutes Per Interval is 30 minutes

- Specify an appropriate UOM/SQI

Note:

Although this is a derived curve, it does not have its own data derivation algorithm. Instead, the algorithm linked to the INTUN30 profile type populates this curve because the calculations for both derived curves can be done with one algorithm.

Update Profile Relationship Types

Now that you have created profile types, go back to each profile relationship type and link the appropriate profile type as valid.

Tunnel Option - Data Derivation Algorithm

It will perform the following functionality:

- It should define two parameters for the source curves, one for the profile relationship type representing the hedge cover (or "reference curve") and one for the profile relationship type representing the measured usage.

- It should define two parameters for the bill factors for the high and low tunnel percentages.

- It should define a parameter for the profile relationship type for the destination curve of the data that falls outside the tunnel.

- This algorithm retrieves the hedge cover data. For each interval, it calculates the tunnel by applying the high and low tunnel percentages to the hedge cover value for that interval. It then compares the measured data for that interval.

- If the measured data falls within the tunnel, it populates the "Within Tunnel" curve with the measured value. (The "within tunnel" curve is the one with a profile type that contains this algorithm.)

- If the measured data falls below the tunnel, it populates the "Within Tunnel" curve with the low tunnel value and populates the "Outside the Tunnel" curve (based on the parameter passed in to this algorithm) with the difference between the low tunnel value and the measured usage.

- If the measured data falls above the tunnel, it populates the "Within Tunnel" curve with the high tunnel value and populates the "Outside the Tunnel" curve with the difference between the measured usage and the high tunnel value.

Tunnel Option - Rate Schedule and Rate Components

Create a rate schedule for your rate.

For the rate components, let's assume the charges are as follows:

- A bill line with the charges for the "within the tunnel" data at the strike price

- A bill line with the charges for the "outside the tunnel" data at the market price

Note that this rate may contain other charges that are not illustrated here.

The above line items require algorithms to perform the interval pricing calculations. The product is shipped with the algorithm type RCIPRS, which applies an interval pricing curve to an interval profile curve, assuming that the interval size is the same.

Seq #

RC Type

Description

Profile Relationship Type

Algorithm

Bill Factor

10

Interval Pricing

Within Tunnel data at strike price

INTUNNEL

Algorithm to apply prices to an interval profile curve

Strike Price

20

Interval Pricing

Outside Tunnel data at market price

OUTTUNNEL

Algorithm that applies prices to an interval profile curve (data does not need to be continuous)

Market Price

Tunnel Option - Common Profile

Create the common profile that contains the hedge cover data. If applicable, the curve created in the Hedge Cover example may be reused. Otherwise, refer to Hedge Cover - Common Profile for information on how to create a common profile.

Tunnel Option - SA Type

Determine the SA type that is used by customers who opt for the tunnel rate. It is possible that the SA type used in the simple Hedge Cover example may be reused. Or it is possible that you want to set up a new SA type.

The SA type chosen must include the following:

- The rate defined above must be linked to the SA type as one of the valid rates.

- The four profile relationship types defined above must be linked to the SA type as valid profile relationship types. (If you reuse the same SA type from the Hedge Cover example, only the two new profile relationship types, INTUNNEL and OUTTUNNEL , need to be linked at this time.)

Tunnel Option - Start Option

Create a new start option for your SA type that sets up the tunnel option scenario for a CSR.

- Set the rate for this start option to the hedge cover with tunnel option rate.

- Set the default interval profile information as shown in the table below.

Profile Relationship Type

Profile Type

Profile

HEDGE

Link the profile created above for the hedge cover

MEASUSAGE

MEAS30

INTUNNEL

INTUN30

OUTTUNNEL

OUTTUN30

Tunnel Option - Service Agreements

When starting service for a customer, choose the appropriate SA type and start option. Upon creation of the SA, the following occurs:

- The appropriate rate is linked.

- The common profile created above is linked to the SA.

- Three new SA owned profiles are created for the SA using the profile types defined in the start option for measured usage, inside tunnel and outside tunnel.

Tunnel Option - Typical Business Flow

Once all the control table data is set and a customer's service agreement has been activated, here is what typically happens in the course of a month:

- Market prices are received periodically and interfaced into the system.

- The customer's measured data is received periodically and interfaced into the system.

- The data derivation background process runs periodically and creates new "within tunnel" and "outside tunnel" data.

- When billing executes, it bills the "within tunnel" data and "outside tunnel" data according to the rate algorithms.

Override Maps

Assume that you have contracts with customers where the standard TOU map is overridden on certain days, for example, for interruptions. The customer is informed of these interruptions ahead of time so that they can plan their usage accordingly. Let's assume that the price for usage during these interruption days is more than the standard TOU Price.

Let's assume that the contract identifies the following time period definitions

Time Period Name

TOU Code

Description

Price

On Peak, Summer

ONSUM

The TOU for the standard map for May through September, inclusive for the times 08:00 through 16:59

$0.0488

Off Peak, Summer

OFFSUM

The TOU for the standard map for May through September, inclusive for the times 00:00 through 07:59 and 17:00 through 23:59

$0.0391

On Peak, Winter

ONWIN

The TOU for the standard map for October through April, inclusive for the times 08:00 through 16:59

$0.0421

Off Peak, Winter

OFFWIN

The TOU for the standard map for October through April, inclusive for the times 00:00 through 07:59 and 17:00 through 23:59

$0.0347

Interruption, On Peak

ONOVR

The TOU for the interruption period. This is not season dependant and covers the times 07:00 through 17:59.

$0.0504

Interruption, Off Peak

OFFOVR

The TOU for the interruption period. This is not season dependant and covers the times 00:00 through 06:59 and 18:00 through 23:59.

$0.0418

As you can see, the contract is set up to designate that on these special interruption days, the definition of on peak changes to include two extra hours, and the price per TOU is higher than on the standard days.

Contents

Override Maps - TOU Codes and TOU Group

Override Maps - Rates and Bill Factors

Override Maps - Profile Relationship Type and Profile Type

Override Maps - Contract Option Types and Contract Option Event Types

Override Maps - Map Relationship Type and Map Type

Override Maps - TOU Map Templates

Override Maps - SA Characteristic

Override Maps - TOU Data Creation Algorithm

Override Maps - SA Type

Override Maps - Start Option

Override Maps - Service Agreements

Override Maps - TOU Map Data

Override Maps - Typical Business Flow

Override Maps - TOU Codes and TOU Group

You need to create TOU codes for all the TOUs defined above. Once these are defined, you need to set up a TOU group and link all the above TOUs to this group. For this example, let's call the TOU Group INTERRUPT .

Override Maps - Rates and Bill Factors

You need to set up your rate schedule and bill factors needed to handle the TOU pricing for all the TOUs in your TOU group, including the prices for the override TOUs. Refer to Designing Your Time Of Use Rate Components for more information.

Override Maps - Profile Relationship Type and Profile Type

You need to set up a profile relationship type and a profile type for your measured usage. Let's assume that we have the same control data as that which was used in the hedge cover example.

Override Maps - Contract Option Types and Contract Option Event Types

You need to define a contract option type and event types for the interruption periods.

Create a Contract Option Type for the interruptions. Call it INTERRUPT . This contract option type has no special characteristic values.

Create a Contract Option Event Type to define the possible type of interruption events. In this example, let's assume that there is only one type of interruption. Call the event type INTERRUPT . This contract option event type has no special characteristic values.

Override Maps - Map Relationship Type and Map Type

You need to define a map relationship type and map type for TOU map.

For this example, create a generic Map Relationship Type of MEASUSAGE .

Create a map type that is used for customers using the contract defined above with possible overrides. Call it INTRPT30 . Define the other attributes as follows:

- TOU Group is INTERRUPT

- Minutes Per Interval is 30 minutes

- Algorithm Type is Creation with an appropriate creation algorithm. A new algorithm type needs to be created by the implementers. Refer to Override Maps - TOU Data Creation Algorithm for information about this algorithm.

Once you have created the map type, go back to the map relationship type and update its valid map types list to include the new map type.

Override Maps - TOU Map Templates

Create a series of TOU map templates for the standard time periods and create a special TOU map template to use for the interruptions.

Override Maps - SA Characteristic

The TOU map creation algorithm needs to know the correct TOU map template to use to generate TOU data when the interruption occurs. Our algorithm assumes that the TOU map template is defined as a characteristic on the service agreement.

Create a foreign key reference for the TOU map template.

Create a new Char type with the following attributes:

- Type is FK Reference

- FK reference code is the one created above for TOU map template

- Char Entity is Service Agreement

Override Maps - TOU Data Creation Algorithm

The TOU map creation algorithm needs to know the correct TOU map template to use to generate TOU data when the interruption occurs. Our algorithm assumes that the TOU map template is defined as a characteristic on the service agreement.

This algorithm performs the following:

- It should define a parameter of Contract Option Type to indicate the type of contract options whose events should trigger an override interruption TOU map. It should also define a parameter of Char Type that indicates the characteristic type used for TOU map templates.

- It looks for frozen contract option events for the input Contract Option Type effective during the creation time period.

- It also looks for canceled contract option events and attempt to undo their effect.

- It finds a characteristic on the service agreement, whose type matches the input Char Type parameter. It verifies that this is a valid TOU map template.

- It generates a new data set for the TOU map for the time period defined by the contract option events using the TOU map template.

Override Maps - SA Type

Determine the SA type that is used by customers with this option. It may be necessary to set up a new SA type. The SA type chosen must include the following:

- The rate defined above must be linked to the SA type as one of the valid rates.

- The MEASUSAGE profile relationship type defined above must be linked to the SA type as a valid profile relationship type.

- The MEASUSAGE map relationship type defined above must be linked to the SA type as a valid map relationship type.

- The INTERRUPT contract option type defined above must be linked to the SA type as a valid contract option type.

Override Maps - Start Option

Create a start option for your SA type that sets up the override map scenario for a CSR.

- Set the rate for this start option to the appropriate rate.

- In the characteristics collection, indicate the Char Type you defined for TOU map templates and choose the interruptions TOU map template that you created.

- Set the default interval profile, map and contract option information as shown in the tables below:

Profile Relationship Type

Profile Type

Profile

MEASUSAGE

MEAS30

Map Relationship Type

TOU Map Type

TOU Map

MEASUSAGE

INTRPT30

Contract Option Type

Contract Option

INTERRUPT

Note:

In this option, there are no common profiles or maps.

Override Maps - Service Agreements

When starting service for a customer, choose the appropriate SA type and start option. Upon creation of the SA, the following occurs:

- The appropriate rate is linked.

- The TOU map template for interruptions is linked as a characteristic to the service agreement.

- A new SA Owned profile is created for the SA, using the profile type defined in the start option for measured usage.

- A new SA Owned TOU map is created for the SA, using the map type defined in the start option.

- A new SA specific contract option is created for the SA, using the contract option type defined in the start option for interruptions.

Override Maps - TOU Map Data

The standard TOU map data must be set up at the beginning of the contract period. A user should go to the TOU Map Maintenance page and use the Generate button to indicate the appropriate TOU map templates to use for the standard data.

Override Maps - Typical Business Flow

Once all the control table data is set and the customer's service agreement has been activated and the standard TOU map data for the customer has been generated, here is what typically happens in the course of a month:

- The customer's measured data is received periodically and interfaced into the system.

- If any special override days occur, a new contract option event is created for the contract option.

- The TOU map creation algorithm runs periodically and it generates new TOU data sets with the TOU Codes and time period definitions as defined above for the interruption days.

- When billing executes, the TOU Mapping, done during rate application, obtains the most up to date TOU map data for each interval. This way, if any special interruption data exists, the measured usage for that day is mapped correctly into the interruption TOUs. Otherwise, the data is mapped to the standard TOUs.

- The correct prices for each time of use period are applied.

Statements

In this section, we describe how to manage your customer's statements.

Contents

The Big Picture of Complex Statements

Statement Construct Maintenance

Statement Maintenance

The Big Picture of Complex Statements

Statements allow you to set up a person to receive a consolidated report of the financial activity for one or more accounts and/or service agreements. This allows you to model complex account scenarios, including the following examples.

- Satellite offices for a company are each responsible for paying their own bill, but the head office would like a consolidated report of the bills for all the satellite offices once a month. In this case, each satellite office is set up as an account covering the services for their office. The head office does not want to receive individual copies of each bill, but rather a consolidated report of the financial activity for all the offices.

- The head office is responsible for paying the bill. The satellite offices should receive a copy of only their portion of the bill. In this case, a service agreement is set up for each satellite office under the head office's account. Each satellite office should receive a copy of the bill segment information for their office's service agreement.

- The head office is responsible for paying the bill. Multiple departments need to see copies of the electric portion of the bill. As illustrated by this scenario, a service agreement or account may appear on many statements.

The topics in this section provide additional information about how to set up statements.

Contents

Constructing Statements

Producing Statements

Printing Statements

Constructing Statements

Statements are produced for a person. Each statement contains the financial transactions for one or more service agreements. The service agreements may belong to any number of accounts. Over time, a person may receive many statements.

When setting up a person to receive statements, it's important to note that a person can receive different statements for different groupings of service agreements. For example, the head office may want a statement of the financial details for the western division offices separately from the eastern division offices.

For each separate statement a person wishes to receive, you will set up a statement construct. On the statement construct, you define the service agreements and/or accounts whose financial information should appear on the statement. If you specify an account on a statement construct, billing information for all the service agreements linked to the account will be included on the statement. The superset of service agreements and accounts defined on a statement construct are called the "construct details".

Fastpath:

Refer to Statement Construct Maintenance for more information.

Producing Statements

Contents

Statement Cycles

Create Statements Background Process

Statement Routing

Where Are Statements Sent

On-line Statement Production

How to Regenerate a Specific Statement

Statement Cycles

The accounts and service agreements linked to a statement construct may have different bill cycles and as a result, their bills are produced on different dates. So when should a statement containing the consolidation of all this financial information be produced? To answer this question, there is a statement cycle.

Just as with a bill cycle, the statement cycle has a schedule. A statement cycle's schedule controls when a statement should be produced. Each statement construct will point to its own statement cycle.

Fastpath:

Refer to Statement Construct Maintenance and Statement Cycle for more information.

Create Statements Background Process

This statement construction background process (known by the batch control ID of STMPRD) is responsible for periodically creating statements. It works as follows:

- All statement cycles are selected with pending schedules whose production date is on or before the business date.

- For each such cycle, all of its statement constructs are selected. For each statement construct,

- If a statement already exists for the cycle schedule and construct, it is deleted (this allows for reproduction after a mess up). Note well, this is true even if the statement is printed as you may have only spotted the problem after viewing the printed statement.

- A statement is created.

- All SA's associated with the construct details effective on the business date are extracted.

- All "SA snapshots" associated with bills whose BILL DATE is within the construct detail's start and end dates that are not already linked to one of the construct's statements are linked to the new statement. Note, an "SA snapshot" is created for every service agreement linked to an account when a bill is completed for an account.

- If no "SA snapshots" are found, the statement is removed.

Note:

The following diagram illustrates how the above logic could result in multiple bills for a single service agreement being linked to the same statement.

Fastpath:

Refer to Statement Maintenance for more information about a statement and its details.

Note:

This process is rerunnable. If a problem occurred during the statement creation, simply run the background process again. It will clean up all existing statements for each construct in the current cycle schedule and start again.

Fastpath:

Refer to Printing Statements for more information for how a separate background process uses the information snapshot on a statement to construct the extract file used to print the statements.

Statement Routing

Just as with bills, statements require routing information in order for the system to understand how and where to send the statements. For example, the system needs to know the method of routing, the number of copies and the format of the statement. This information is captured on a statement construct.

Where Are Statements Sent

The system extracts a statement's address as per its statement construct's address source. Note, if the address source is Person and the person has a seasonal address effective on the business date, the seasonal address will be used.

If you need to reprint a statement because it was addressed incorrectly, correct the person's address, and then reprint the statement (by pressing the Reprint button on the statement). When you press this button, the statement will be marked for downloading. When your download process next runs, it simply extracts the statement construct's current address.

On-line Statement Production

Statements may be produced on-line as well as in batch. To produce a statement on-line, simply go to the Statement page, select the correct Construct ID and choose the Generate button.

This statement will include the financial information related to bills for the accounts and service agreements linked to this construct, with the following criteria:

- The bills do not already appear on a statement

- The bill dates fall within the "effective period" for the statement construct. In other words, the bill falls within the start and end period for the statement construct details.

Fastpath:

Refer to Statement Maintenance for more information.

How to Regenerate a Specific Statement

There may be times when a specific statement needs to be regenerated. For example, perhaps a cancel / rebill has occurred since the statement was produced, and you wish to recreate the statement to reflect this.

If you need to regenerate a statement using up-to-date information, simply delete the statement and generate a new statement. This may be done on-line.

Note:

Statements may be deleted, even if they have already been printed. This enables you to delete and regenerate statements.

Fastpath:

Refer to Statement Maintenance for more information.

Printing Statements

The contents of this section describe the technical implementation of printing statements.

Contents

Statement Route Types Control The Information Merged Onto Statements

Technical Implementation Of Online Statement Image

Technical Implementation Of Printing Statements In Batch

Reproducing The Statement Print Flat File

How To Reprint A Specific Statement

The Documaker1 Records

Statement Route Types Control The Information Merged Onto Statements

Every statement references a statement route type. The route type controls the following statement print functions:

- It contains an algorithm that is responsible for extracting the information merged onto your statements. Specifically, algorithms of this type create the "flat file records" that are passed to your statement print software. Algorithms of this type are called under the following scenarios:

- The background process that builds the flat file that's passed to your statement print software calls these algorithms to construct the "flat file records" for each statement.

- If your statement print software has the ability to construct a real-time image of a statement (in a PDF), you can plug-in an Online Statement Image algorithm on the Installation Record. This type of algorithm will call the statement's dispatch group extract algorithm to extract the information that is merged onto the statement. Refer to Technical Implementation Of Online Statement Image for the details.

- Refer to The Documaker Records for examples of the record layouts passed to the Documaker print software.

- It contains the ID of the background process that builds the flat file that's passed to your statement print software. The base package example of this process (known by the batch control ID of STMDWLD) simply calls each statement's construct's route type's extract algorithm to format the information placed onto the flat file.

Technical Implementation Of Online Statement Image

Users can view an image of any statement if you setup the following:

- Plug-in an Online Statement Image construction algorithm on the Installation Record. Refer to ONSD-ST for an example of such an algorithm. Note, if your statement print software is not capable of producing a PDF containing an image of a statement, users will not be able to view images of statements.

- Plug-in the appropriate extract algorithm on each statement route type. Algorithms of this type format the records that contain the information that is passed to your printing software. Refer to STEX-TX for an example of such an algorithm.

When you plug-in these algorithms, a button appears on Statement - Main. When a user presses this button, the following takes place:

- The installation record's Online Statement Image construction algorithm is executed.

- This algorithm calls the statement's route type's extract algorithm. This algorithm constructs the information that's merged onto the statement and returns it to the Online Statement Image algorithm. This algorithm, in turn, passes it to your statement print software.

- Your statement print software renders an image of the statement in a PDF and returns it to the Online Statement Image algorithm.

- And finally, the Online Statement Image algorithm displays the PDF in a separate Adobe session.

Technical Implementation Of Printing Statements In Batch

The batch process that extracts statement information (known by the batch control ID of STMDWLD) reads all statements in a given run number that are marked with its batch control ID. For each statement, it creates numerous records on a flat file. These records contain the information that is merged onto your statements.

The base package example of this process (known by the batch control ID of STMDWLD ) simply calls the extract algorithm on the statement route type to format the information placed onto the flat file. Refer to Statement Route Types Control The Information On Statements for more information.

Note:

If your software doesn't support online statement images. The algorithm that formats statement extract records that's plugged in on statement route type serves two purposes: 1) it formats the records used to construct online images of a statement, and 2) it formats the records downloaded to your statement print software in batch. If your statement print software does not support the rendering of statement images real time, there is no need to create an extract algorithm. Rather, you should simply develop your own download process that both formats the extract records and downloads them (and then specify this batch process on your statement route type).

Reproducing The Statement Print Flat File

You can reproduce the flat file at any time. Simply request the STMDWLD process and specify the run number associated with the historic run.

How To Reprint A Specific Statement

If you need to reprint a specific statement, navigate to Statement - Main and press the Reprint button.

If your implementation has enabled the online creation of statement images, you can also press the Display Statement button on this page and then print the resultant PDF on your local printer.

The Documaker Records

Numerous different types of records are interfaced to the Documaker software. However, they all share a common structure:

- The first 4 bytes are called the Printer Key. This field is a record type used by the Documaker statement template.

- The next 186 bytes are called the Sort Key. This field is used to ensure the various records used to construct a printed statement appear in the correct order in the interface file.

- The next 12 bytes are called the Mailing Key. This field is used to control the order in which the formatted statements are printed.

- The remaining bytes contain the Statement Information that appears on the printed statement. The type of information differs for each type of record.

The topics in this section describe each component.

Contents

Printer Keys (Record Types)

Sort Key

Mailing Key

Statement Information

Printer Keys (Record Types)

The following table defines each printer key (i.e., record type) on the statement print flat file.

Record Type

Description

Notes

0010

Global extract information

Required. 1 per flat file.

0100

Statement record

Required. 1 per statement.

0120

Total by currency record

Required. At least one per statement.

0500

Construct detail record

Required. At least one per construct detail linked to the statement construct.

0900

Service agreement record

1 per SA

1100

Bill record

1 per bill

1300

Financial Transaction (FT) record

1 per FT linked to the SA.

3600

End of record type 1100

1 for each bill

3700

End of record type 0900

1 for each SA

5000

End of record type 0500

1 for each statement construct detail

9999

End of record type 0100

1 for each Statement

Sort Key

The following table defines the structure of the sort key that appears on each statement print record. Please note that different components are filled in for each printer key.

Field Name

Format

Record Type

Source/Value/Description

Statement ID

A12

All

Prime key of the statement

Sequence Number

N2

All

Set to "1"

Copy Number

N2

All

Defaulted to "1" on the first copy, set to "1" when a statement is requested on-line

Statement record group

A2

0010

Blank

0100

10

0120

20

0500, 0900, 1100, 1300, 3600, 3700, 5000

30

9999

60

Construct detail sort sequence 1

N3

0010, 0100, 0120, 9999

blank

0500, 0900, 1100, 1300, 3600, 3700, 5000

Statement construct's PRT_SEQ

Construct detail sort sequence 2

A10

0010, 0100, 0120, 9999

blank

0500, 0900, 1100, 1300, 3600, 3700, 5000

Statement construct's STM_CNST_DTL_ID

Premise Indicator

A1

0010, 0100, 0120, 0500, 9999

Blank

5000

'Z'

0900, 1100, 1300, 3600, 3700

For a non-premise, this will be 'N' otherwise 'Y'

Premise State

A6

0010, 0100, 0120, 0500, 5000, 9999

Blank

0900, 1100, 1300, 3600, 3700

Premise's state (if this is for a non-premise, this will be blank)

Premise City

A90

0010, 0100, 0120, 0500, 5000, 9999

Blank

0900, 1100, 1300, 3600, 3700,

Premise's city (if this is for a non-premise, this will be blank)

Premise Address 1

A58

0010, 0100, 0120, 0500, 5000, 9999

Blank

0900, 1100, 1300, 3600, 3700

Premise's address line 1(if this is for a non-premise, this will be blank)

Premise Id

A10

0010, 0100, 0120, 0500, 5000, 9999

Blank

0900, 1100, 1300, 3600, 3700

Premise's ID (if this is for a non-premise, this will be blank)

SA Print Priority

A2

0010, 0100, 0120, 0500, 5000, 9999

Blank

0900, 1100, 1300, 3600, 3700

The SA's SA type's print priority

SA Id

A10

0010, 0100, 0120, 0500, 5000, 9999

Blank

0900, 1100, 1300, 3600, 3700

The SA's SA ID

SA record group

A2

0010, 0100, 0120, 0500, 5000, 9999

Blank

0900

10

1100, 1300, 3600

20

3700

30

Bill Date

A10

0010, 0100, 0120, 0500, 0900, 3700, 5000, 9999

Blank

1100, 1300, 3600

Bill's bill date in the format YYYYMMDD.

Bill Id

A12

0010, 0100, 0120, 0500, 0900, 3700, 5000, 9999

Blank

1100, 1300, 3600

Bill's bill id

Bill record group

A2

0010, 0100, 0120, 0500, 0900, 3700, 5000, 9999

Blank

1100

10

1300

20

3600

30

Arrears Date

A10

0010, 0100, 0120, 0500, 0900, 1100, 3600, 3700, 5000, 9999

Blank

1300

Financial transaction arrears date

FT Type

A2

0010, 0100, 0120, 0500, 0900, 1100, 3600, 3700, 5000, 9999

Blank

1300

Financial transaction type

Mailing Key

The following table defines the structure of the mailing key that appears on each statement print record.

Field Name

Format

Source/Value/Description

Postal code

A12

This is the postal code on address associated with the statement.

Statement Information

The topics in this section describe the information that appears on each on each statement print record.

Contents

Global Extract Information Record (0010)

Statement Record (0100)

Total By Currency Record (0120)

Statement Construct Detail Record (0500)

Service Agreement Record (0900)

Bill Record (1100)

Financial Transaction (FT) Record (1300)

End Bill Record (3600)

End Service Agreement Record (3700)

End Statement Construct Detail Record (5000)

End Statement Record (9999)

Address Sub-record

Global Extract Information Record (0010)

Field Name

Format

Source/Value/Description

BATCH_CD

A8

Batch Control Code of the extract process.

BATCH_NBR

N10

Batch Number of the extract process

BATCH_RERUN_NBR

N10

Batch Rerun number of the extract process.

STATEMENT_CNT

N10

Count of statements on this extract. Multiple copies of a statement are counted multiple as well.

EXTRACT_DTTM

A31

System time of extraction. Formatted according to user profile.

STMT_ID_START

A12

This is only used when a statement is produced as a result of an online request (from Statement - Main). It contains the Statement Id to extract.

STMT_ID_END

A12

This is only used when a statement is produced as a result of an online request (from Statement - Main). It contains the Statement Id to extract.

THREAD_NBR

N10

This field is only used if statements are extracted in batch. It contains the thread number in which the statement was extracted.

THREAD_CNT

N10

This field is only used if statements are extracted in batch. It contains the total number of threads that were extracted.

STATEMENT_IND

A1

Defaulted to "Y"

Statement Record (0100)

Field Name

Format

Source/Value/Description

STMT_ID

A12

CI_STM

PER_ID

A10

CI_STM_CNST

STMT_DT

A31

STM_DT from CI_STM. Formatted according to user profile.

COPY_NBR

N1

"1"

NBR_STMT_COPIES

N1

"1"

ENTITY_NAME

A64

Main name of CI_PER (from CI_PER_NAME).

ADDRESS_SBR

A361

Address where the statement should be sent (the address is defined on the statement's statement construct).

ENTITY_NAME1

A64

CI_PER

ENTITY_NAME2

A64

CI_PER

ENTITY_NAME3

A64

CI_PER

DESCR50

A50

CI_STM_CNST

Total By Currency Record (0120)

One total record will be created for each currency code associated with the FT's associated with the SA snapshots linked to the statement.

Field Name

Format

Source/Value/Description

CURRENCY_CD

A3

This is the currency code associated with the summary information.

CUR_BAL

A30

This is the sum of CUR_AMT snapshot on the SA snapshots (CI_BILL_SA) linked to the statement. SA snapshots (CI_BILL_SAs) are referenced on CI_STM_DTL.

BILL_AMT

A30

This is the sum of CUR_AMT from CI_FTs classified as "corrections" and "current charges" on bill's associated with the statement. Please note, only those FT's associated with SAs linked to the statement will be amalgamated. This is formatted according to user's display profile.

CUR_ADJ_AMT

A30

This is the sum of CUR_AMT from CI_FTs classified as "adjustments" on bills associated with the statement. Please note, only those FT's associated with SAs linked to the statement will be amalgamated. This is formatted according to user's display profile.

CUR_PAY_AMT

A30

This is the sum of CUR_AMT from CI_FTs classified as "payments" on bills associated with the statement. Please note, only those FT's associated with SAs linked to the statement will be amalgamated. This is formatted according to user's display profile.

Statement Construct Detail Record (0500)

Field Name

Format

Source/Value/Description

STM_CNST_ID

A12

CI_STM_DTL

SA / Account Indicator

A1

A switch to indicate if the statement construct is for a service agreement of an account. 'S' for service agreement, 'A' for account.

Unique ID

A10

The unique identifier of the account or service agreement

SA / Account Info

A160

Contains the standard information about the account or service agreement

STMT_PRT_DESCR

A50

CI_STM_CNST

Service Agreement Record (0900)

Field Name

Format

Source/Value/Description

SA_ID

A10

CI_SA

Address Information

A120

This is the standard format of a premise address that is displayed throughout the system.

SA Information

A120

This is the standard SA information that is displayed throughout the system

SVC_TYPE_CD

A2

CI_SA_TYPE

Bill Record (1100)

Field Name

Format

Source/Value/Description

BILL_ID

A12

Completion Date

A31

Date formatted according to user profile.

Due Date

A31

Date formatted according to user profile.

SA Ending Balance

A30

FT Exist Indicator

A1

Financial Transaction (FT) Record (1300)

Field Name

Format

Source/Value/Description

FT_ID

A12

CI_FT

ARS_DT

A31

CI_FT (The date when the transaction starts aging).

Date formatted according to user profile.

AMOUNT

A30

CUR_AMT from CI_FT formatted according to user display profile.

FT_DESCR

A120

Formatted FT information.

End Bill Record (3600)

Field Name

Format

Source/Value/Description

Dummy field

End Service Agreement Record (3700)

Field Name

Format

Source/Value/Description

Dummy field

End Statement Construct Detail Record (5000)

Field Name

Format

Source/Value/Description

Dummy field

End Statement Record (9999)

Field Name

Format

Source/Value/Description

Dummy field

Address Sub-record

The address sub-record that in statement record (0100) is composed of the following:

Field Name

Format

Description

COUNTRY

A3

ADDRESS1

A64

ADDRESS2

A64

ADDRESS3

A64

ADDRESS4

A64

CITY

A30

NUM1

A6

NUM2

A4

HOUSE_TYPE

A2

COUNTY

A30

STATE

A6

POSTAL

A12

GEO_CODE

A11

IN_CITY_LIMIT

A1

Statement Construct Maintenance

The statement construct enables you to indicate the collection of accounts and/or service agreements whose financial details should be consolidated for a statement to a given person. The statement construct also contains routing information needed by the system to send the statement to the person in the preferred manner.

Contents

Lifecycle of a Statement Construct

Statement Construct - Main

Statement Construct - Details

Lifecycle of a Statement Construct

The following diagram illustrates the lifecycle of a statement construct.

Active: The statement construct will be in this status while a person is actively receiving statements for the accounts and service agreements linked to this construct. A statement construct may transition from this status to inactive.

Inactive: The statement construct will be in this status when a person no longer wishes to receive statements for the accounts and service agreements linked to this construct. A statement construct may transition from this status back to active.

Statement Construct - Main

Open this page using Customer Information, Statement Construct.

Description of Page

Statement Construct is a concatenation of summary information about this record. It is composed of the name of the statement person, the print description and the status.

Statement Construct ID is the unique system-generated identifier for this statement construct.

Person ID is the person who receives the future statements.

Note:

A person may be linked to many statement construct records.

Status indicates whether or not this person is currently receiving statements. The values are Active and Inactive.

Fastpath:

Refer to Lifecycle of a Statement Construct for more information.

Address Source indicates where the source of the statement's address. The values are Person and Mailing Premise. If the value is person, the person's mailing address is used. If the value is mailing premise, indicate the Mailing Premise to use.

Statement Cycle controls when statements are produced for this statement construct. Refer to Statement Cycle for a description of how the production schedule is maintained.

Statement Route Type controls how the statement is routed to the Person (e.g., via email, postal service, EDI, etc.). Refer to Statement Route Type for more information on setting up statement route types.

Number of Copies indicates how many copies of the statement the person wishes to receive.

Statement Format indicates if the person receives a Detailed or a Summary statement.

Note:

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

Print Description is a brief description that can be printed on the statement.

The tree shows the statement construct's details. The nodes expand to show account, premise and service agreement information for the construct details.

Note:

Large statement constructs. The tree is hard to use if the statement construct has many details. In this situation, transfer to the adjacent tab page and use the filter to restrict the details that are shown.

Statement Construct - Details

This page is used to maintain the accounts and service agreements where financial transactions should appear on statements produced using this statement construct. Open this page using Customer Information, Statement Construct, Details.

Description of Page

Statement Construct is a concatenation of summary information about this record. It is composed of the name of the statement person, the print description and the status.

Statement Construct ID is the unique system-generated identifier for this statement construct.

If a statement construct has a large number of details, you can use the Details Filter to limit the details that appear in the grid. The following options are available:

- All. Use this option to view all details linked to the statement construct.

- Person Name. Use this option to restrict details linked to accounts whose main customer has a primary name that matches an input Name.

- SA's at an Address. Use this option to only show details linked to service agreements that are linked to service points associated with a given Address, City and/or Postal code. Note, you can specify any combination of these fields.

- Statement Print Description. Use this option to restrict details to those with a given Description.

Don't forget to click the search button after changing the filter.

The grid contains the Accounts and/or Service Agreements whose financial information contributes to this statement construct. Each record in the grid contains the following information:

- Construct Detail Type defines if the construct detail is for an entire Account or a single Service Agreement. This field is protected if a statement detail was produced using this construct.

- Service Agreement/Account identifies the account (for Account construct details) or the service agreement (for Service Agreement) construct details. This field is protected if a statement detail was produced using this construct.

- Statement Print Description is available for use by the extract program to include on the printed statements to help the recipient identify the details.

- Print Order control where the financial transactions associated with the account / service agreement appear on the printed statement.

- Start Date is the date that this account / service agreement's financial transactions should begin appearing on statements.

- End Date is the date that this account / service agreement's financial transactions should stop appearing on statements.

Note:

Only financial transactions linked to bills whose BILL DATE is within the construct detail's Start Date and End Dates will appear on statements.

- Construct Detail ID is a system generated unique identifier of the construct detail.

Statement Maintenance

Statements allow you to set up a Person to receive a consolidated report of the financial activity for one or more accounts and/or service agreements. The topics in this section describe how to maintain statements.

Note:

The system creates most statements behind-the-scenes. Most statements are created by the system when it processes the statement cycle schedule. You should only have to access the statement pages to regenerate a statement or to add a statement real-time. For information about how the system creates statements, refer to The Statement Creation Background Process.

Contents

Lifecycle of a Statement

Statement - Main

Statement - Details

Lifecycle of a Statement

The following diagram illustrates the lifecycle of a statement.

Pending: A statement is created in this state and will remain in this state until the statement details are extracted. When that occurs, it will transition to printed.

Printed: A statement transitions to this state after the details of a statement have been extracted.

Statement - Main

Open this page using Financial, Statement.

Note:

Correcting erroneous statements. It's important to be aware that there are very few fields that are directly modifiable by a user. This is because a statement is a summary of financial transactions. If you need to change information on a statement, you must change the source information (e.g., change the statement's construct or complete additional bills) and then regenerate the statement. Refer to How To Regenerate A Statement for more information.

Description of Page

Statement is a concatenation of summary information about this record. It is composed of the name of the statement person, the statement construct print description, the create date of the statement and the statement status.

Statement ID is the unique system-generated identifier for this statement.

Indicate the Construct ID for the statement construct whose construct details should be included in this statement.

Address is a display-only field that contains the address to which the statement will be sent.

The Statement Status indicates the current status of the statement. The values are Pending , Printed .

Fastpath:

Refer to Lifecycle of a Statement for more information.

The Create Date indicates the date that this statement was created.

The Batch Control and Batch Number are the batch process and run in which the statement was (or will be) sent to the recipient.

Fastpath:

Refer to Printing Statements and to Statement Route Type for more information.

The Statement Action area contains buttons that you use to generate, reprint or delete a statement.

- The Generate button enables you to create a statement on-line. Refer to On-line Statement Production for more information.

- The Reprint button will stamp the latest run number for the statement's batch control. This will enable the statement to be reprinted the next time the batch control process executes. Refer to How to Reprint A Specific Statement for more information.

- The Delete button will remove the statement and its details from the database. Refer to How to Regenerate a Specific Statement for more information.

- The Display button will display an online image of the statement when pressed. Refer to Online Statement Image for more information.

Note:

You can only use the Display 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. Refer to Technical Implementation Of Online Statement Image for more information.

The bottom portion of this page is dedicated to a tree that shows the statement details. The nodes expand to show every service agreement that will appear on the statement and the financial details that will be swept onto the statement for each service agreement. You may transfer to the details of any of the nodes by selecting that node. Context menus are also available for various nodes to facilitate easy navigation to other pages.

Note:

Large statements. The tree will be hard to use if the statement has many service agreements that contributed financial transactions to the statement. In this situation, transfer to the adjacent tab page and use the filter to restrict the service agreements that are shown.

Statement - Details

This page is used to view the service agreements that contributed financial transactions to the statement. Open this page using Financial, Statement and then navigate to the Details tab.

Description of Page

Statement is a concatenation of summary information about the statement. It is composed of the name of the statement person, the statement construct print description, the create date of the statement and the statement status.

Statement ID is this statement's unique system-generated identifier.

If a statement has a large number of service agreements that contributed financial transactions to the statement, you can use the SA Filter to limit the service agreements that appear in the grid. The following options are available:

- All. Use this option to view all service agreements that contributed financial transactions to the statement.

- Person Name. Use this option to only show service agreement linked to accounts whose main customer has a primary name that matches Person Name.

- SA's at an Address. Use this option to only show service agreements that are linked to service points associated with a given Address, City and/or Postal code. Note, you can specify any combination of these fields.

- Statement Print Description. Use this option to only show service agreements associated with a construct detail with a given Statement Print Description.

Don't forget to click the search button after changing the filter.

The grid contains service agreements that contributed financial transactions to the statement. If a service agreement's financial transactions appeared on multiple bills, a separate line is displayed for each bill. You can press the go to button adjacent to Bill Due Date to be transferred to Financial Transactions On A Bill where the individual financial transactions associated with the associated service agreement and bill can be viewed. The following information is displayed in the grid:

- Statement Print Description is the description of the construct detail associated with the service agreement.

- Bill's Due Date is the date of the bill on which the service agreement's financial transactions appear. Press the adjacent go to button to be transferred to Financial Transactions On A Bill where the individual financial transactions can be viewed.

- Premise Information describes the characteristic premise, if any, associated with the service agreement.

- SA Information describes the service agreement that contributed financial transactions to the statement.

- Account Information describes the account associated with the service agreement whose details appear on the statement.

- Construct Detail ID is the unique identifier of the construct detail associated with the service agreement.

- Statement Detail ID is the unique identifier of the statement detail on which the service agreement's financial transactions appear.

Sales & Marketing Business Processes

The sales and marketing functionality satisfies many diverse requirements. For example, you can use this functionality to:

- Enroll new customers using a single transaction (i.e., you don't have to use the person, premise, service point, and start / stop transactions to enroll a new customer who resides at a new premise).

- Sell new products to existing customers.

- Update person, account and premise information using a single transaction.

- Market your services to prospects from a marketing list (and measure the success of your efforts). If the customer responds to your sales efforts, the system will automatically setup the customer, premise and related service agreements.

- Setup marketing surveys and record your customers' responses.

- Quickly create one-time charges.

- Setup proposals for prospective services (and then send a quotation to the customer for these services).

- And more...

The topics in this section provide more information about the sales and marketing functions.

Contents

The Big Picture of Campaigns, Packages and Orders

The Big Picture Of Package Eligibility Rules

The Big Picture Of Campaign Eligibility Rules

Designing Campaigns and Packages

Other Useful Information

Maintaining Orders

Maintaining Campaigns

Maintaining Packages

The Big Picture of Program Management

The Big Picture of Campaigns, Packages and Orders

Three objects are at the heart of the sales and marketing functionality: Campaigns, Packages, and Orders.

- A package defines a basket of goods and services that can be offered to a customer or a prospect.

- A campaign is a structured effort to offer a given set of packages to existing customers or new prospects.

- An order is created for each customer / prospect to which a campaign is targeted.

The topics in this section provide background information about these objects.

Contents

An Overview of Campaigns, Packages and Orders

Supported Business Processes

Examples of Campaigns and Packages

An Overview of Campaigns, Packages and Orders

An order is used to define:

- Demographic information about a customer / prospect.

- Geographic information about the service address.

- The customer's response to eligibility-oriented questions. For example, you can pose questions like: Who is your current energy service provider? / Would you like to pay automatically? / What is your date of birth?

After the above information is defined, the order transaction presents packages that may be offered to the customer. A package controls the various types of service agreements that will be created if the customer selects the package.

Note:

The customer must be eligible for a package. When you setup a package, you define its eligibility criteria. For example, you can setup a package that is only applicable to commercial customers in Toronto who pay automatically and who commit to a one-year service contract.

If the customer elects to take a package, the order transaction sets up / updates the "V" (along with all of the ancillary things that happen when service is initiated, e.g., field activities are created). Please note that in addition to setting up the "V", it's also possible to populate / update other information when a package is selected. For example, you could have the system setup the customer's automatic payment options.

Note:

An order can be completed without creating service agreements. It is possible to use the order transaction to simply create / update persons and accounts. Refer to Marketing Surveys and Setting up a New Customer Prior To Using Start/Stop for more information.

All orders must reference a campaign. An order's campaign defines:

- How the campaign's orders use accounts and premises. For example, you can indicate that a given campaign is only targeted at existing premises (thus preventing the creation of a new premise when an order is completed).

- The type of information defaulted onto an order. For example, you can setup a campaign to default a given account management group on all orders linked to the campaign. This account management group will subsequently default onto the new account when the order is completed.

- The validation rules that control how its orders use accounts and premises. Specifically, on a campaign you define if an account / premise is required / optional / not allowed on its orders. In addition, if an account / premise is required or optional, you can control whether new accounts / premises can be created when an order is completed (the alternative is to force each order to use an existing account / premise). These controls prevent the unwanted proliferation of new accounts and premises for campaigns that are targeted at existing accounts and premises.

- The eligibility-oriented questions that are posed to the customer when an order is taken. For example, the questions indicated above - Who is your current energy service provider? / Would you like to pay automatically? / What is your date of birth? - are all defined on the order's campaign.

- The superset of packages that can be offered to a customer whose order references this campaign. An order's campaign defines the types of packages that may be selected.

- In addition to the above, campaigns also control high-level eligibility rules and business process flows.

Note:

Bottom line. Campaigns allow you to define a group of packages that a customer is eligible to purchase. Every time a campaign is targeted at a customer, an Order is created. The information entered on the order qualifies the customer for one of the campaign's packages. If a customer elects to take a package, the "V" is setup / updated along with all of the ancillary things that happen when service is initiated, e.g., field activities are created, workflow processes are initiated, etc.

Supported Business Processes

Before providing examples of specific business processes, we'd like to highlight that you have control over some aspects of the user-interface flow (i.e., the screen navigation is not hard-coded). The following illustration highlights the potential user-interface flow:

Note:

Bottom line. You can navigate to the order transaction from many places in the system. After you complete an order, you are transferred to an appropriate transaction. The specific transaction is controlled by you when you setup the order's campaign.

The topics that follow illustrate specific business process flows that are possible in your implementation of the sales and marketing functionality.

Contents

Marketing to Prospects from a Marketing List

Marketing to Pre-selected Customers

Real-time Marketing of Additional Services to a Customer

Real-time Marketing of Services to a Prospect

Setting up a New Customer Prior To Using Start/Stop

Marketing to Prospects from a Marketing List

The following business process flow illustrates how the sales and marketing functionality would be used to market to prospects uploaded from a marketing database.

The following points describe the steps in this business process:

- An upload interface creates an order for each entry in a marketing database.

Note:

The system is not supplied with a dedicated interface to upload a marketing list. We recommend that you use the XAI utility to implement such an upload.

- Each order is routed to a salesperson via a To Do entry (or via a predictive dialer if your company supports this type of technology).

- The first step in the salesperson's interaction with the prospect will be to confirm the information uploaded from the marketing list (e.g., is your Bob Smith?, is your address 15 Main St?, etc.). Any changes are made to the information saved on the order.

- The salesperson's next step involves posing eligibility-oriented questions related to the campaign. Examples of questions include:

- What is your date of birth? This type of question might be asked if you have packages that are only marketed to senior citizens. Potential answers would be a valid date that's in the past.

- Would you be interested in our full-service option (electricity, digital cable and gas)? Potential options are: yes and no.

- Who is your current electric service provider? Potential answers are: Utility.Com, Reliant Resources, Other.

- Would you like to pay automatically? Potential answers are: Yes, No.

- Would you like to pay using a levelized payment plan? Potential answers are: Yes, No.

- Etc.

- The gathered information is saved on the order and then the system displays the packages that can be offered to the customer. The available packages may be restricted based on information on the order. For example, some packages are only applicable to senior citizens, while others are only applicable to customers whose current service provider is Utility.com.

- If the customer is interested in a package, the salesperson selects it. Prior to the order being completed, the package confirmation page is shown. On this page are additional instructions about the package and a description of how the system will be updated if the package is selected (e.g., the types of service agreements will be displayed). In addition, the package may require additional information before it can be chosen. For example, the package may only be selectable if the customer agrees to pay automatically. In this situation, the package confirmation page will require the salesperson to enter the customer's bank and bank account.

- After entering all package-specific information, the order is completed. When the order is completed, the "V" is setup and all work necessary to satisfy the order is initiated (e.g., field activities are created, workflow processes are initiated, etc.).

- And finally, the user is returned to Control Central - Account Info where an overview of the customer is displayed. From this page, the user can drill down to any service agreement (or to start/stop) to perform any fine-tuning.

- Please be aware that the page to which you are transferred after order completion is controlled by a field on the order's campaign. In our example, it made sense to transfer the user to Control Central as it provides a nice confirmation to the user (it shows a great deal of information about an account). However, you could setup the campaign to take the user to virtually any page in the system. You'll see good examples later in this discussion.

Marketing to Pre-selected Customers

The following business process flow illustrates how the sales and marketing functionality would be used to market additional services to existing customers selected by a background process.

The following points describe the steps in this business process:

- A background process creates an order for each customer to be targeted under a marketing campaign.

Note:

The base package does not have an example of such a background process. Please speak to your support team if you require assistance in developing this type of process.

- Sales people would then process the order as described above.

Real-time Marketing of Additional Services to a Customer

The following business process flow illustrates how the sales and marketing functionality would be used to market additional services to existing customers when they call in.

The following points describe the steps in this business process:

- When you find the customer's record on Control Central - Main, you are automatically transferred to the Account Information portal. One of the zones on this page contains the campaigns that can be offered to the customer.

Note:

The "potential campaigns" zone only appears if the CSR has modified their preferences to display this zone.

- If you select a campaign from this zone, you are transferred to the Order transaction.

Note:

An order's campaign controls whether the Main or Questions & Misc Fields tab is initially displayed when the order transaction is invoked from this zone. For example, you might want to have the Main tab displayed if you want the order-taker to confirm the customer's demographic information before posing questions. Alternatively, you may want to skip this step and immediately present the order-taker with the campaign's questions. Keep in mind that the user can always display the other tab regardless of what is initially displayed.

- You then process the order as described above.

Note:

An easy way to create one-time charges. The above business process illustrates how the selection of a package will create one or more new service agreements for a customer. If your organization levies one-time charges (e.g., tree trimming charges, damage assessments, etc.), you can also use the order transaction to create both a "one-time charge" service agreement and create the related billable charge when the order is completed. To do this, setup a campaign with a separate package for each possible one-time charge. If an order is created for this type of campaign and the relevant package is selected, the system will setup the new billable charge service agreement and link the billable charge to it. Refer to An Easier Way To Create One Time Charges for an example of such a campaign.

Real-time Marketing of Services to a Prospect

The following business process flow illustrates how the sales and marketing functionality would be used to market services when a new customer calls.

Warning:

We do not recommend using this business process if your organization's service territory is predefined (i.e., if you've set up the premises and service points for your entire service territory). Why? Because it can result in the creation of new premises and / or service points and you probably don't want this to happen if you've already set everything up. While it is possible to disable the creation of new service points and premises by developing new plug-ins, we'd recommend using the business process described under How To Add A New Customer From Control Central if a new customer calls in and you have predefined premises and service points.

The following points describe the steps in this business process:

- You look for the customer using Control Central - Main. Because the customer is new, you push the Add Order button on Control Central to transfer to the Order transaction.

- You then process the order as described above.

In order to take advantage of the above business process, it's important that you understand the following points:

- When the order page is opened for a new customer, the order's campaign is defaulted from the installation record. The default campaign on the installation record is "generic" because we don't know anything about the customer (they are new) and therefore we cannot default a campaign targeted to their customer class or geography.

- This default campaign on the installation record must be constructed using one of the following approaches:

- The default campaign has a package for every potential type of customer who can call up. While this is possible, it's probably not realistic as the data setup burden required to define every type of package could be onerous. However, if you have a limited number of service agreements, this approach is feasible.

- The default campaign could just be a "dummy" campaign that has no packages. The "real" campaigns will only be shown after basic information about the customer has been recorded on the order and the "show eligibility" button is pressed. These campaigns appear in the order's eligibility tree. The selection of a campaign in this tree will cause the order's campaign to be switched. Note, because the "dummy" campaign has no packages, no packages will appear in the order's eligibility tree when the dummy campaign is referenced on an order.

- The order is then processed as described above.

Setting up a New Customer Prior To Using Start/Stop

The following business process flow illustrates how the sales and marketing functionality would be used to create a new customer prior to using Start / Stop to start service at an existing premise.

Note:

The following business process is similar to that described under How To Add A New Customer From Control Central. The only difference is that the Order transaction is used to create a new person and account rather than the Person transaction. The order transaction may be a better choice because it lets you define many attributes on person, account and premise that are not accessible on the person page. For example, the order transaction lets you define the customer's automatic payment option, bill after date, override due date, etc. In addition, on an order's campaign, you can define default values of many field values (both real fields and characteristics). These default values are presented on the order transaction and may be overridden by the user at will.

The following points describe the steps in this business process:

- You look for the customer using Control Central - Main. Because the customer is new, you push the "Add Order" button on Control Central to transfer to the Order transaction.

- You record additional demographic and geographic information about the new customer and confirm all values defaulted from the order's campaign. After all required information is entered, you press the Update Cust. Info and Go To Start / Stop button to create the new person and account and transfer to Start / Stop to identify the new services desired by the customer.

Note:

The button's existence and label are dynamic. In the above example, we indicated that there is a button on the order page called Update Cust. Info and Go To Start / Stop. This button's presence on the page and its label are controlled by fields on the campaign. When pressed, the "V" is updated with information on the order and the user is transferred to the "post completion" page (which is also defined on the campaign). You would only enable this button on campaigns whose orders can be completed without selecting a package. In the above example, the campaign doesn't have any packages (because service is intended to be started using Start / Stop). In Examples of Campaigns and Packages we show other examples of how these fields would be setup for different types of campaigns.

In order to take advantage of the above business process, it's important that you understand the following points:

- When the order page is opened as a result of pressing the Add Order button on Control Central - Main, the order's campaign is defaulted from the installation record. The default campaign on the installation record is "generic" because nothing is known about the new customer and therefore it is impossible to default a campaign targeted to their customer class or geography.

- The campaign on the installation record should be setup to contain default information for the "average" customer. For example, if you typically deal with residential customers, the information on the default campaign should be residential-oriented.

- When a user takes an order for a new customer, they'll change the default information when appropriate. For example, if an industrial customer were being added, they'd change the customer class to "industrial" and then ask to see the campaigns such a customer is eligible to choose (these alternate campaigns are displayed in the order's eligibility tree). For example, if you've setup campaigns with eligibility rules that are targeted at industrial customers and the customer class on the order has been changed to "industrial", the user will see these campaigns in the eligibility tree. The user can then change the campaign's order by simply clicking on the desired campaign.

Note:

The above example illustrates how an order can be completed without causing the creation of service agreements. Refer to Marketing Surveys and Prelude to Start Stop for examples of such campaigns.

Examples of Campaigns and Packages

The topics that follow provide examples of campaigns and packages that support several different scenarios. Your organization's campaigns and packages may differ markedly from these examples. Factors that will influence your sales and marketing objects include:

- Whether the type of goods and services marketed to your customers / prospects differs depending on some trait of the customer or the region in which they are located. For example,

- Your company may have very straightforward packages that only differ based on whether the customer is industrial, residential or commercial. If this describes your company, the setup process will be simple.

- Alternatively, your company might offer different packages to residential customers based on whether they pay automatically, whether the customer is a senior citizen, whether they purchase multiple services from you, etc. If this describes your company, then you'll have to define the various eligibility criteria and the respective packages applicable to customers who satisfy each criterion.

- Whether premises exist prior to order taking. For example, a company that distributes a commodity has a well-defined geographic area and therefore new premises typically don't arise when orders are taken.

- Whether your company offers many different types of goods and services.

- Whether your rates have charges / discounts that are only applied to some customers. For example, you might have discounts that are applied if the customer is a senior citizen or an employee.

- Which of the Supported Business Processes you implement.

Use the information that follows to form an intuitive understanding of campaigns and packages. After attaining this understanding, you'll be ready to design your own campaigns and packages.

Contents

Campaigns Without Packages

Campaigns With Simple Packages

Campaigns With Complex Packages

Campaigns Without Packages

An order that references a campaign without packages will never create service agreements. The following topics describe scenarios when such a campaign would be used.

Contents

Marketing Surveys

Prelude to Start/Stop

Marketing Surveys

Some organizations conduct "marketing surveys" to determine general trends amongst their customer base. The following diagram illustrates how such a campaign might look:

Note the following about this campaign:

- If the campaign is used to establish new customers, you can define information to default onto orders created for new customers. Because marketing surveys are targeted at existing customers, you don't need new customer default information on the campaign.

- You can define questions to be posed to customers when an order is taken when you setup a campaign. For a "marketing survey" campaign, you'd define each of the survey questions and the permissible answers. When a customer is surveyed, an order is created and their answers are saved on the order.

- On a campaign, you can define additional fields to be updated on persons, accounts and premises when orders associated with the campaign are completed. For example, you could indicate that the account's override due date and automatic payment options should be confirmed when an order is taken. Because marketing surveys are typically only asking questions, you wouldn't need to define additional customer information fields to be confirmed. However, you can if you want.

- All campaigns need at least one eligibility rule. These rules control whether the campaign appears in the "eligible campaigns" content zone when a customer is selected on Control Central. These rules also control whether the campaign appears on an order's eligibility tree (campaigns that appear in this tree are alternate campaigns that may be used on the order). Our example has assumed that this is a residential customer survey and therefore it only needs a single eligibility rule. Refer to The Big Picture Of Campaign Eligibility Rules for more information.

- Because this campaign is used purely to manage a marketing survey, it doesn't need any packages. Packages are only necessary if service agreements are created when an order is completed.

- Because this campaign doesn't have packages, we have indicated that the button that allows orders to be completed without selecting a package is enabled. If you don't enable this button, a user won't be able to complete a marketing survey (and it is only during order completion when the "V" is updated with the information on the order). Notice that we have assigned the button a label of Complete Survey.

- This campaign should be setup to transfer the user to Control Central - Account Info after the survey is completed.

Prelude to Start/Stop

Consider the example illustrated above under Setting up a New Customer Prior To Start / Stop. In this example, the order transaction is used to create a new person and account; no service agreements are created when the order is completed. Rather, after the order is completed, the user is automatically transferred to Start / Stop where they can create service agreements. The following diagram illustrates how such a campaign might look:

Note the following about this campaign:

- Because this campaign is used to establish new customers, you should define new customer default information. The order taker can override these default values.

- If we assume you don't ask marketing / eligibility-oriented questions when you take-on a new customer then this campaign would not require any questions.

- On a campaign, you can define additional fields to be updated on the related person, account and premise when orders associated with the campaign are completed. For example, you could indicate that the account's override due date and automatic payment options should be confirmed when an order is taken. In our example, we are assuming that we want to define the customer's automatic payment options and his/her date of birth.

- As described under Marketing Surveys, a campaign's eligibility rule(s) control whether the campaign appears in the "eligible campaigns" content zone and on an order's eligibility tree. This campaign is odd in that we don't want it to ever appear as an "eligible campaign" because it's only used for NEW customers. In order to make this work you must:

- Define an eligibility algorithm on this campaign that prevents it from appearing as an "eligible campaigns". Refer to A Campaign That Is Never Eligible for more information.

- Update the installation record to indicate that this campaign is the one that should be used on orders created when a user presses the "Add an Order" button on Control Central - Main. Refer to Setting up a New Customer Prior To Starting Service for more information about the flow of this business process.

- Because this campaign is used purely to add accounts and persons, it doesn't need any packages. Packages are only necessary if service agreements are created when an order is completed.

- Because this campaign doesn't have packages, we have indicated that the button that allows an order to be completed without selecting a package is enabled. If you don't enable this button, a user won't be able to complete the order (and it is only during order completion when the "V" is updated with the information on the order). Notice that we have assigned the button a label of Update The V and Go To Start.

- This campaign should be setup to transfer the user to Start / Stop after the order is completed.

Campaigns With Simple Packages

As explained under Campaigns Without Packages, there are several situations that might necessitate a campaign without packages. In this section, we describe simple scenarios of campaigns with packages.

An Easier Way To Create One Time Charges

We use the term "one-time charge" to describe ad hoc charges, e.g., tree trimming charges, damage assessments, etc. The following points describe how one-time charges are levied if you don't use the order transaction:

- Determine if the customer to be invoiced already has an appropriate "one-time charge" service agreement. If one doesn't exist, you must create one using Start/Stop Service.

- Next, a billable charge is added to the "one-time charge" service agreement (using Billable Charge Maintenance). The billable charge contains the invoice lines and amounts. The system will produce the bill for this charge when the account's bill cycle next executes.

Rather than going through the above multi-step process, you can also use the order transaction to create both a "one-time charge" service agreement AND create the billable charge. In addition, if the customer receiving the charge is new, the order transaction will also create a new person and account at the same time.

To take advantage of this facility, you must set up a campaign that has a separate package for each type of one-time charge as illustrated below. When an order is taken for such a campaign, the user simply selects the package that corresponds with the desired one-time charge. The system will then create the necessary customer and financial information when the package is confirmed.

Note:

Billing of one-time charges. The order transaction will not cause a bill to be generated for the customer. Rather, the next time the account is billed, the system will see that there's an unbilled billable charge and create a bill segment for it. This bill segment will appear on the customer's regular bill along with their other charges. If you'd prefer to create the bill for the one-time charges immediately, you could setup the campaign to automatically transfer the user to the bill transaction where they can create an ad hoc bill. Note, if you do this, you'll need to create a new plug-in algorithm on the billable charge SA type to automatically activate the service agreement when it is created (otherwise the user would have to manually activate the billable charge service agreement before the bill can be generated).

Note the following about this campaign:

- One-time charges can be levied against both new and existing customers. This means that orders associated with this campaign may cause new customers to be created. Therefore, we have specified information to default onto orders for new customers on the campaign. Note that we defined "residential-oriented" default values as the majority of one-time charges are levied against residential customers.

- If we assume you don't ask marketing / eligibility-oriented questions when you levy a one-time charge then this campaign would not require any questions.

- We have assumed that you are not capturing miscellaneous fields when you levy a one-time charge.

- As described under Marketing Surveys, all campaigns need at least one eligibility rule. We have assumed that this campaign's packages can be selected by all types of customers and have therefore specified an eligibility algorithm that will be true for all customers.

- Because this campaign has packages, we have indicated that the button that allows an order to be completed without selecting a package is disabled. This means a user must choose one of the packages to complete the order.

- You might want to setup this campaign to automatically transfer the user to the bill transaction after the order is completed. See the note above the illustration for more information.

- We have assumed that this campaign can be used to levy two kinds of one-time charges - a tree trimming charge and a damaged line charge - and therefore this campaign requires two packages. Note the following about each package:

- A package's eligibility rules control whether the package can be selected when an order is taken. With more sophisticated campaigns, you may have packages that are only applicable to certain types of customers. In our example, we've assumed that these types of one-time charges can be levied against all customers and have therefore used "universal" eligibility criteria (i.e., there are no eligibility restrictions). Refer to A Package That Is Always Eligible for more information.

- On a package, it's possible to define additional questions to be posed if a package is selected. In our example, there are no additional questions to be posed for the one-time charge packages.

- On a package, it's possible to define additional fields to be captured if a package is selected. In our example, there are no additional fields to be captured.

- On a package, you define the types of service agreements to be created if a package is selected. In our example, we only need a single service agreement created / updated if the package is selected and therefore there's just one entry in SA's To Create. Please note the following about the information used to create this service agreement:

- The SA Type is one that's used for a billable charge service agreement.

- The SA Type's Start Option is one that will automatically create a billable charge when a service agreement is created (if a start option references a billable charge template, a billable charge will be created when this start option is used). In our example, we have assumed a different start option has been setup for each type of one-time charge.

- Billable charge service agreements do no require service points and therefore SP Type is not applicable.

- We've indicated a Start Algorithm of Billable Charge . Refer to STRM-AS for an example of such an algorithm (type).

Campaigns With Complex Packages

The Campaigns With Simple Packages illustrated campaigns with very simple packages. In this section, we describe a campaign with more complex packages.

Contents

Packages Limited By Answers And Field Values

Packages Limited By Current State Of Service

Packages Limited By Answers And Field Values

Assume your organization has a campaign with several packages. Each package has the following restrictions in respect of its use:

- "Package 1" can be offered to residential customers in California who are senior citizens.

- "Package 2" can be offered to residential customers in California who live in single-family homes who are not senior citizens and who heat their homes with electricity.

- "Package 3" can be offered to residential customers in California who live in single-family homes who are not senior citizens and who heat their homes with gas.

- "Package 4" can be offered to residential customers in California who live in multi-family homes who are not senior citizens.

Also assume that all customers are encouraged to pay automatically.

The following diagram illustrates how such a campaign might look:

The topics that follow describe the campaign and packages used to support this scenario. We'll start by explaining each package. Then we'll describe how the campaign will be setup. This seems backwards, but it mirrors how you should design this type of campaign:

Contents

Senior Citizen Package

Single-Family Electric Package

Single-Family Gas Package

Multi-Family Package

The Campaign

S enior Citizen Package

The package that is offered to residential customers in California who are senior citizens has the following traits:

- It has eligibility rules that restrict its use to customers who meet the following criteria:

- Customer class = Residential

- Division = California

- Birth date equates to that of a senior citizen

- We only need a single service agreement created if the package is selected and therefore there's just one entry in SA's To Create. Please note the following about the information used to create this service agreement:

- The SA Type is one that's used for an electric residential service agreement (hence the E-RES SA type).

- The SA Type's Start Option is one that will automatically setup the service agreement with the appropriate rate and contract options for a senior citizen.

- The service agreement needs to be linked to an electric residential service point (hence the E-RES SP type).

- We've indicated a Start Algorithm of Start SP Service . Refer to STRM-VT for an example of such an algorithm (type).

- We have not shown additional questions or miscellaneous fields in this package. This is because this package doesn't have additional questions or additional fields.

S ingle-Family Electric Package

The package that is offered to residential customers in California who live in single-family homes who are not senior citizens and who heat their homes with electricity has the following traits:

- It has eligibility rules that restrict its use to customers who meet the following criteria:

- Customer class = Residential

- Division = California

- Birth date does not equate to that of a senior citizen

- The premise is a single-family home

- The premise is heated with electricity

- We only need a single service agreement created if the package is selected and therefore there's just one entry in SA's To Create. Please note the following about the information used to create this service agreement:

- The SA Type is one that's used for an electric residential service agreement (hence the E-RES SA type).

- The SA Type's Start Option is one that will automatically setup the service agreement with the appropriate rate and contract options for this type of customer.

- The service agreement needs to be linked to an electric residential service point (hence the E-RES SP type).

- We've indicated a Start Algorithm of Start SP Service . Refer to STRM-VT for an example of such an algorithm (type).

- We have not shown additional questions or miscellaneous fields in this package. This is because this package doesn't have additional questions or additional fields.

S ingle-Family Gas Package

The package that is offered to residential customers in California who live in single-family homes who are not senior citizens and who heat their homes with gas has the following traits:

- It has eligibility rules that restrict its use to customers who meet the following criteria:

- Customer class = Residential

- Division = California

- Birth date does not equate to that of a senior citizen

- The premise is a single-family home

- The premise is heated with gas

- We only need a single service agreement created if the package is selected and therefore there's just one entry in SA's To Create. Please note the following about the information used to create this service agreement:

- The SA Type is one that's used for a gas residential service agreement (hence the G-RES SA type).

- The SA Type's Start Option is one that will automatically setup the service agreement with the appropriate rate and contract options for this type of customer.

- The service agreement needs to be linked to a gas residential service point (hence the G-RES SP type).

- We've indicated a Start Algorithm of Start SP Service . Refer to STRM-VT for an example of such an algorithm (type).

- We have not shown additional questions or miscellaneous fields in this package. This is because this package doesn't have additional questions or additional fields.

M ulti-Family Package

The package that is offered to residential customers in California who live in multi-family homes who are not senior citizens has the following traits:

- It has eligibility rules that restrict its use to customers who meet the following criteria:

- Customer class = Residential

- Division = California

- Birth date does not equates to that of a senior citizen

- The premise is a multi-family home

- This package requires additional information that was not requested at the campaign-level. We're going to assume that the multi-family rate needs to know the number of units in the building. This means that this package needs an additional field (number of units).

- We only need a single service agreement created if the package is selected and therefore there's just one entry in SA's To Create. Please note the following about the information used to create this service agreement:

- The SA Type is one that's used for an electric residential service agreement (hence the E-RES SA type).

- The SA Type's Start Option is one that will automatically setup the service agreement with the appropriate rate and contract options for this type of customer.

- The service agreement needs to be linked to an electric residential service point (hence the E-RES SP type).

- We've indicated a Start Algorithm of Start SP Service . Refer to STRM-VT for an example of such an algorithm (type).

- We have not shown additional questions in this package. This is because this package doesn't have additional questions.

T he Campaign

Note the following about this campaign:

- Orders can be created for both new and existing customers. Because new customers are possible, we have specified information to default onto orders for new customers. Note that we defined "residential-oriented" default values (but remember, these values can be overridden on the order).

- The questions on the campaign are those whose answers play a part in each package's eligibility. You could also ask additional marketing survey-oriented questions that have nothing to do with package eligibility.

- The miscellaneous fields highlight an interesting situation. Notice that the date-of-birth and "automatic payment" fields are optional. However the field that holds the number of dwelling units is "only applicable on packages". When a field has this designation, the user will only be prompted to supply this field's value if a package is chosen where this field is applicable. In our example, only the Multi Family Package uses this field. This package will be setup to indicate that this field is required whereas the other packages will be setup to indicate that this field is not used.

Note:

Bottom line. The "miscellaneous fields" on a campaign must also include package-specific fields.

- All campaigns need at least one "highlight rule". These rules control whether the campaign appears in the "eligible campaigns" content zone when a customer is selected on Control Central. Also note that "highlight rules" also control whether the campaign appears on an order's eligibility tree (campaigns that appear in this tree are alternate campaigns that may be used on the order).

- We're going to assume that this is a residential campaign and therefore you would specify a highlight rule that returns true if the customer's customer class is residential.

- Because this campaign has packages, we have indicated that the button that allows an order to be completed without selecting a package is disabled. This means a user must choose one of the packages to complete the order.

- This campaign is setup so that the user will be transferred to Control Central - Account Info after the order is completed. This is a subjective decision as you could transfer the user to a variety of transactions. It's just that the Account Info page provides a nice confirmation of how the customer looks after the order has updated / created new information.

Packages Limited By Current State Of Service

Assume your organization has a campaign with several packages. Each package has the following restrictions in respect of its use:

- "Package 1" can be offered to residential customers in California who have gas service, but don't have electric service.

- "Package 2" can be offered to residential customers in California who have electric service, but don't have gas service.

- "Package 3" can be offered to residential customers in California who have neither electric nor gas service.

The following diagram illustrates how such a campaign might look:

The topics that follow describe the campaign and packages used to support this scenario. We'll start by explaining each package. Then we'll describe how the campaign will be setup. This seems backwards, but it mirrors how you should design this type of campaign:

Contents

Has Gas / No Electricity Package

Has Electricity / No Gas Package

No Electricity / No Gas Package

H as Gas / No Electricity Package

The package that is offered to customers that currently have gas service, but don't have electricity service has the following traits:

- It has eligibility rules that restrict its use to customers who meet the following criteria:

- Customer has gas service

- Customer doesn't have electricity service

- Refer to A Package With Service Type Comparisons for more information.

- We only need a single service agreement created if the package is selected and therefore there's just one entry in SA's To Create. Please note the following about the information used to create this service agreement:

- The SA Type is one that's used for an electric residential service agreement (hence the E-RES SA type).

- The SA Type's Start Option is one that will setup the service agreement with the appropriate rate and contract options.

- The service agreement needs to be linked to an electric residential service point (hence the E-RES SP type).

- We've indicated a Start Algorithm of Start SP Service . Refer to STRM-VT for an example of such an algorithm (type).

- We have not shown additional questions or miscellaneous fields in this package. This is because this package doesn't have additional questions or additional fields.

H as Electricity / No Gas Package

The package that is offered to customers that currently have electric service, but don't have gas service has the following traits:

- It has eligibility rules that restrict its use to customers who meet the following criteria:

- Customer has electric service

- Customer doesn't have gas service

- We only need a single service agreement created if the package is selected and therefore there's just one entry in SA's To Create. Please note the following about the information used to create this service agreement:

- The SA Type is one that's used for a gas residential service agreement (hence the G-RES SA type).

- The SA Type's Start Option is one that will setup the service agreement with the appropriate rate and contract options.

- The service agreement needs to be linked to a gas residential service point (hence the G-RES SP type).

- We've indicated a Start Algorithm of Start SP Service . Refer to STRM-VT for an example of such an algorithm (type).

- We have not shown additional questions or miscellaneous fields in this package. This is because this package doesn't have additional questions or additional fields.

N o Electricity / No Gas Package

The package that is offered to customers that don't currently have electricity or gas service has the following traits:

- It has eligibility rules that restrict its use to customers who meet the following criteria:

- Customer doesn't have electric service

- Customer doesn't have gas service

- We need two service agreements created (one for electricity, one for gas).

- We have not shown additional questions or miscellaneous fields in this package. This is because this package doesn't have additional questions or additional fields.

The Big Picture Of Package Eligibility Rules

The packages described under Examples of Campaigns and Packages have a variety of eligibility rules. Designing these rules can be easy or time-consuming; it all depends on the complexity of your business rules. We'll walk you through several examples to help you form an intuitive understanding of how to setup eligibility rules. Once you've acquired this intuition you'll be ready to design the eligibility rules for your own packages.

Note:

Don't confuse package eligibility rules with those associated with a campaign. Package eligibility rules control whether a customer is allowed to choose a package on the order transaction. Campaign eligibility rules control whether a campaign is highlighted on the "eligible campaigns" content zone and on an order's eligibility tree.

Contents

Criteria Groups versus Eligibility Criteria

Defining Logical Criteria

Examples Of Package Eligibility Rules

Criteria Groups versus Eligibility Criteria

Before we provide concrete examples of eligibility criteria, we need to explain two concepts: Criteria Groups and Eligibility Criteria. A package's criteria groups control whether a customer is eligible to choose a package. 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 for a given customer.

- When you create a group, you define what should happen if the group is TRUE or FALSE. You have the following choices:

- The customer is eligible to choose the package

- The customer is not eligible to choose the package

- The next group should be checked.

We'll use the following example to help illustrate these points. Assume a package exists that can only be selected if:

- The customer resides in California and their current retail supplier is company A, B or C

- OR, the customer resides in Nevada and their current retail supplier is company X, Y or A

This package requires two eligibility groups because it has two distinct conditions:

- IF (STATE = CALIFORNIA AND (SERVICE PROVIDER IN (A, B, C))

- IF (STATE = NEVADA AND (SERVICE PROVIDER IN (X, Y, A))

If either condition is true, then the customer is eligible for the package.

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

Customer resides in California and their current retail supplier is company A, B or C

Eligible

Check next group

2

Customer resides in Nevada and their current retail supplier is company X, Y or A

Eligible

Ineligible

The following criteria will be required for each of the above groups:

Group 1: Customer resides in California and their current retail supplier is company A, B or C

Seq

Logical Criteria

If Eligibility Criteria is TRUE

If Eligibility Criteria is FALSE

If Insufficient Data

10

State = California

Check next condition

Group is false

Group is false

20

Electric retail supplier in (A, B, C)

Group is true

Group is false

Group is false

Group 2: Customer resides in Nevada and their current retail supplier is company X, Y or A

Seq

Logical Criteria

If Eligibility Criteria is TRUE

If Eligibility Criteria is FALSE

If Insufficient Data

10

State = Nevada

Check next condition

Group is false

Group is false

20

Electric retail supplier in (X, Y, A)

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 choose one of the miscellaneous fields on the order (keep in mind that miscellaneous fields also hold the answers to any questions posed on the order).

- 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 whose job it will be to perform the comparison (and return 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 Package Eligibility Rules provide numerous examples to help you understand this design.

Examples Of Package Eligibility Rules

The topics in this section provide examples about how to setup package eligibility rules.

Contents

A Package That Is Always Eligible

A Package With A Time Span Comparison

A Package With Service Type Comparison

A Package With More Complex Operators

A Package That Is Always Eligible

If a package is always eligible, it still needs an eligibility group. Good examples of such packages are shown under An Easier Way To Create One Time Charges. A package that is always eligible would require the following eligibility information:

Group

No.

Group Description

If Group is TRUE

If Group is FALSE

1

Always eligible

Eligible

Eligible

The following criteria will be required for this group:

Group 1: Always eligible

Seq

Field to Compare

Comparison Method

If TRUE

If FALSE

If Insufficient Data

10

Algorithm: retrieve order's account

Algorithm: Always true

Group is true

Group is true

Group is true

This group's criterion is odd in that it's not comparing anything. In order to setup this criterion, you have to use the following "trick":

- Field to Compare. You can pick any miscellaneous field on the campaign. If the campaign has no miscellaneous fields, you'll need to setup an algorithm to retrieve a field from the order (refer to PKEL-ENRFLD for an example of this type of algorithm). In the above example, we used an algorithm to retrieve the order's account.

- Comparison Method. We chose a comparison algorithm that always returns a value of TRUE (refer to PKCC-DEFAULT for an example of this type of algorithm).

- You'll notice that if a value of TRUE is returned, the Group is true (and we've setup the group to indicate a true group means the customer is eligible for the package).

We understand this is a little complicated, but this design provides the power necessary to support very complex criteria. The following sections provide more examples to help you form a better understanding of these concepts.

A Package With A Time Span Comparison

The Senior Citizen Package has the following eligibility rules:

- Customer class = Residential

- Division = California

- Birth date equates to that of a senior citizen

These rules require only one eligibility group on the package. It would look as follows:

Group

No.

Group Description

If Group is TRUE

If Group is FALSE

1

Residential, Calif, Senior

Eligible

Ineligible

The following criteria will be required for this group:

Group 1: Residential, Calif, Senior

Seq

Field to Compare

Comparison Method

If TRUE

If FALSE

If Insufficient Data

10

Algorithm: retrieve order's customer class

= R

Check next condition

Group is false

Group is false

20

Algorithm: retrieve order's division

= CA

Check next condition

Group is false

Group is false

30

Misc Field On Order: Date of Birth

Algorithm: True if senior

Group is true

Group is false

Group is false

The first two criteria are easy; they simply retrieve a field on the order and compare it to a given value. If the comparison doesn't result in a TRUE value, the Group is false (and, the group indicates that if the group is false, the customer isn't eligible for the package). If the comparison results in a TRUE value, the next condition is checked.

The last 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 customer 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 package as described below.

- Field to Compare. The miscellaneous field in which the customer'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 customer's date of birth) is greater than 65 years (refer to PKCC-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 customer is eligible).

Note:

The time span algorithm can be used to compare days, weeks, months, etc. Refer to PKCC-TIMESPN for more information about this algorithm.

A Package With Service Type Comparison

The Has Gas / No Electricity Package has the following eligibility rules:

- Customer has gas service

- Customer doesn't have electricity service

These rules require only one eligibility group on the package. It would looks as follows:

Group

No.

Group Description

If Group is TRUE

If Group is FALSE

1

Has Gas, Doesn't Have Electricity

Eligible

Ineligible

The following criteria will be required for this group:

Group 1: Has Gas, Doesn't Have Electricity

Seq

Field to Compare

Comparison Method

If TRUE

If FALSE

If Insufficient Data

10

Algorithm: check if customer has gas service

= TRUE

Check next condition

Group is false

Group is false

20

Algorithm: check if customer has electric service

= TRUE

Group is false

Group is true

Group is false

Both criteria are similar - they check if the customer has a given type of service and act accordingly. We used a "field to compare" algorithm to pull this off, but this algorithm is a bit counter intuitive (but understanding it will provide you with another way to implement complex eligibility criteria):

- Field to Compare. We chose a "field to compare" algorithm that checks if an account has service agreements that belong to a given set of service types. It returns a value of TRUE if the customer has an active service agreement that matches one of the service types in the algorithm. In our example, the "check if customer has gas service" algorithm returns a value of TRUE if the customer has at least one active service agreement whose SA type references the gas service type. The "check if customer has electric service" algorithm is almost identical, only the service type differs. Refer to PKEL-SVCTYP for an example 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 FALS (this is not a misspelling). This value is, in turn, compared by the "comparison method" and the group is set to true, false or check next accordingly.

A Package With More Complex Operators

One of the eligibility groups described under Criteria Groups versus Eligibility Criteria has the following eligibility rules:

- Customer must live in California

- Service provider is A, B or C

The eligibility group in which these rules would be defined looks as follows:

Group

No.

Group Description

If Group is TRUE

If Group is FALSE

1

Lives in California, current service provider is either retailer A, B or C

Eligible

Ineligible

The following criteria will be required for this group:

Group 1: Lives in California, current service provider is either retailer A, B or C

Seq

Field to Compare

Comparison Method

If TRUE

If FALSE

If Insufficient Data

10

Algorithm: retrieve order's state

= CA

Check next condition

Group is false

Group is false

20

Misc Field On Order: Current electric supplier

IN A, B, C

Group is true

Group is false

Group is false

This example is very simple. The only thing worth pointing out is that a number of operators can be used when you define a "comparison method". Refer to Package - Eligibility for the complete list of operators.

The Big Picture Of Campaign Eligibility Rules

In the previous section, we explained how to Design Eligibility Rules For A Package. In this section, we explain how to design eligibility rules for a campaign.

A campaign's eligibility rules control two things:

- Whether the campaign appears in the Eligible Campaigns content zone. This content zone suggests possible campaigns for the current customer displayed on control central. You might want to use this zone if you have different campaigns that are offered to different types of customers. Refer to Real-time Marketing of Additional Services to a Customer for an example of how this content zone can be used to "up sell" additional services.

- Whether the campaign appears on an order's eligibility tree. Campaigns that appear in this tree are alternate campaigns that may be used on the order. Refer to Real-time Marketing of Services to a Prospect for an example of how an order's eligibility tree can contain alternate campaigns for an order.

Designing these criteria can be easy or time-consuming; it all depends on the complexity of your business rules. We'll walk you through several examples to help you form an intuitive understanding of how to setup campaign eligibility rules. Once you've acquired this intuition you'll be ready to design the eligibility rules for your own packages.

Note:

Don't confuse eligibility rules for a package with those associated with a campaign. Package eligibility rules control whether a customer is allowed to choose a package. Campaign eligibility rules control whether a campaign is highlighted on the Eligible Campaigns content zone and on an order's eligibility tree.

Contents

Campaign Eligibility Rules Are Not Strictly Enforced

Campaign Eligibility Rules Are Defined Using Algorithms

Examples Of Campaign Eligibility Rules

Campaign Eligibility Rules Are Not Strictly Enforced

While the system prevents ineligible packages from being selected for an order (based on the package's eligibility rules), the system does not strictly enforce a campaign's eligibility rules. In other words, a user can change the campaign on an order to any active campaign. This "laxness" is intentional; otherwise it could become impossible to change an order's campaign.

It might be more helpful to think of campaign eligibility rules as "highlight conditions". These "highlight conditions" simply control whether the campaign appears in the Eligible Campaigns content zone and on an order's eligibility tree.

Campaign Eligibility Rules Are Defined Using Algorithms

You define a campaign's eligibility rules using one or more algorithms on the campaign. These algorithms are relatively straightforward as they simply return one of the following values:

- Eligible . Meaning the customer is eligible for the campaign.

- Ineligible . Meaning the customer is not eligible for the campaign

- Check Next Algorithm . Meaning that the next algorithm should be checked. You'd only design an algorithm to return such a value if multiple algorithms are used to determine a customer's eligibility for a campaign.

Note:

Bottom line. A customer is eligible for a campaign if at least one of its eligibility algorithms returns a value of "eligible".

The Examples Of Campaign Eligibility Rules provide numerous examples to help you understand this design.

Examples Of Campaign Eligibility Rules

The topics in this section provide examples about how to setup campaign eligibility rules.

Contents

A Campaign That Is Always Eligible

A Campaign That Is Never Eligible

A Campaign For Residential Customers

A Campaign For California, Residential Customers

A Campaign That Is Always Eligible

If a campaign is always eligible, it would require a simple eligibility algorithm that returns an indication that it is always eligible . A good example of such a campaign is shown under An Easier Way To Create One Time Charges. Refer to CAEL-DEFAULT for an example of this type of eligibility algorithm.

A Campaign That Is Never Eligible

If a campaign is never eligible, it would require a simple eligibility algorithm that returns an indication that it is ineligible . A good example of such a campaign is shown under Prelude To Start / Stop. Refer to CAEL-DEFAULT for an example of this type of eligibility algorithm.

A Campaign For Residential Customers

If a campaign should only be targeted at residential customers, it would require a simple eligibility algorithm that returns an indication of eligible if the customer's customer class is residential. A good example of such a campaign is shown under Marketing Surveys. Refer to CAEL-CC for an example of this type of eligibility algorithm.

A Campaign For California, Residential Customers

If a campaign should only be targeted at residential customers in California, it would require two eligibility algorithms:

Algorithm No

Algorithm

Example Algorithm

1

Indicate Check Next Algorithm if customer class is "residential"

Refer to CAEL-CC for an example of this type of eligibility algorithm.

2

Indicate Eligible if division is "California"

Refer to CAEL-DIV for an example of this type of eligibility algorithm.

Designing Campaigns and Packages

Designing campaigns and packages can be simple or challenging. Factors that will influence the complexity of the design process include:

- Whether the type of goods and services marketed to your customers / prospects differs depending on some trait of the customer or the region in which they are located. For example,

- Your company may have very straightforward packages that only differ based on whether the customer is industrial, residential or commercial. If this describes your company, the setup process will be simple.

- Alternatively, your company might offer different packages to residential customers based on whether they pay automatically, whether they are a senior citizen, whether they purchases multiple services from you, etc. If this describes your company, then you'll have to define the various eligibility criteria and the respective packages applicable to customers who satisfy each criterion.

- Whether premises exist prior to order taking. For example, a company that distributes a commodity has a well-defined geographic area and therefore new premises typically don't arise when orders are taken.

- Whether your company offers many different types of goods and services.

- Whether your rates have charges / discounts that are only applied to some customers. For example, you might have discounts that are applied if the customer is a senior citizen or an employee.

- Which of the Supported Business Processes you implement.

The topics that follow provide a structured approach to design your campaigns and packages.

Contents

Determine The Place Of Start / Stop

Determine Which Types Of Service Agreements Are Created

Determine The Different Start Options That Exist For Each Type Of Service Agreement

Determine The SP Type (if any) For Each Service Agreement

Determine The Method Used To Create Each Service Agreement

Extract Algorithms From The Start Method

Determine Which Combinations Can Be Grouped Under A Package

Determine Package Eligibility Rules

Extract Algorithms From The Eligibility Rules

Extract Miscellaneous Fields From The Eligibility Rules

Determine Additional Information That Is Required If A Package Is Selected

Determine If There Are Additional Questions / Fields For Your Packages

Determine If Additional Instructions Should Be Shown

Determine If There Are Campaign-Level Fields / Questions

Determine The Properties Of Every Miscellaneous Field

Extract Characteristic From The Miscellaneous Fields

Extract Column References From The Miscellaneous Fields

Extract Algorithms From The Column References

Determine Account / Premise Dependency For Each Column Reference

Determine If Any Properties Are Overridden On Any Package

Determine The Eligibility Rules For The Campaign

Determine How The Campaign Behaves

Setup Sequence

Determine The Place Of Start / Stop

Before you can design your campaigns and packages, you must determine if your organization will use start / stop to initiate new service agreements or whether new service can be initiated using the order transaction. Refer to Order versus Start / Stop for information to help you make this decision.

If you decide to use start / stop to initiate service, we'd recommend creating the following types of campaigns:

- Create a campaign similar to that described under Prelude to Start / Stop.

- If you levy one-time charges, you may also want to create a campaign similar to that described under An Easier Way To Create One Time Charges.

- If your organization performs marketing surveys, you may also want to create a campaign similar to that described under Marketing Surveys.

If you decide to use the order transaction to initiate new service, follow the steps outlined in the following sections. Note that we use the example described under Packages Limited By Answers And Field Values when describing the design process.

Determine Which Types Of Service Agreements Are Created

Warning:

We have assumed that you have already designed your organization's SP types, SA types, start options and rates. If you have not yet done this, we recommend familiarizing yourself with the concepts described in Designing SP Types, Rates and Defining Service Agreement Types before designing your campaigns and packages.

Start off by determining the different types of service agreements that can be created if a package is selected. In our example campaign, only one SA type is used - E-RES (electric residential service).

Determine The Different Start Options That Exist For Each Type Of Service Agreement

After you know which SA types are going to be created, determine the potential start options that can be used for each SA type. In our example campaign, several start options are possible for the E-RES (electric residential service):

SA Type

Start Option

E-RES

Senior

E-RES

Single-Elec Heat

E-RES

Single-Gas Heat

E-RES

Multi-Family

Determine The SP Type (if any) For Each Service Agreement

The SA types and start options control how the service agreement will look (i.e., they control the rate, contract riders, characteristics, interval profiles, time-of-use maps, etc. defaulted onto new service agreements created when a package is selected). During this step, you define the SP type of the service point that will be linked to the service agreement. If several different types of SP types can be used for a service agreement, you'll have to choose one as this is the type of service point that will be created when the service agreement is created. If you plan to allow the package to be used to start service at an existing premise (and you don't want the system to create new service points), you will have to develop new plug-ins. Please speak to your implementation group if you need more information.

In our example campaign, only one SP type is created (or reused if the premise already has a service point of this type) - E-RES (electric residential service point):

SA Type

Start Option

SP Type

E-RES

Senior

E-RES

E-RES

Single-Elec Heat

E-RES

E-RES

Single-Gas Heat

E-RES

E-RES

Multi-Family

E-RES

Note:

Many service agreements don't need SP types. For service agreements that don't use service points (e.g., deposit service agreements, charitable contributions, one-time charges, etc.), you don't have to reference a SP type.

Determine The Method Used To Create Each Service Agreement

For each SA Type / Start Option / SP Type combination, determine the algorithm that will be used to create the service agreement and the service point. The base package is supplied with a limited number of such algorithm types (refer to STRM-AS and STRM-VT for examples).

SA Type

Start Option

SP Type

Start Method

E-RES

Senior

E-RES

Algorithm: Create new service agreement and stop old service agreement if active SA with the same service type exists

E-RES

Single-Elec Heat

E-RES

Algorithm: Create new service agreement and stop old service agreement if active SA with the same service type exists

E-RES

Single-Gas Heat

E-RES

Algorithm: Create new service agreement and stop old service agreement if active SA with the same service type exists

E-RES

Multi-Family

E-RES

Algorithm: Create new service agreement and stop old service agreement if active SA with the same service type exists

Extract Algorithms From The Start Method

The start methods illustrated above all require the same algorithm:

Algorithm Type

Algorithm

Parameter Values

Create SP and create SA (see STRM-VT)

Always create new SA and stop existing SA

2 (stop existing service)

Determine Which Combinations Can Be Grouped Under A Package

Now you determine which combinations of service agreements can be offered to a customer as a package. In our example campaign, a customer can only choose one type of service agreement (i.e., each entry in our table is mutually exclusive). This means that each entry is a separate package:

Package

SA Type

Start Option

SP Type

Algorithm

1

E-RES

Senior

E-RES

STRM-VT (Switch Option)

2

E-RES

Single-Elec Heat

E-RES

STRM-VT (Switch Option)

3

E-RES

Single-Gas Heat

E-RES

STRM-VT (Switch Option)

4

E-RES

Multi-Family

E-RES

STRM-VT (Switch Option)

Fastpath:

Refer to Packages Limited By Current State Of Service for an example of a package that has multiple service agreements.

Determine Package Eligibility Rules

The topics in this section describe the eligibility rules for each package in our example campaign.

Note:

Assumption. This section assumes you are comfortable with the information in The Big Picture Of Package Eligibility.

Contents

Eligibility Rules For Package 1

Eligibility Rules For Package 2

Eligibility Rules For Package 3

Eligibility Rules For Package 4

Eligibility Rules For Package 1

Package 1 (the senior package) in our example campaign has the following eligibility rules:

- Customer class = Residential

- Division = California

- Birth date equates to that of a senior citizen

These rules require only one eligibility group on the package. It would looks as follows:

Group

No.

Group Description

If Group is TRUE

If Group is FALSE

1

Residential, Calif, Senior

Eligible

Ineligible

The following criteria will be required for this group:

Group 1: Residential, Calif, Senior

Seq

Field to Compare

Comparison Method

If TRUE

If FALSE

If Insufficient Data

10

Algorithm: retrieve order's customer class

= R

Check next condition

Group is false

Group is false

20

Algorithm: retrieve order's division

= CA

Check next condition

Group is false

Group is false

30

Misc Field On Order: Date of Birth

Algorithm: True if senior

Group is true

Group is false

Group is false

Eligibility Rules For Package 2

Package 2 (the single-family / electric heat package) in our example campaign has the following eligibility rules:

- Customer class = Residential

- Division = California

- Birth date does not equate to that of a senior citizen

- Lives in a single-family home

- House is heated with electricity

These rules require only one eligibility group on the package. It would looks as follows:

Group

No.

Group Description

If Group is TRUE

If Group is FALSE

1

Residential, Calif, Non Senior, Single Family, Electric Heat

Eligible

Ineligible

The following criteria will be required for this group:

Group 1: Residential, Calif, Non Senior, Single Family, Electric Heat

Seq

Field to Compare

Comparison Method

If TRUE

If FALSE

If Insufficient Data

10

Algorithm: retrieve order's customer class

= R

Check next condition

Group is false

Group is false

20

Algorithm: retrieve order's division

= CA

Check next condition

Group is false

Group is false

30

Misc Field On Order: Date of Birth

Algorithm: True if senior

Group is false

Check next condition

Group is false

40

Misc Field On Order: Type of Residence

= S (single family home)

Check next condition

Group is false

Group is false

50

Misc Field On Order: Type of Heat

= E (electric)

Group is true

Group is false

Group is false

Eligibility Rules For Package 3

Package 3 (the single-family / gas heat package) in our example campaign has the following eligibility rules:

- Customer class = Residential

- Division = California

- Birth date does not equate to that of a senior citizen

- Lives in a single-family home

- House is heated with gas

These rules require only one eligibility group on the package. It would looks as follows:

Group

No.

Group Description

If Group is TRUE

If Group is FALSE

1

Residential, Calif, Non Senior, Single Family, Gas Heat

Eligible

Ineligible

The following criteria will be required for this group:

Group 1: Residential, Calif, Non Senior, Single Family, Gas Heat

Seq

Field to Compare

Comparison Method

If TRUE

If FALSE

If Insufficient Data

10

Algorithm: retrieve order's customer class

= R

Check next condition

Group is false

Group is false

20

Algorithm: retrieve order's division

= CA

Check next condition

Group is false

Group is false

30

Misc Field On Order: Date of Birth

Algorithm: True if senior

Group is false

Check next condition

Group is false

40

Misc Field On Order: Type of Residence

= S (single family home)

Check next condition

Group is false

Group is false

50

Misc Field On Order: Type of Heat

= G (gas)

Group is true

Group is false

Group is false

Eligibility Rules For Package 4

Package 4 (the multi-family package) in our example campaign has the following eligibility rules:

- Customer class = Residential

- Division = California

- Birth date does not equate to that of a senior citizen

- Lives in a multi-family home

These rules require only one eligibility group on the package. It would looks as follows:

Group

No.

Group Description

If Group is TRUE

If Group is FALSE

1

Residential, Calif, Non Senior, Multi Family

Eligible

Ineligible

The following criteria will be required for this group:

Group 1: Residential, Calif, Non Senior, Single Family, Gas Heat

Seq

Field to Compare

Comparison Method

If TRUE

If FALSE

If Insufficient Data

10

Algorithm: retrieve order's customer class

= R

Check next condition

Group is false

Group is false

20

Algorithm: retrieve order's division

= CA

Check next condition

Group is false

Group is false

30

Misc Field On Order: Date of Birth

Algorithm: True if senior

Group is false

Check next condition

Group is false

40

Misc Field On Order: Type of Residence

= M (multi family home)

Group is true

Group is false

Group is false

Extract Algorithms From The Eligibility Rules

The eligibility rules illustrated above require the following algorithms:

Algorithm Type

Algorithm

Parameter Values

Retrieve a field from the order for eligibility comparison (see PKEL-ENRFLD)

Retrieve Order's Customer Class

Field name: CUST_CL_CD

Retrieve a field from the order for eligibility comparison (see PKEL-ENRFLD)

Retrieve Order's Division

Field name: CIS_DIVISION

Time span comparison (see PKCC-TIMESPN)

Determine if birth date equates to that of a senior

Time span type: YEAR

Operator: >=

Comparison Value: 65

Extract Miscellaneous Fields From The Eligibility Rules

During this step, you extract miscellaneous fields that must be captured on the order in order drive your eligibility rules.

Misc. Field

Where Stored

Why Is It Needed

Date of birth

Person characteristic

Numerous eligibility rules use this field to determine if a customer is a senior citizen

Type of Residence

Premise characteristic

Numerous eligibility rules use this field to qualify a customer for a package

Type of Heat

Premise characteristic

Numerous eligibility rules use this field to qualify a customer for a package

Note:

Fields explicitly referenced on every order. You'll notice that we didn't list those fields referenced in the eligibility rules that are explicitly referenced on every order (e.g., customer class, state, division, etc.). This is because these types of fields come "for free".

Determine Additional Information That Is Required If A Package Is Selected

During this step, you determine if there's any information that needs to be created when a package is selected that can't be defaulted from its start option. In our example campaign, package 4 (the Multi-Family Home package), also needs to know the number of housing units at the premise (this information is probably needed to calculate a specific charge in the rate). None of the other packages require additional information. The extra field has been appended to our miscellaneous field table.

Misc. Field

Where Stored

Why Is It Needed

Date of birth

Person characteristic

Numerous eligibility rules use this field to determine if a customer is a senior citizen

Type of Residence

Premise characteristic

Numerous eligibility rules use this field to qualify a customer for a package

Type of Heat

Premise characteristic

Numerous eligibility rules use this field to qualify a customer for a package

Number of Units in House

Premise characteristic

The electric SA created by package 4 requires the number of units when it calculates the ongoing bill segments

Determine If There Are Additional Questions / Fields For Your Packages

Our example campaign indicates that all customers are encouraged to pay automatically. In order to pay automatically several fields are required (Start Date, End Date, Autopay Source (i.e., bank / credit card), Account Number, Account Name, Expiration Date). These fields are not "explicitly referenced" on the order and therefore must be captured as miscellaneous fields. We have appended these fields to our list of miscellaneous fields:

Misc. Field

Where Stored

Why Is It Needed

Date of birth

Person characteristic

Numerous eligibility rules use this field to determine if a customer is a senior citizen

Type of Residence

Premise characteristic

Numerous eligibility rules use this field to qualify a customer for a package

Type of Heat

Premise characteristic

Numerous eligibility rules use this field to qualify a customer for a package

Number of Units in House

Premise characteristic

The electric SA created by package 4 requires the number of units when it calculates the ongoing bill segments

Auto Pay Start Date

Account / Autopay Start Date Column

Used if a customer pays automatically

Auto Pay End Date

Account / Autopay End Date Column

Used if a customer pays automatically

Auto Pay Source

Account / Autopay Source

Used if a customer pays automatically

Auto Pay Account Number

Account / Autopay Account ID

Used if a customer pays automatically

Auto Pay Account Name

Account / Autopay Account Name

Used if a customer pays automatically

Auto Pay Account Expiration Date

Account / Autopay Account Expiration Date

Used if a customer pays automatically

We're going to assume that we don't capture any additional marketing-oriented questions. If we did, we'd need additional fields to hold the response to each question.

Determine If Additional Instructions Should Be Shown

If a package is selected, you can present additional instructions to the user informing them of special tasks they should perform (or special instructions they should give to the customer). For example, you could instruct the user to inform customers who aren't senior citizens that they should call back if they become seniors as they may qualify for a better rate. These instructions can be defined on each package.

For the sake of brevity, we will assume no additional instructions are necessary when a package is selected.

Determine If There Are Campaign-Level Fields / Questions

Next, you determine if there are additional fields that need to be captured regardless of the package that's selected. For example, you may want to capture additional demographic or geographic information for marketing purposes.

While our example campaign has no such requirement, for illustration purposes we'll assume you ask the customer to rate the quality of service they have experienced (assuming they are a current customer). This additional question requires another entry in our list of miscellaneous fields.

Misc. Field

Where Stored

Why Is It Needed

Date of birth

Person characteristic

Numerous eligibility rules use this field to determine if a customer is a senior citizen

Type of Residence

Premise characteristic

Numerous eligibility rules use this field to qualify a customer for a package

Type of Heat

Premise characteristic

Numerous eligibility rules use this field to qualify a customer for a package

Number of Units in House

Premise characteristic

The electric SA created by package 4 requires the number of units when it calculates the ongoing bill segments

Auto Pay Start Date

Account / Autopay Start Date Column

Used if a customer pays automatically

Auto Pay End Date

Account / Autopay End Date Column

Used if a customer pays automatically

Auto Pay Source

Account / Autopay Source

Used if a customer pays automatically

Auto Pay Account Number

Account / Autopay Account ID

Used if a customer pays automatically

Auto Pay Account Name

Account / Autopay Account Name

Used if a customer pays automatically

Auto Pay Account Expiration Date

Account / Autopay Account Expiration Date

Used if a customer pays automatically

Service Rating

Person characteristic

Campaign level marketing question

Determine The Properties Of Every Miscellaneous Field

At this point, you have amalgamated all miscellaneous fields required for the campaign and its packages. Now you have to define the following for each field:

- Prompt On Order. This is the prompt that will prefix the field when the order is taken. The following table provides examples.

- Campaign Applicability. This controls whether the field is optional , required , or only applicable on package(s) .

- A value of required means the order taker must enter a valid value before packages are displayed for selection.

- A value of optional means the order taker can leave the field blank prior to package selection. You can make an optional field required on individual packages. For example, you would probably make Date of birth required on the Senior package.

- A value of only applicable on packages is used for fields that are only captured for specific packages. Fields of this type are suppressed prior to package selection. When you setup a package, you indicate if the field is applicable (if so, the user is only prompted for the field if the package is selected).

- Type Of Response. This controls where the field is stored when the order is completed and how it is validated. You have two options: characteristic or column .

- If a field is a Characteristic , you must define which entity the characteristic value is to be stored on when the order is completed ( Person , Account , Premise or Order ). You must also define the Characteristic Type as this controls the characteristic value entered by the user.

- If a field's value resides is a column (as opposed to a characteristic value), you must define the column reference. A field's column reference controls three things:

- How the field's value is retrieved. A field's value is retrieved when an existing person / account / premise is referenced on an order.

- How the field's value is validated. A field's value is validated before package eligibility is determined and before the order is completed.

- How the field's value is posted (i.e., updated on the database). A field's value is posted when an order is completed.

Fastpath:

Refer to Extract Column References From Miscellaneous Fields for more information about column references.

- Default Value On Order. This controls whether the order taker is supplied with a default value when an order is created. Note well: for optional and only applicable on package fields, you can specify a different default value on each package.

Misc. Field

Prompt On Order

Campaign Applicability

Type Of Response

Default Value On Order

Date of birth

What is your date of birth (used to qualify for senior discount)?

Optional

Characteristic

Entity:Person

Char Type: Date of birth

Type of Residence

What type of residence do you live in?

Required

Characteristic

Entity:Premise

Char Type: Type of residence

S (single family)

Type of Heat

How do you heat your home?

Required

Characteristic

Entity:Premise

Char Type: Type of heat

E (electric)

Number of Units in House

How many units are in the entire house?

Only applicable on package(s)

Characteristic

Entity:Premise

Char Type: Number of units in house

Auto Pay Start Date

What day would you like to start automatic payment processing (YYYY-MM-DD)?

Optional

Column

Column Reference: Auto Pay Start Date

Auto Pay End Date

What day would you like to stop automatic payment processing (leave blank if not applicable)?

Optional

Column

Column Reference: Auto Pay End Date

Auto Pay Source

From what type of credit card / bank will the funds be debited?

Optional

Column

Column Reference: Auto Pay Source

Auto Pay Account Number

What is your credit card / bank account number?

Optional

Column

Column Reference: Auto Pay Account Number

Auto Pay Account Name

What is the name on your account?

Optional

Column

Column Reference: Auto Pay Account Name

Auto Pay Account Expiration Date

If paying with a credit card, what is the expiration date (MM-YYYY)?

Optional

Column

Column Reference: Auto Pay Credit Card Expiration Date

Service Rating

Please rate our service

Optional

Characteristic

Entity:Person

Char Type: Service rating

1 (excellent)

Extract Characteristic From The Miscellaneous Fields

Characteristic Type

Type

Valid Values

Entities On Which Characteristic Can Be Defined

Date of birth

Ad hoc value : use validation algorithm to confirm date is > 1-Jan-1900 and < 31-Feb-2002

Not applicable

Person , Order

Type of Residence

Predefined value

S: Single-Family

M: Multi-Family

Premise, Order

Type of Heat

Predefined value

E: Electric

G: Gas

Premise, Order

Number of Units in House

Ad hoc value : use validation algorithm to confirm value is > 0

Not applicable

Premise, Order

Service Rating

Predefined value

0: Not applicable

1: Excellent

2: Very Good

3: Good

4: Poor

Person, Order

Extract Column References From The Miscellaneous Fields

The miscellaneous fields illustrated above require the following column references (we describe the referenced algorithms at the bottom of the table):

Column Reference

Retrieval Algorithm

Validation Algorithm

Post Algorithm

Foreign Key Reference

Auto Pay Start Date

Retrieve account's current automatic payment information

Validate automatic payment information

Post automatic payment information

Auto Pay End Date

N/A - this field is handled by the Retrieval Algorithm on Auto Pay Start Date

N/A - this field is handled by the Validation Algorithm on Auto Pay Start Date

N/A - this field is handled by the Post Algorithm on Auto Pay Start Date

Auto Pay Source

N/A - this field is handled by the Retrieval Algorithm on Auto Pay Start Date

N/A - this field is handled by the Validation Algorithm on Auto Pay Start Date

N/A - this field is handled by the Post Algorithm on Auto Pay Start Date

Auto pay source

Auto Pay Account Number

N/A - this field is handled by the Retrieval Algorithm on Auto Pay Start Date

N/A - this field is handled by the Validation Algorithm on Auto Pay Start Date

N/A - this field is handled by the Post Algorithm on Auto Pay Start Date

Auto Pay Account Name

N/A - this field is handled by the Retrieval Algorithm on Auto Pay Start Date

N/A - this field is handled by the Validation Algorithm on Auto Pay Start Date

N/A - this field is handled by the Post Algorithm on Auto Pay Start Date

Auto Pay Expiration Date

N/A - this field is handled by the Retrieval Algorithm on Auto Pay Start Date

N/A - this field is handled by the Validation Algorithm on Auto Pay Start Date

N/A - this field is handled by the Post Algorithm on Auto Pay Start Date

There are three types of algorithms referenced in the above table:

- Retrieval algorithm. A column's retrieval algorithm retrieves the column's current value from the database. You'll notice that only one of our columns uses a retrieval algorithm. This is because we've used a sophisticated example of a group of columns that are retrieved at the same time. When you have such a group of columns, nominate one of the columns to do the retrieval work and specify the retrieval algorithm on it.

- Validation algorithm. A column's validation algorithm validates the column's value prior to the database being updated. You'll notice that only one of our columns uses a validation algorithm. This is because we've used a sophisticated example of a group of columns that are validated as a group. When you have such a group of columns, nominate one of the columns to do the validation work and specify the validation algorithm on it.

- Post algorithm. A column's post algorithm updates the column's value on the database when the order is completed. You'll notice that only one of our columns uses a post algorithm. This is because we've used a sophisticated example of a group of columns that are posted together. When you have such a group of columns, nominate one of the columns to do the posting work and specify the posting algorithm on it.

Notice that we have indicated that one of the columns has a "foreign key reference". You declare a "foreign key reference" if the valid values for a column are defined on another table in the system (this also affects the order user interface as a dropdown appears for columns that have foreign key references). In our example, Auto Pay Source is the only column whose valid values are defined on the automatic payment source control table.

Extract Algorithms From The Column References

The column references illustrated above require the following algorithms:

Algorithm Type

Algorithm

Parameter Values

Retrieve automatic payment information from an account (see CRRT-AP)

Retrieve automatic payment information from an account

Param 1 = Auto Pay Start Date Column Reference

Param 2 = Auto Pay End Date Column Reference

Param 3 = Auto Pay Source Column Reference

Param 4 = Auto Pay External Account Id Column Reference

Param 5 = Auto Pay Expiration Date Column Reference

Param 6 = Auto Pay Name Column Reference

Validate automatic payment information (see CRVL-AP)

Validate automatic payment information

Param 1 = Auto Pay Start Date Column Reference

Param 2 = Auto Pay End Date Column Reference

Param 3 = Auto Pay Source Column Reference

Param 4 = Auto Pay External Account Id Column Reference

Param 5 = Auto Pay Expiration Date Column Reference

Param 6 = Auto Pay Name Column Reference

Post automatic payment information (see CRPS-AP)

Post automatic payment information

Param 1 = Auto Pay Start Date Column Reference

Param 2 = Auto Pay End Date Column Reference

Param 3 = Auto Pay Source Column Reference

Param 4 = Auto Pay External Account Id Column Reference

Param 5 = Auto Pay Expiration Date Column Reference

Param 6 = Auto Pay Name Column Reference

Determine Account / Premise Dependency For Each Column Reference

Later in the design process (see Determine How The Campaign Behaves), you define on the campaign whether an account (and premise) is required, optional or not allowed on its orders. Your selection impacts how you setup column references. This is a little complicated so let's use an example:

- Assume you've setup a campaign to indicate a premise can optionally be defined on its orders.

- If the order-taker doesn't define a premise on an order, any premise-oriented questions and miscellaneous fields (Q&MF) should be suppressed on the order.

- It's easy for the system to know which Q&MFs to suppress when a Q&MF's response is held in a characteristic (because you must define on the campaign if the response will reside in an account, premise, person or order characteristic). For column reference Q&MFs, the system doesn't know if the response is account-oriented, premise-oriented or neither because algorithms handle the validation / updating of the response.

- Therefore, when you use column references on a campaigns Q&MFs, you must define if the responses are account-oriented or premise-oriented (so that the system can suppress the Q&MF when the user doesn't enter an account or premise on the order).

The following table contains the column references defined above as well as their dependency

Column Reference

Question Dependency

Auto Pay Start Date

Must have account

Auto Pay End Date

Must have account

Auto Pay Source

Must have account

Auto Pay Account Number

Must have account

Auto Pay Account Name

Must have account

Auto Pay Expiration Date

Must have account

You'll notice that each column reference is account-oriented (this is because automatic payment fields are stored on the respective account).

Determine If Any Properties Are Overridden On Any Package

At this point, you have defined the properties of all miscellaneous fields at the campaign level. You now need to determine if any of your packages need to override any of these properties. In general, you can only override miscellaneous fields whose campaign applicability is optional or only applicable on package(s) .

Our example campaign has only two overrides:

Package 1 requires the following miscellaneous field overrides:

Misc. Field

Override Prompt (seen if a package is selected)

Override Package Applicability

Override Default Value

Date of birth

Not overridden

Required

Not overridden

Package 4 requires the following miscellaneous field overrides:

Misc. Field

Override Prompt (seen if a package is selected)

Override Package Applicability

Override Default Value

Number of Units in House

Not overridden

Required

2

Warning:

If you override field properties on a campaign's packages, you will not be able to change the properties of the field at the campaign level.

Determine The Eligibility Rules For The Campaign

Note:

Assumption. This section assumes you are comfortable with the information in The Big Picture Of Campaign Eligibility.

The easiest way to determine a campaign's eligibility is to examine each package's eligibility criteria and abstract common eligibility restrictions onto the campaign. It's important to remember that campaign-level eligibility is only used to highlight if the campaign MAY contain applicable packages; campaign-level eligibility is not strictly enforced.

The packages on our example campaign are all targeted at residential customers in California. Therefore we'll take advantage of two base package algorithms to construct the campaign's eligibility criteria.

Algorithm Type

Algorithm

Parameter Values

Check if account's customer class is in a predefined list (see CAEL-CC)

If customer class is "residential", check next algorithm

If customer's customer class is in list: 30 (check next)

If customer's customer class is not in list: 20 (ineligible)

List of customer classes: R

Check if account's division is in a predefined list (see CAEL-DIV)

If division is "California", customer is eligible

If customer's CIS division is in list: 10 (eligible)

If customer's CIS division is not in list: 20 (ineligible)

List of customer classes: CA

Determine How The Campaign Behaves

The final step before you're ready to setup the campaign involves defining a variety of behavioral functions as described below:

- You need to define how the campaign uses accounts and premises. Specifically, on a campaign you define if an account / premise is required / optional / not allowed on its orders. In addition, if an account / premise is required or optional, you can control whether new accounts / premises can be created when an order is completed (the alternative is to force each order to use an existing account / premise). These controls prevent the unwanted proliferation of new accounts and premises for campaigns that are targeted at existing accounts and premises.

- Many fields on an order (e.g., phone type, customer class, division, account management group) can be defaulted on orders created for new customers. You will see these fields on Order - Main. Think about each such field and whether a default value is appropriate. Keep in mind that the order taker can override any of these default values.

- An order taker can indicate that they want to hold an order if they need to do further research before continuing with an order. A background process (referred to by the batch control ID TD-ECBK ) will create a To Do entry for held orders as a reminder to get back in touch with the customer on a future date. You can define the default To Do role assigned to such To Do entries when you create a campaign. Keep in mind that this value can be overridden when the order taker holds an order.

- You can indicate on a campaign the transaction to which the user should be transferred when orders are completed. Refer to Supported Business Processes for examples of how you might want to use this field.

Setup Sequence

And now you're ready to set up your campaign. The following points describe the order in which this should be done:

Warning:

We have assumed that you have already designed your organization's SP types, SA types, start options and rates. If you have not yet done this, we recommend familiarizing yourself with the concepts described in Designing SP Types, Rates and Defining Service Agreement Types before designing your campaigns and packages.

- Setup any new column references required by the campaign's miscellaneous fields. You will have to leave the retrieve, validate and post algorithms blank until after the next step.

- Setup any new algorithms required by:

- The packages' eligibility rules.

- The packages' start methods.

- The campaign's eligibility rules.

- The campaign's column references.

- Update the relevant column references with the appropriate retrieve, validate and post algorithms.

- Setup any new characteristic types required by the campaign's miscellaneous fields.

- Create the campaign using the information you designed above. Specifically:

- You defined the question and miscellaneous fields under Determine The Properties Of Every Miscellaneous Field.

- You defined the eligibility rules under Determine The Eligibility Rules For The Campaign.

- You defined everything else under Determine How The Campaign Behaves.

- We recommend leaving the campaign's status as Inactive until all packages are entered.

- Create the campaign's packages using the information you designed above. Specifically:

- You defined the question and miscellaneous field overrides under Determine If Any Properties Are Overridden On A Package.

- You defined the eligibility rules under Determine Package Eligibility Rules .

- You defined the instructions under Determine If Additional Instructions Are Required.

- Change the campaign's status to Active .

Note:

The default campaign on the installation record. If the campaign you've setup is the "default" campaign used when a user presses the Add Order button on Control Central, make sure to specify it as the default campaign on the installation record. Refer to Setting up a New Customer Prior To Starting Service for more information.

Other Useful Information

The topics in this section contain miscellaneous information about the sales & marketing functions.

Contents

Order versus Start / Stop

Orders Cannot Be Changed After They Are Completed

Premise and SP Characteristics May Be Populated From Postal Defaults

To Do List Processing

Hold and Cancel Reason Codes

Additional Things Can Happen When An Order Is Completed

New Premises and Accounts Are Only Created if an Order is Completed

Premise Geographic Types Are Populated In An Unusual Way

Account And Premise Usage Are Controlled By The Campaign

Order versus Start / Stop

There are two different ways to start service for a customer:

- As described under definitions, you can use the order transaction to start service.

- Alternatively, you can use start / stop.

The following table provides insight into the pros and cons of each method (after this table you will find our recommendations):

Issue

Order

Start / Stop

New customer setup

Information about the new customer can be entered on the order page. A person / account will be setup when the order is completed.

A new person and account must be setup prior to using start / stop. See How To Add A New Customer From Control Central for more information.

New premise setup

Information about the new premise can be entered on the order page. A premise (and service points) will be setup when the order is completed.

A new premise and service point(s) must be setup prior to using start / stop.

Updates to existing customer information

Changes to a customer's existing account and/or person info may be entered on the order page. The related person and/or account will be updated when the order is completed.

Start / stop cannot be used to update person or account information. Rather, you must transfer to the person or account page and make the necessary changes.

Incomplete orders

The order transaction allows you to record customer information and hold it without starting service. The customer can call back in the future and you can continue where you left off.

You cannot leave a start half-finished - you either have to complete the start or cancel it.

Stop current service, start new service

The order transaction does not currently provide a mechanism for stopping service (it can only be used to start service).

Start / stop can be used to stop a customer's current service and start new service.

Automatic versus manual start option selection (start options are used to default a great deal of information onto a service agreement)

If a customer selects a package, the system creates service agreements using the start options defined in the package (i.e., you do not have to select a start option for each service agreement that's created).

When you start service, you must define the specific start option for each service agreement created (actually, you only have to do this for those types of service agreements that use start options).

Starting premise and non-premise oriented services

If a customer selects a package, the system can create both premise and non-premise oriented service agreements. For example, when a package is selected, the system can create electric, gas, deposit, and charitable contribution SA's (based on the information defined on the package).

Multiple premise-oriented service agreements can be created in one interaction. However, a separate interaction is required for each non-premise oriented service agreement.

Changes after completion

An order cannot be modified after it is completed. Any changes (cancellations prior to starting service, changes of the start date, etc.) must be performed using the start / stop transaction.

The start / stop transaction allows you to cancel and make changes to pending start service agreements.

Field activity visibility

After an order is completed, the user is transferred to control central where field activities associated with the premise can be seen in trees and context zones.

All field activities associated with all premises associated with all pending starts / stops are shown on the start / stop transaction.

Address changes

Address changes entered on the order transaction are applied when an order is completed (i.e., when a package is selected). They are not held awaiting service agreement activation.

When you enter an address change on the start / stop transaction, this address changed is saved until the first pending start or stop is activated. This means that the address change is effectively held until the start / stop is activated.

Based on the above, we'd recommend the following:

- If your organization has well-defined service locations (i.e., premises) AND a premise's service point type controls the types of services offered to the customer, you should probably only use the order transaction to setup new customer information. The new service agreements should be setup using start / stop. See Prelude To Start/Stop for more information.

- In all other situations, we'd recommend using the order transaction to start service. If customers typically stop and start service in tandem, we'd recommend the following steps:

- Stop the customers existing service using start / stop.

- Return to Control Central - Account Info and select the appropriate campaign from the appropriate portal zone. Keep in mind that the portal zones displayed on this page are based on the user's preferences and security profile. Therefore this zone may not be available to all users.

- When you select the appropriate campaign, you'll be transferred to the order transaction where you can start the desired package for the customer.

Orders Cannot Be Changed After They Are Completed

The Lifecycle of an Order indicates that once an order is complete , it cannot become pending again. In addition to this rule, we'd like to stress that once an order is complete , you cannot make any changes to the order except to add new log entries.

Premise and SP Characteristics May Be Populated From Postal Defaults

If you specify a new premise on the order transaction and you complete the order, a new premise will be created. This premise's characteristics can be populated from two different sources:

- You could have designed the campaign to have its orders capture premise characteristics. You do this by adding miscellaneous fields to the campaign that are premise characteristics.

- You could have set up postal defaults for the premise's country and postal code.

If a given characteristic is referenced on both of the above, the characteristic value on the campaign is used as the premise's characteristic value.

As described above, service points may be created when a package is selected (it depends on the SA to Create algorithm that you've used on the selected package). The base package algorithms that create a new service point when a package is selected will populate the service point's characteristics using the information on the postal defaults (if specified). Refer to STRM-VT for an example of this type of SA to create algorithm.

To Do List Processing

In the base package, there are two To Do lists that may be affected by orders:

- Highlight pending orders. This To Do list contains orders that are in the pending state. Refer to Pending To Do Entries for more information about this To Do list.

- Highlight held orders. This To Do list contains orders that are in the held state. Refer to Held To Do Entries for more information about this To Do list. Refer to Order - Hold Dialog for more information about holding orders.

Hold and Cancel Reason Codes

In Lifecycle of an Order, we illustrated how a user can hold a pending order. Before a user can hold an order, they must supply an Order Hold Reason .

The same is true if a user wants to cancel a pending or held order (i.e., they must supply a Order Cancellation Reason).

These reason codes are purely for audit purposes.

Additional Things Can Happen When An Order Is Completed

An optional plug-in spot exists on customer class where you can introduce additional logic to be executed when an order is completed for an account that belongs to this customer class.

Another optional plug-in spot exists on campaign where you can introduce additional logic to be executed when an order is completed for the campaign.

New Premises and Accounts Are Only Created if an Order is Completed

It's important to understand that a premise and account are only created when an order is completed . This means you can explore alternatives with a prospect who resides at a new premise without introducing the premise / account. However, the system creates a person if you save an order so that an audit of the customer interaction exists in the system.

Premise Geographic Types Are Populated In An Unusual Way

A premise's geographic ID's are used by Control Central when you look for a customer / premise using geographic identifiers.

Note:

Geographic coordinates are optional. An installation option controls whether at least one geographic coordinate is required on every premise.

The following points describe how the geographic ID's are populated on premises that are created when an order is completed:

- If a postal default exists for the new premise's country / postal code, any geographic identifiers on the postal default are copied onto the new premise.

- If a postal default hasn't been setup for the new premise's country / postal code, the premise will have a single geographic identifier. It is constructed as follows:

- The geographic type is defaulted from the campaign.

- The geographic value is set to ***.

Note:

Potential error. If neither the campaign nor the postal defaults results in a geographic type AND the installation record indicates at least one geographic type is required on a premise, an error is generated explaining that either postal defaults or the campaign should be populated with default geographic information.

Account And Premise Usage Are Controlled By The Campaign

When you set up a campaign, you define how the campaign's orders use accounts and premises. Refer to the description of Account Usage and Premise Usage under Campaign - Main for more information.

Maintaining Orders

The order transaction can be used to satisfy many diverse requirements. For example, you can use an order to:

- Enroll new customers using a single transaction (i.e., you don't have to use the person, premise, service point, and start / stop transactions to enroll a new customer who resides at a new premise).

- Sell new products to existing customers.

- Update existing person, account and premise information using a single transaction.

- Market your services to prospects uploaded from a marketing list (and measure the success of your efforts). If the customer responds to your sales efforts, the system will automatically setup the customer, premise and related service agreements.

- Setup marketing surveys and record your customers' responses.

- Quickly create one-time charges.

- Set up proposals for prospective services (and then send a quotation to the customer for these services).

- And more...

The topics in this section describe the order transaction. Refer to The Big Picture of Campaigns, Packages and Orders for general information about orders.

Contents

Lifecycle of an Order

Order User Interface Flow

Order - Main

Order - Questions & Misc. Fields

Order - Log

Order - Package Confirmation

Order - Hold Dialog

Order - Cancel Dialog

Lifecycle of an Order

The following diagram illustrates the lifecycle of an order.

Pending An order starts its life in the Pending state. An order remains in this state until you Cancel , Complete or Hold it.

Held You Hold an order when you want to save an order pending future information. For example, you would hold an order if you need to perform research on the perfect rate for the customer before completing the order. A Held order can be Completed or Canceled .

Complete When a customer selects a package of goods and services, the "V" is updated, service agreements are initiated, and the order becomes Complete . No changes may be made to a Complete order.

Canceled A Pending or Held order may be Canceled .

Order User Interface Flow

The diagram that appears below illustrates the anticipated navigation path used to process an order.

Warning:

An order's campaign controls many aspects of the user interface flow. The illustration that appears below is a sample of what's possible; it may not mirror how your team has setup your company's campaigns.

Order - Main

This page is used to define demographic and geographic information about the customer / prospect.

Fastpath:

Refer to The Big Picture of Campaigns, Packages and Orders for more information about orders.

Open this page using Sales & Marketing, Order.

Fastpath:

Refer to Order User Interface Flow for information about how to use this page.

Description of Page

Order contains a concatenation of the customer's name, campaign, package (if the order is completed), status and start date. Order ID is the system-assigned unique identifier of the order. These values only appear after the order is added to the database.

Status contains the state of the order. Refer to Lifecycle of an Order for information about the valid values and the state transition rules. Additional information may also be displayed based on the status:

- If the order's status is Held , the following information is also displayed: the hold reason, the name of the user who held the order, and the date and time when a reminder for the order is due to be created.

- If the order's status is Canceled , the following information is also displayed: the cancel reason, the name of the user who canceled the order, and the date and time when the order was canceled.

- If the order's status is Complete , the following information is also displayed: the name of the user who completed the order and the date and time when the order was completed.

Press the Hold button to hold a Pending order. Refer to Order - Hold Dialog for a description of the pop-up window used to hold an order.

Press the Cancel button to cancel a Pending or Held order. Refer to Order - Cancel Dialog for a description of the pop-up window used to cancel an order.

If the Campaign has been setup to allow the completion of orders without selecting a package, a button appears to the right of Cancel. The label that appears in the button is defined on the Campaign. When pressed, the order is completed. When the order is completed,

- The "V" is setup / updated.

- All questions and miscellaneous fields (defined on the next tab) are posted to the appropriate object.

- Optional plug-ins are executed.

- You will be transferred to the order completion transaction that's defined on the Campaign (if any).

If the order references an existing person, account, or premise and the related person / account / premise has changed after their information was snapshot on the order, the Out of Sync section appears. This section highlights which objects have changed since the order was last saved. In addition, the Sync button appears. When pressed, the order is updated with the current field values for these objects.

An order's Campaign controls many aspects of the order's behavior. For example, it controls:

- The type of information defaulted onto an order.

- The eligibility-oriented questions that are displayed on the next tab.

- The superset of packages that can be offered to a customer.

- In addition to the above, campaigns also control high-level eligibility rules and business process flows.

An order's Campaign is defaulted as follows:

- When you select a customer on Control Central - Main, you are automatically transferred to the Account Information portal. One of the zones on this portal page contains the campaigns that can be offered to the customer. If you select a campaign from this zone, you are transferred to the Order transaction with the respective Campaign defaulted. Note, the Applicable Campaigns zone only appears if the CSR has modified their preferences to display this zone.

- In all other situations, the order's campaign defaults from the Installation Record.

You may change an order's Campaign at will. Note that changing the campaign will result in the Questions & Misc Fields (the next tab) being refreshed with values associated with the new campaign. However, other values typically defaulted from the campaign (such as default customer class) do not get refreshed so that data you may have entered does not get overwritten.

Start Date defines the date on which service will start. This date becomes the start date on service agreements created when this order is completed. If you need to change the start date on these service agreements, transfer to Start/Stop (where all of the pending start service agreements will appear).

The topics that follow describe the remaining sections on this page

Contents

Order - Main - Person Information

Order - Main - Service Address

Order - Main - Account Information

Order - Main - Person Information

The Person Information section contains demographic information about the customer / prospect.

Warning:

This page contains a subset of person-oriented information. If you need to define other person-oriented information, transfer to Person - Main after the order is completed.

If this is a new customer, select Create New Person and enter demographic information in the fields that follow. Otherwise, select Use Existing Person and use the Name field or press the search button to find the customer. After you select an existing person, the following events takes place:

- The person's name appears beneath the person search (and the person context menu can now be used to drill down to person-oriented pages). 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.

- If any of the Questions & Misc Fields (on the next tab) are used to capture person-oriented characteristics, the person's existing characteristic values are defaulted.

- If the selected person has at least one account, information about the account is displayed in the Account Information section (if the Campaign makes uses of accounts). In addition, if any of the Questions & Misc Fields (the next tab) are used to capture account-oriented characteristics, the account's existing characteristic values are populated in the respective rows on this tab.

- Information about the person is displayed in the fields that follow.

Use Person/Business to indicate if the customer is a Person or a Business . This value controls how the person's primary name is validated. Note, for new customers, this value defaults based on the Campaign.

Names are used by Control Central when you look for a customer based on their name. In addition, a person's primary name is the addressee on the person's bill unless overridden by the Override Mailing Name (defined on Person - Correspondence Information ). To modify a name, simply move to a field and change its value. To add a new name, press + to insert a row, then fill in the information for each field. 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.

- 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 RepresentationName Type 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.

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.

Phone numbers are used by Control Central to look for accounts and persons. For new customers, the phone type(s) default based on the Campaign. To modify a telephone number, simply move to a field and change its value. To add a new telephone number, press + to insert a row, then fill in the information for each field. 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. You can also have this plug-in convert input values into formatted values, e.g., this algorithm could transform all numbers into a formatted string. 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 has several uses:

- It is used by Control Central when you look for a customer / premise based on their ID.

- It is used to highlight potential duplicate persons.

- Control Central displays a person's primary identification in the search results area to help a user identify the customer when multiple customers match the search criteria.

The person ID usage flag on the installation record indicates whether or not at least one id for a person is required or optional . The ID Type defaults from the installation record based on the Person Type ( Person versus Business ). The following fields are used to define a customer's primary ID.

- Indicate the type of identification in the drop down.

- 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 a person 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.

A person can have many forms of identification. The order transaction only caters for a single form of ID (as this is the most typical situation). If you want to specify additional person ID's, you must transfer to Person - Main after the person is created (persons are created when the order is saved).

Specify the customer's Email ID (if any).

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 Customer Language for more information on options for supporting multiple languages for your customers.

Use Life Support / Sensitive Load to indicate if the person has life support or sensitive load equipment. Valid values are: LS/SL (i.e., the person has life support / sensitive load equipment), None . If the customer has Life Support / Sensitive Load equipment, indicate such in the adjacent comment field.

Note:

A premise can also have life support / sensitive load information. If the equipment is physically linked to the premise (e.g., a hospital has life support equipment), you should NOT specify the life support information on the person. Rather, after the premise is added, transfer to Premise - Misc and specify life support information on the premise.

Life support affects alerts and C&C. If life support / sensitive load information is specified, an alert will appear when the person is displayed on control central. In addition, if a person has life support or sensitive load equipment, it is possible for a different credit & collection severance process to be kicked off if the person's account associated has overdue debt. Refer to Designing Your Severance Procedures for more information.

Order - Main - Service Address

The Service Address section contains geographic information about the service address:

Warning:

This page contains a subset of premise-oriented information. If you need to define other premise-oriented information, transfer to Premise - Main after the order is completed.

Whether or not a premise is required or even allowed on an order is controlled by an option on the Campaign. If the Campaign disallows the use of a premise, this section will be suppressed. If the Campaign allows the use of a premise, an indication of whether a premise is optional or required is displayed adjacent to Service Address.

If a premise is allowed on the order, use the dropdown at the top of this section to tell the system about this order's premise:

- Select No Premise Information if you do not want to associate a premise with this order (e.g., for a one-time charge).

- Select Create New Premise if this is a new premise. You should enter the new premise's address in the remaining fields in this section.

- Select Use Existing Premise if an existing premise should be used on the order. Use the Address and City fields or press the search button to find the premise. Refer to Control Central - Search Facilities for suggestions in respect of how to use these fields. After you select an existing premise, the following events takes place:

- The premise's description appears beneath the premise search fields (and the premise context menu can now be used to drill down to premise-oriented pages).

- If any of the Questions & Misc Fields (the next tab) are used to capture premise-oriented characteristics, the premise's existing characteristic values are defaulted.

- Information about the premise is displayed in the fields that follow.

Use Premise Type to describe the type of service location.

The address's constituent fields vary based on the Country. Please refer to the Country page for more information.

Populate Trend Area if the Postal is blank. The Postal and the Trend Area cannot both be blank as the Trend Area is a required field on the premise and its value is typically defaulted from postal defaults.

Note:

Default note. The values of several fields on this and the next page default based on the Country and the Postal Code. Refer to Setting Up Premise & Service Point Postal Defaults for more information. Also note, there are several premise-oriented fields that do not appear on this transaction that will be populated on the premise based on the Country and Postal Code (e.g., characteristics, time zone, trend area, geo ID's).

Use CIS Division to define the jurisdiction in which the premise is located.

Order - Main - Account Information

The Account Information section contains account-oriented information.

Warning:

This page contains a subset of account-oriented information. If you need to define other account-oriented information, transfer to Account - Main after the order is completed.

Whether or not an account is required or even allowed on an order is controlled by an option on the Campaign. If the Campaign disallows the use of an account, this section will be suppressed. If the Campaign allows the use of an account, an indication of whether an account is optional or required is displayed adjacent to Account Information.

If an account is allowed on the order, use the dropdown at the top of this section to tell the system about this order's account:

- Select No Account Information if you do not want to associate an account with this order (e.g., for a person-oriented marketing survey).

- Select Create New Account if this is a new account. You should enter the new account's information in the remaining fields in this section.

- Select Use Existing Account if an existing account should be used on the order. If an existing person was selected above, one of the person's accounts (if any) will be automatically displayed in the Account Information. In addition, if the order references an existing person, the account search will be limited to accounts associated with this person. If an Existing Account is selected, the following takes place:

- Basic information about the account appears beneath the search area (and the account context menu can now be used to drill down to account-oriented pages).

- If any of the Questions & Misc Fields on the next tab are used to capture account-oriented characteristics, the account's existing characteristic values are defaulted.

- Information about the account is displayed in the fields that follow.

Customer Class plays a part in:

- If and when a customer is subject to late payment charges.

- The account's default collection class and when the account debt monitor reviews an account. Refer to The Big Picture of Credit & Collections for more information about how and when an account's debt is reviewed.

- And several other functions. Refer to and Setting Up Customer Classes for more information.

Note:

Default note. For new accounts, Customer Class defaults based on the Campaign.

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.

Note:

Default note. For new accounts, Management Group defaults based on the Campaign.

The remaining fields are used to describe how the bill should be routed to the customer.

Warning:

When an order is completed, several fields that do not appear on this page that reside on Account - Person are populated. For example, Account Relationship Type, Bill Format, Number of Copies, Receives Notification are all populated with default values. If you need to override the default values, transfer to Account - Person after the account is added.

Use Bill Route Type to define how the bill is sent to the customer. This field's value defaults from the Installation Record. This value is important as it controls many options on the remainder of this page. If the Bill Route Type 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 indicates that bills are routed via Email, the person's Email addressis displayed adjacent. If the Bill Route Type indicates that bills are routed via the Postal service, you must choose an appropriate Bill Address Source to define which address should be used. Refer to Setting Up Bill Route Types for more information about bill route types.

If the Bill Route Type indicates that bills are routed via the Postal service, you must choose the appropriate Bill Address Source to define which address should be used. This field will be protected for other Bill Route Types.

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

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

- Choose Account Override if bills 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 bills should be sent to a different address.

If you select a Bill Address Source of Account Override , you must enter the address to which bills will be sent in the following address constituents. The number and type of address constituents is based on the Country (refer to Defining Countries for more information on address constituents). These fields will be protected for other Bill Address Sources. Note, the Country defaults from Installation Options - System and several other constituents default based on the Country and Postal Code if a Postal Default exists for the postal code.

Order - Questions & Misc. Fields

This page has several purposes:

- The order's Campaign can define questions to be posed to customers when an order is taken. For example, you could ask the customer "marketing survey" questions (e.g., please rate our service, how do you heat your home?, etc.). This page allows you to capture the customer's response.

- The order's Campaign can also be setup to capture additional fields to be updated on the order's person / account / premise when the order is completed. For example, you could indicate that the account's override due date and automatic payment options should be captured when an order is taken. This page allows you to capture these field values.

- The order's Campaign can also be setup to pose eligibility-oriented questions that qualify the customer for packages of goods and services. For example, you might have a campaign with packages that can only be selected if the customer commits to a year's worth of service. This page allows you capture the customer's response to these types of questions.

- After entering the above information (and the information on the Main page), you can use this page to select a package of goods and services for the customer.

- You can use this page to switch the campaign on the order (which would result in new questions and miscellaneous fields appearing).

Fastpath:

Refer to The Big Picture of Campaigns, Packages and Orders for more information.

Open this page using Sales & Marketing, Order and then navigate to the Questions & Misc Fields tab.

Fastpath:

Refer to Order User Interface Flow for information about how to use this page.

Description of Page

Order contains a concatenation of the customer's name, campaign, package (if the order is completed), status and start date. Order ID is the system-assigned unique identifier of the order. These values only appear after the order is added to the database.

Status contains the state of the order. Refer to Lifecycle of an Order for information about the valid values and the state transition rules. Additional information may also be displayed based on the status:

- If the order's status is Held , the following information is also displayed: the hold reason, the name of the user who held the order, and the date and time when a reminder for the order is due to be created.

- If the order's status is Canceled , the following information is also displayed: the cancel reason, the name of the user who canceled the order, and the date and time when the order was canceled.

- If the order's status is Complete , the following information is also displayed: the name of the user who completed the order and the date and time when the order was completed.

Press the Hold button to hold a Pending order. Refer to Order - Hold Dialog for a description of the pop-up window used to hold an order.

Press the Cancel button to cancel a Pending or Held order. Refer to Order - Cancel Dialog for a description of the pop-up window used to cancel an order.

If the Campaign has been setup to allow the completion of orders without selecting a package, a button appears to the right of Cancel. The label that appears in the button is defined on the Campaign. When pressed, the order is completed. When the order is completed,

- The "V" is setup / updated.

- All questions and miscellaneous fields (defined on the next tab) are posted to the appropriate object.

- Optional plug-ins are executed.

- You will be transferred to the order completion transaction that's defined on the Campaign (if any).

If the order references an existing person, account, or premise and the related person / account / premise has changed after their information was snapshot on the order, the Out of Sync section appears. This section highlights which objects have changed since the order was last saved. In addition, the Sync button appears. When pressed, the order is updated with the current field values for these objects.

The number and type of Questions & Misc Fields is controlled by the Campaign.

Note:

Some questions can be suppressed. The campaign contains an indication if each question is account-oriented, person-oriented, premise-oriented or order-oriented. If the question is account-oriented and no account is defined on the Main tab, the question will be suppressed. If the question is premise-oriented and no premise is defined on the Main tab, the question will be suppressed.

Each row in this grid has a Prompt and a Response. The value of each Prompt is defined on the Campaign. The Response holds the answer supplied by the customer. Please note the following about the Response field:

- On a Campaign, you can indicate which questions / miscellaneous fields are required. The Response for a required field is prefixed with an asterisk - * .

- The value of a Response can default from a variety of sources:

- If an existing person was selected on the Main page AND the response is used to capture a person characteristic, the existing characteristic value will be defaulted.

- If an existing premise was selected on the Main page AND the response is used to capture a premise characteristic, the existing characteristic value will be defaulted. If no value exists, the characteristic values will default based on the postal defaults associated with the service address's Country and Postal Code.

- If an existing account was selected on the Main page AND the response is used to capture an account characteristic, the existing characteristic value will be defaulted.

- Otherwise, the characteristic value is defaulted from the Campaign.

- The type of field used to capture a Response is controlled by the Campaign. Depending on the type of Response you may see Go To buttons and Search buttons.

After entering the Responses to the Questions & Misc Fields, press the Show Eligibility button.

The following may occur when this button is pressed:

- If a new customer is specified on the Main page, a warning will advise you that a new person will be added. The system needs to add a new person so that an audit of the customer interaction exists.

- The tree expands to show the Order - Eligibility Tree containing package, ineligible package, error package, and other campaign nodes:

- Each Package node contains a package that is linked to the campaign whose Eligibility Criteria allows its selection by the customer. You can expand this node to see the various service agreements that will be created if you select the package. Selecting one of these packages causes the Order - Package Confirmation page to appear in which you can confirm your selection.

- The Ineligible Package(s) node contains packages whose Eligibility Criteria prevents their selection by the customer.

- The Error Packages node contains packages whose Eligibility Criteria have returned errors (if any).

- The other campaign(s) node contains alternative campaigns that may be substituted for the current campaign on the package. Selecting one of these campaigns will cause the campaign to be changed on this order. Changing a campaign on an order will result in new questions and miscellaneous fields appearing. Refer to The Big Picture Of Campaign Eligibility for more information.

Note:

Some nodes can be suppressed. To increase page performance with large campaigns, you can define a feature configuration to suppress the display of the Ineligible Packages, Error Packages or Other Campaign nodes. If a node is suppressed, it does not appear on the eligibility tree and the system does process the information necessary to display the node.

Order - Log

This page contains an audit trail of significant events that transpired in the history of this order.

Open this page using Sales & Marketing, Order and then navigate to the Log tab.

Description of Page

Order contains a concatenation of the customer's name, campaign, package (if the order is completed), status and start date. Order ID is the system-assigned unique identifier of the order. These values only appear after the order is added to the database.

Status contains the state of the order. Refer to Lifecycle of an Order for information about the valid values and the state transition rules. Additional information may also be displayed based on the status:

- If the order's status is Held , the following information is also displayed: the hold reason, the name of the user who held the order, and the date and time when a reminder for the order is due to be created.

- If the order's status is Canceled , the following information is also displayed: the cancel reason, the name of the user who canceled the order, and the date and time when the order was canceled.

- If the order's status is Complete , the following information is also displayed: the name of the user who completed the order and the date and time when the order was completed.

Press the Hold button to hold a Pending order. Refer to Order - Hold Dialog for a description of the pop-up window used to hold an order.

Press the Cancel button to cancel a Pending or Held order. Refer to Order - Cancel Dialog for a description of the pop-up window used to cancel an order.

Campaign contains basic information about the order's campaign.

Package only appears if the order has been completed. It contains basic information about the package.

Start Date contains the date on which the service agreement's created by the order will be started.

The Log contains an audit trail of significant events that transpired in the history of this order. There are two types of entries in the log:

- The system automatically adds log entries when key events occur. These entries may not be removed or changed.

- Users may add log entries by pressing the + button and then specifying the Details.

Order - Package Confirmation

The Package Confirmation page allows you to check the package you selected before the V is created / updated for the customer. This page opens when you select a package from the eligibility tree on Order - Questions & Misc Fields.

Warning:

If you press the Complete button, a variety of objects may be created (service agreements, service points, a premise, an account, field activities, etc.). If you need to change any of these objects after order completion, you must transfer to the respective page on which the object is maintained. You can also use Start / Stop to make changes to the service agreements created by this transaction.

Description of Page

Order contains a concatenation of basic information about the order. Order ID is the system-assigned unique identifier of the order. These values only appear after the order is added to the database.

Campaign contains basic information about the order's campaign.

Package contains basic information about the package.

Premise is the address at which service will be delivered.

Person is the name of the customer.

Account is the name of the customer and their customer class.

Start Date contains the date on which the service agreement's created by the order will be started.

The Questions & Misc Fields grid contains the questions and miscellaneous fields that appeared on the order. Note well, it is possible to design a campaign and a package where some fields are optional on the campaign but required for a specific package. The Response of all required fields for the selected package are prefixed with an asterisk. Refer to Order - Questions & Misc Fields for information about the rows in this grid.

Note:

Changing your answers could cause the package to become ineligible. As described earlier, the fields you enter on an order play are what the system uses to determine if a package can be selected for a customer. If you change the answers to the Questions & Misc Fields, the package may no longer be eligible and an error will be presented to you. You will have the choice of reverting to the original answers or returning to the order page where you can select an eligible package.

Additional questions / misc fields are possible. It is possible to design a campaign where certain field values are only visible on specific packages. In this scenario, the Questions & Misc Fields grid may contain additional rows for a given package. Refer to Designing Campaigns and Packages for more information.

The Instructions grid contains package-specific suggestions. These instructions are defined on the package.

The Messages grid contains system-generated messages that summarize what will happen if you press the Complete button.

Press the Complete Order button if you are satisfied with the information on the order. Otherwise, press Do Not Use this Package to change or cancel the order.

Order - Hold Dialog

The Order - Hold dialog opens if you press the Hold button on the order transaction. You use it to define why the order is being held and when you want to be reminded to check up on the order.

Description of Page

Use Hold Reason to define why the order is being held.

The following fields are used to control the To Do entry that will be created to remind you about this order.

- Use Reminder Date / Time 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 (known by the batch control ID of TD-ECBK ) 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 Reminder Date that the To Do entry should be created.

- 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. Note, the To Do Role will default from the order's campaign.

- 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 in To Do User.

- Log Notes are used to describe why the order is being held. This information appears in the log entry that is created by the system when you hold an order.

If there are any To Do entries (with a status of Open or Being Worked On ) that drill down to this order, a message is displayed indicating that existing To Do entries for this order will be completed. If the order is already in Hold status, existing To Do entries are completed when you click the OK button and a new To Do entry is created when the background process responsible for creating the To Do entries runs.

Order - Cancel Dialog

The Order - Cancel dialog opens if you press the Cancel button on the order transaction. You use it to define why the order is being canceled.

Description of Page

Use Cancel Reason to define why the order is being canceled.

Use Log Notes to describe why the order is being canceled. This information appears in the log entry that is created by the system when you cancel an order.

Maintaining Campaigns

When you add an order, you must reference its campaign. An order's campaign controls:

- The type of information defaulted onto an order. For example, you can setup a campaign to default a given account management group on all orders linked to this campaign. This account management group will then default onto accounts created when the campaign's orders are completed.

- The eligibility-oriented questions that are posed to the customer when an order is taken. For example, the questions indicated above - Who is your current energy service provider? / Would you like to pay automatically? / What is your date of birth? - are all defined on the order's campaign.

- The superset of packages that can be offered to a customer whose order references this campaign. An order's campaign defines the types of packages that may be selected.

- In addition to the above, campaigns also control high-level eligibility rules and business process flows.

The topics in this section describe the campaign transaction.

Fastpath:

Refer to The Big Picture of Campaigns, Packages and Orders for general information about campaigns. Refer to The Big Picture Of Campaign Eligibility Rules for a discussion of how to control which campaigns can be used for different types of customers. Refer to Designing Campaigns and Packages for guidelines describing how to design your campaigns.

Contents

Lifecycle of a Campaign

Campaign - Main

Campaign - Questions and Misc. Fields

Campaign - Algorithm

Campaign - Package

Lifecycle of a Campaign

The following diagram illustrates the lifecycle of a campaign.

Active An Active campaign may have orders created in respect of it.

Inactive By Inactivating the campaign, you are preventing it from being used on future orders. In addition, Inactive campaigns do not appear in the Applicable Campaigns zone.

Campaign - Main

This page is used to define basic information about a campaign.

Fastpath:

Refer to The Big Picture of Campaigns, Packages and Orders and Designing Campaigns and Packages for more information.

Open this page using Sales & Marketing, Campaign.

Description of Page

Campaign is the user-defined code that uniquely identifies the campaign. The campaign's description appears adjacent.

Description briefly describes the campaign.

Campaign Status describes the state of the campaign. Refer to Lifecycle of a Campaign for more information.

The following fields contain values to be defaulted onto this campaign's orders. The user who takes the order may override these default values. Note well, these default values are only applicable for new persons - they will not override field values defined on existing persons.

- The system requires all persons to be defined as either a Person or a Business . Use Default Person / Business to define the default value for persons created by this campaign's orders.

- Every phone number defined for a person must reference a phone type. Use Default Phone Type 1 and Default Phone Type 2 to define the first two phone types defaults for persons created by this campaign's orders.

Premise Usage controls if and how this campaign's orders use premises. You have the following options:

- Select Not Allowed if this campaign's orders do not reference a premise.

- Select Optional if this campaign's orders do not have to reference a premise. This option also means that a new OR existing premise may be specified on the order. Note, if an order references a new premise, the premise will be created when the order is completed.

- Select Optional - Existing Premise Only if this campaign's orders do not have to reference a premise. This option also means that only an existing premise may be specified on an order.

- Select Required if this campaign's orders must reference a premise. This option also means that a new OR existing premise may be specified on the order. Note, if an order references a new premise, the premise will be created when the order is completed.

- Select Required - Existing Premise Only if this campaign's orders must reference a premise. This option also means that only an existing premise may be specified on an order.

The following fields contain values to be defaulted onto this campaign's orders. The user who takes the order may override these default values. Note well, these default values are only applicable for new premises - they will not override field values defined on existing premises.

- The system requires all premises to reference a premise type. Use Default Premise Type to define the default value for premises created by this campaign's orders.

- Every geographic ID defined for a premise must reference a geographic type . Use Default Premise Geo Type to define the default value for premises created by this campaign's orders. Refer to Premise Geographic Types Are Populated In An Unusual Way.

Account Usage controls if and how this campaign's orders use accounts. You have the following options:

- Select Not Allowed if this campaign's orders do not reference an account.

- Select Optional if this campaign's orders do not have to reference an account. This option also means that a new OR existing account may be specified on the order. Note, if an order references a new account, the account will be created when the order is completed.

- Select Optional - Existing Account Only if this campaign's orders do not have to reference an account. This option also means that only an existing account may be specified on an order.

- Select Required if this campaign's orders must reference an account. This option also means that a new OR existing account may be specified on the order. Note, if an order references a new account, the account will be created when the order is completed.

- Select Required - Existing Account Only if this campaign's orders must reference an account. This option also means that only an existing account may be specified on an order.

The following fields contain values to be defaulted onto this campaign's orders. The user who takes the order may override these default values. Note well, these default values are only applicable for new accounts - they will not override field values defined on existing accounts.

- The system requires all accounts to belong to a customer class. Use Default Customer Class to define the default value for accounts created by this campaign's orders.

- An account may reference an account management group. Use Default Acct Management Group to define the default value for accounts created by this campaign's orders.

If a user holds one of the campaign's orders, they can have a To Do entry generated on a future date to remind them about the order. Use Default Hold To Do Role to define the group of users to whom the To Do entry will be sent. Note well, the user who holds an order can indicate that the related To Do entry should be addressed to a specific user ID rather than a Role.

Use Order Open Option to define the tab page that is displayed when a user adds a new order for this campaign. This field is only relevant when the order transaction is invoked in "add mode" and a campaign is passed to this transaction (e.g., if a user adds an order from the Applicable Campaigns Zone).

A user can be automatically transferred to a different transaction when they complete an order. Refer to Supported Business Processes for examples of transactions that we anticipate being used. Use Navigation Option to define this transaction. Note,

- Leave Navigation Option blank if the user should remain on the order transaction after completion.

- You can setup Navigation Options to transfer to the user to a tab other than the main tab.

If a user is allowed to complete this campaign's order's without selecting a package,

- Turn on Allow Order Compl w/o Package and

- Use Order Compl w/o Package Label to define the message to appear in the button used to complete such orders.

Fastpath:

Refer to Campaigns Without Packages for examples of campaigns where you would enable the above fields.

Use Long Description to provide an overview of this campaign.

The grid at the bottom of the page summarizes this campaign's questions and miscellaneous fields. To change this information, press the adjacent go to button (which will transfer you to the Questions and Misc Fields tab). To add additional information, transfer to the Questions and Misc Fields tab and press the + button.

Campaign - Questions and Misc. Fields

This page is used to define the following type of information:

- An order's campaign can define questions to be posed to customers when an order is taken. For example, you could ask the customer "marketing survey" questions (e.g., please rate our service, how do you heat your home?, etc.).

- An order's campaign can also be setup to capture additional fields to be updated on the order's person / account / premise when the order is completed. For example, you could indicate that the account's override due date and automatic payment options should be captured when an order is taken.

- An order's campaign can also be setup to pose eligibility-oriented questions that qualify the customer for packages of goods and services. For example, you might have a campaign with packages that can only be selected if the customer commits to a year's worth of service.

Fastpath:

Refer to Designing Campaigns and Packages for information describing how to design this type of information for your campaigns.

Open this page using Sales & Marketing, Campaign and navigate to the Question & Misc Fields tab.

Description of Page

Warning:

This information is not intuitive; we strongly recommend that you follow the guidelines under Designing Campaigns and Packages before attempting to enter this information.

Campaign is the user-defined code that uniquely identifies the campaign. The campaign's description appears adjacent.

The Questions & Misc Fields scroll contains one row for each question / miscellaneous field captured on this campaign's orders. The following fields are used:

- Prompt on Order contains the prompt that is shown to the user when the order is taken. Refer to Determine The Properties Of Every Miscellaneous Field for examples.

- Brief Description is simply a brief description of the question / miscellaneous field.

- Sort Sequence controls the order in which the question appears on the order.

- Applicability controls whether the field is Optional , Required , or Only Applicable on Package .

- A value of Required means the order taker must enter a valid value before packages are displayed for selection.

- A value of Optional means the order taken can leave the field blank prior to package selection. You can make an Optional field Required on individual packages.

- A value of Only Applicable on Package is used for fields that are only captured for specific packages. Fields of this type are suppressed prior to package selection. When you setup a package, you indicate if the field is applicable (if so, the user is only prompted for the field if the package is selected).

- Type of Response controls where the field is stored when the order is completed and how it is validated. You have two options: Characteristic or Column .

- If a field is a Characteristic , you must define which entity the characteristic value is to be stored on when the order is completed ( Person , Account , Premise or Order ). You must also define the Characteristic Type as this controls the characteristic value entered by the user.

- If a field's value resides in a Column (as opposed to a characteristic value), you must define the column reference. A field's Column Reference controls three things:

- How the field's value is retrieved. A field's value is retrieved when an existing person / account / premise is referenced on an order.

- How the field's value is validated. A field's value is validated before package eligibility is determined and before the order is completed.

- How the field's value is posted (i.e., updated on the database). A field's value is posted when an order is completed.

Fastpath:

Refer to Extract Column References From Miscellaneous Fields for more information about column references.

- If a field's value resides in a Column (as opposed to a characteristic value), you must also define whether the question / field is dependent on the order referencing an account or premise. You do this by populating Question Dependency with one of the following values:

- Select Must Have Account if this question / field should only appear if the order references an account (new OR existing).

- Select Must Have Premise if this question / field should only appear if the order references a premise (new OR existing).

- Select No Dependency if this question / field should always appear.

Fastpath:

Refer to Determine Account / Premise Dependencies For Column References for more information.

- Default Column Value / Default Char Value controls whether the order taker is supplied with a default value when an order is created. Note well: for Optional and Only Applicable on Package fields, you can specify a different default value on each package.

Campaign - Algorithm

This page defines plug-in algorithms that are executed for orders associated with this campaign. Open this page using Sales & Marketing, Campaign and navigate to the Algorithm tab.

Description of Page

Campaign is the user-defined code that uniquely identifies the campaign. The campaign's description appears adjacent.

The grid contains Algorithms that control campaign-oriented functions. You must define the following for each plug-in algorithm:

- Specify the System Event with which the algorithm is associated (see the table that follows for a description of all possible events).

- Specify the Sequence and Algorithm for each System Event. You can set the Sequence Number to 10 unless you have a System Event that has multiple Algorithms. In this case, you need to tell the system the Sequence in which they should execute.

You can define algorithms for the following System Events:

System Event

Optional / Required

Description

Campaign Eligibility

Required

A campaign's eligibility algorithms control two things:

- Whether the campaign appears in the Applicable Campaigns Zone. This content zone suggests possible campaigns for the current customer displayed on control central. You might want to use this zone if you have different campaigns that are offered to different types of customers. Refer to Real-time Marketing of Additional Services to a Customer for an example of how this content zone can be used to "up sell" additional services.

- Whether the campaign appears on an order's eligibility tree. Campaigns that appear in this tree are alternate campaigns that may be used on an order. Refer to Real-time Marketing of Services to a Prospect for an example of how an order's eligibility tree can contain alternate campaigns for an order.

Refer to The Big Picture Of Campaign Eligibility for information about these algorithms.

Click here to see the algorithm types available for this system event.

Order Completion

Optional

When an order is completed for this campaign, algorithms plugged into this spot are called to do additional work (e.g., create a customer contact). You need only specify this type of algorithm if you require additional work to be performed when an order is completed for this campaign.

Click here to see the algorithm types available for this system event.

Campaign - Package

A package controls the various types of service agreements that will be created if the customer selects the package. This page summarizes all packages that may be selected on orders associated with this campaign. Open this page using Sales & Marketing, Campaign and navigate to the Package tab.

Description of Page

Campaign is the user-defined code that uniquely identifies the campaign. The campaign's description appears adjacent.

The grid contains an entry for every package associated with this campaign. To view or change a package, press the adjacent go to button (which will transfer you to Package - Main). To add a new package, use the Campaign context menu to transfer to Package - Main in add mode.

Maintaining Packages

After a user enters basic information about a customer on an order, they are shown the various packages that may be offered to the customer. A package controls the various types of service agreements that will be created if the customer selects the package.

If the customer elects to take a package, the system sets up / updates the "V" (along with all of the ancillary things that happen when service is initiated, e.g., field activities are created).

The topics in this section describe the package transaction.

Fastpath:

Refer to The Big Picture of Campaigns, Packages and Orders for general information about packages. Refer to The Big Picture Of Package Eligibility Rules for a discussion of how to control which packages can be used for different types of customers. Refer to Designing Campaigns and Packages for guidelines describing how to design your packages.

Note:

An order can be completed without selecting a package. It is possible to use the order transaction to simply create / update persons and accounts. Refer to Campaigns Without Packages for more information.

Contents

Lifecycle of a Package

Package - Main

Package - SAs To Create

Package - Questions & Misc Fields

Package - Eligibility

Package - Instructions

Lifecycle of a Package

The following diagram illustrates the lifecycle of a package.

Active An Active package may be selected on an order.

Inactive By Inactivating a package, you are preventing it from being selected on future orders.

Package - Main

This page is used to define basic information about a package.

Fastpath:

Refer to The Big Picture of Campaigns, Packages and Orders and Designing Campaigns and Packages for more information.

Open this page using Sales & Marketing, Package.

Description of Page

Package contains a concatenation of basic information about the package. Package ID is the system-assigned unique identifier of the package. These values only appear after the order is added to the database.

Use Campaign to define the campaign to which this package belongs.

Use Description and Long Description to describe the package.

Status defines the state of the package. Refer to Lifecycle of a Package for information about the valid values and the state transition rules.

The tree at the bottom of the page summarizes the information that appears on the remaining tabs. You can click on a hyperlink to transfer you to the appropriate tab with the relevant information displayed.

Package - SAs To Create

This information on this page controls the type of service agreement(s) / service point(s) that are created if this package is selected on an order.

Fastpath:

Refer to The Big Picture of Campaigns, Packages and Orders and Designing Campaigns and Packages for more information.

Open this page using Sales & Marketing, Package and navigate to the SAs To Create tab.

Description of Page

Package contains a concatenation of basic information about the package. Package ID is the system-assigned unique identifier of the package. These values only appear after the order is added to the database.

Warning:

This following information is not intuitive; we strongly recommend that you follow the guidelines under Designing Campaigns and Packages before attempting to enter this information.

The SAs To Create scroll contains one row for every service agreement that will be created if this package is selected on an order. The following fields are used:

- CIS Division and SA Type define the type of service agreement to be created.

- Start Option controls how the system will populate the new service agreement with default values. Refer to start options for more information.

- SP Type defines the type of service point that will be created / reused. Refer to Designing SP Types for more information.

- Start Method Algorithm controls how the system creates the new service agreement and service point. Refer to Determine The Method Used To Create Service Agreements for more information.

- Create Proposal SA controls if the new service agreement is a real or a proposal SA. This switch only appears if the quotation Contract Management module is not turned off. Refer to Proposal Service Agreements Must Exist for more information.

Package - Questions & Misc Fields

It is possible to design a campaign so that the user is prompted for additional information when a package is selected on an order. This page is used to define how the package overrides the questions and miscellaneous fields defined on the campaign.

Fastpath:

Refer to The Big Picture of Campaigns, Packages and Orders and Designing Campaigns and Packages for more information.

Open this page using Sales & Marketing, Package and navigate to the Questions & Misc Fields tab.

Description of Page

Package contains a concatenation of basic information about the package. Package ID is the system-assigned unique identifier of the package. These values only appear after the order is added to the database.

Campaign contains a concatenation of basic information about the campaign.

Warning:

The following information is not intuitive; we strongly recommend that you follow the guidelines under Designing Campaigns and Packages before attempting to enter this information.

The grid contains one row for every Questions & Misc Field defined on the Campaign. You need only modify this information if this package behaves differently than the campaign (e.g., a field is required on the package, but optional on the campaign). To override a field on this package, turn on the Override switch and change the appropriate fields. There are several restrictions in respect of what can be overridden as described below:

- If a question / miscellaneous field is Required on the campaign, no fields may be overridden on the package.

- If a question / miscellaneous field is Optional on the campaign, you may override all field values. However, if the package has been used on a Completed order, you may not change its Applicability to be Required .

- If a question / miscellaneous field is designated as only applicable on package on the campaign, you should designate its applicability as Required , Optional or Not Used On This Package . If the field is either Required or Optional on this package, you may also override the other field values. Please note that if the package has been used on a Completed order, you may not change its Applicability to be Required .

Fastpath:

Please refer to the Description of Page that appears under Campaign - Questions & Misc Fields for a description of the fields on the page.

Package - Eligibility

This page is used to define the conditions under which a package can be selected on an order.

Fastpath:

Refer to The Big Picture Of Package Eligibility and Determine Package Eligibility Rules for more information.

Open this page using Sales & Marketing, Package and navigate to the Eligibility tab.

Description of Page

Package contains a concatenation of basic information about the package. Package ID is the system-assigned unique identifier of the package. These values only appear after the order is added to the database.

Warning:

The following information is not intuitive; we strongly recommend that you follow the guidelines under The Big Picture Of Package Eligibility and Determine Package Eligibility Rules 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 Sequence to control the relative order in which the group is executed when the system determines if the package can be selected on an order (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 Eligible if this package can be selected on the order.

- Choose Ineligible if this package cannot be selected on the order.

- Choose Check Next Group if the next criteria group should be checked.

- 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 Eligible if this package can be selected on the order.

- Choose Ineligible if this package cannot be selected on the order.

- Choose Check Next Group if the next criteria group should be checked.

The grid that follows contains the package'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 customer is eligible for the package if their customer class is residential. 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 Field if you want to compare a response to a question / miscellaneous field to a given value. Push the adjacent search button to select the field.

- Choose Algorithm if you want to compare anything other than a response to a question / miscellaneous field. 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 Type using a logical operator. The following options are available:

- Use > , < , = , >= , <= , <> (not equal) to compare the Criteria Field Type using standard logical operators. Enter the comparison value in the adjacent field.

- Use In to compare the Criteria Field Type 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 Type 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 package will be judged Ineligible or Eligible 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 package will be judged Ineligible or Eligible 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 package will be judged Ineligible or Eligible based on the values defined above in If Group is False and If Group is True.

Package - Instructions

This page is used to define special instructions that should be presented to the user when they select this package. This information appears on the Order - Package Confirmation page.

Fastpath:

Refer to Determine If Additional Instructions Are Needed for more information.

Open this page using Sales & Marketing, Package and navigate to the Instructions tab.

Description of Page

Package contains a concatenation of basic information about the package. Package ID is the system-assigned unique identifier of the package. These values only appear after the order is added to the database.

The grid contains a row for each instruction to be presented to the user when they select a package. The following fields are used:

- Use Sort Sequence to control the relative order of the instruction.

- Use Display Icon to control the icon that prefixes the instruction. Refer to Display Icons for more information.

- Use Description to define the text of the instruction.

The Big Picture of Program Management

The program management functionality satisfies many diverse requirements. For example, you can use this functionality to:

- Market your products and/or services to customers and measure the success of your efforts.

- Encourage customers to enroll in various sales and marketing initiatives. For example, you can use program management to organize a campaign to encourage customers to participate in a conservation program, or to sign up for special contract options.

- Set up marketing surveys and record your customer’s responses.

- Assign representatives to accounts.

- And more…

The topics in this section provide more information about the program management functionality.

Contents

The Big Picture of Initiatives, Leads and Sales Representatives

Maintaining Initiatives

Maintaining Leads

Maintaining Lead Events

Maintaining Sales Representatives

The Big Picture of Initiatives, Leads and Sales Representatives

Three objects are at the heart of the program management functionality: Initiatives, Leads and Sales Representatives.

- An initiative defines a structured campaign that outlines the efforts to encourage customers to participate in a program targeted at a specific market segment.

- A lead is an instance of an initiative for targeted customers.

- A Sales Representative is a user or group of users who can be assigned to follow up on leads and is responsible for selling the initiative’s product or service to the customer.

The topics in this section provide background information about these objects.

Contents

The Big Picture of Initiatives

The Big Picture of Leads

The Big Picture of Sales Representatives

The Big Picture of Initiatives

An initiative defines a structured campaign designed to encourage customers to participate in a program. An initiative can:

- Target a market segment by specifying criteria that must be satisfied before leads are generated for customers.

- Define a structured marketing effort for the events or actions that should take place during the life of a lead to encourage a customer to participate in the program.

- Contain sub-initiatives. Together, an initiative and its subsidiary initiatives form an initiative hierarchy. This supports reporting purposes and the analysis of the success of different market segments and marketing efforts.

Refer to Maintaining Initiatives for more information.

Contents

The Components of an Initiative

The Lifecycle of an Initiative

Initiative Information Can Be Overridden

About Initiative Hierarchies

The Components of an Initiative

The topics in this section provide information about the components of an initiative.

Contents

About Initiative Eligibility Criteria

Examples of Initiative Eligibility Criteria

About Lead Event Type Profile

About the Initiative Log

About Initiative Eligibility Criteria

Each initiative can define its target market by specifying the criteria that must be satisfied before a customer is invited to participate in a program. An initiative may have zero, one or many eligibility criteria. Each customer is subjected to these criteria to determine whether they will have a lead generated for them for the initiative.

Designing these criteria can be easy or time-consuming; it all depends on the complexity of your business rules.

When you set up an eligibility criterion, you must define two things:

- The field to be compared

- The comparison method

For the field to be compared, you can execute an algorithm to:

- Retrieve a field value or values from someplace else in the system (e.g. the customer class or types of services associated with the customer )

- Derive a value based on some data from someplace else in the system (e.g. the number of days since the last lead was created for the customer)

For the comparison method, you can execute an algorithm whose job it will be to perform the comparison on the field to be compared. The result from the algorithm will be TRUE, FALSE, or INSUFFICIENT DATA.

For each criterion, you indicate what the next action will be based on the results from the comparison method. The valid actions could be:

- Customer is eligible

- Customer is not eligible

- Check next condition

Refer to Defining Eligibility Criteria for an Initiative for more information about setting up eligibility criteria on an initiative.

Examples of Initiative Eligibility Criteria

The topics in this section provide examples about how to set up eligibility criteria for an initiative

An Initiative Where All Customers Are Eligible

If an initiative should be targeted at all customers, no eligibility criterion needs to be defined.

An Initiative For Residential Customers

If an initiative should be targeted at residential customers, it would require a simple eligibility criterion that returned an indication of eligible if the customer’s customer class is residential

An Initiative For California, Residential Customers

If an initiative should only be targeted at residential customers in California, it would require two eligibility criteria:

Criteria

Criteria Field Comparison

Retrieve Field Value Algorithm Example

1

Indicate Check Next Condition if customer class is "residential".

Refer to C1-ICGETCC for an example of an algorithm that retrieves the customer class for a customer’s account.

2

Indicate Eligible if CIS Division is "California".

Refer to CI_GETDIV for an example of an algorithm that retrieves the CIS Division for a customer’s account.

An Initiative For California, Residential Customers But Excluding San Francisco and South San Francisco

If an initiative should only be targeted at residential customers in California, but excluding San Francisco and South San Francisco, it would require four eligibility criteria:

Criteria

Criteria Field Comparison

Retrieve Field Value Algorithm Example

1

Indicate Check Next Condition if customer class is "residential".

Refer to C1-ICGETCC for an example of an algorithm that retrieves the customer class for a customer’s account.

2

Indicate Check Next Condition if CIS Division is "California".

Refer to CI_GETDIV for an example of an algorithm that retrieves the CIS Division for a customer’s account.

3

Indicate Check Next Condition if City is not ‘San Francisco’.

Refer to C1-ICGETCITY for an example of an algorithm that retrieves the Cities the account’s service agreements for a customer.

4

Indicate Eligible if City is not ‘South San Francisco’.

Refer to C1-ICGETCITY for an example of an algorithm that retrieves the Cities the account’s service agreements for a customer.

About Lead Event Type Profile

Each initiative can define a structured marketing effort for the events or actions that should take place during the life of a lead to encourage a customer to participate in a program. Each event in a marketing effort is defined by a Lead Event Type. For example, one event could be that a letter or an email is sent to a customer. The collection and sequencing of lead event types defined on an initiative is referred to as the Lead Event Type Profile.

Refer to Creating Initiatives and Maintaining Initiatives for more information on setting up and maintaining the Lead Event Type Profile on an initiative.

About the Initiative Log

Every initiative has a log holding its history. Entries are added to the log when meaningful events occur, for example:

- When an initiative is created.

- When an initiative’s status changes (e.g. transitions to the active, accumulate statistics, inactive states).

- When lead related background processes are submitted for execution.

- When users want to manually add log entries (you might want to think of these as "diary" entries) as desired.

The Lifecycle of an Initiative

The following diagram shows the possible lifecycle of an Initiative:

Pending state: An initiative starts out in a pending state.

Active state: An initiative is transitioned manually by a user to the active state. Leads can only be generated for an initiative in an active state.

Accumulate Statistics state: A user or the system may transition an active initiative to a periodically transitioning accumulate statistics state. During this state, statistics for the initiative are accumulated prior to returning back to the active state.

Inactive state: An initiative may be transitioned manually by a user to the inactive state when they want to deactivate the initiative either temporarily or permanently. A user can manually place the initiative back to the active state from the inactive state.

Refer to Maintaining Initiatives for more information.

Initiative Information Can Be Overridden

“Initiative info” is the concatenated string of information that summarizes an initiative throughout the system. The base-package logic constructs this string by concatenating the following information:

- Initiative description

- Status of the initiative

- Start date and end date (if available) of the initiative

If you'd prefer a different info string, you can develop a new algorithm and plug-it in on the Initiative’s maintenance object.

About Initiative Hierarchies

Initiatives form an initiative hierarchy when one initiative is configured as a sub-initiative to a parent initiative. An initiative hierarchy can be used when a program is targeted at several market segments, or when different market segments each require a unique marketing effort to be executed. Initiative hierarchies can be up to five levels deep.

The following is a general example of a multi-level initiative hierarchy:

- Level 1 could be a “strategy” initiative.

- Level 2 could contain multiple campaigns. Each campaign can have a different way of marketing the strategy.

- Level 3 could define multiple marketing efforts. Each effort can have a different method for marketing the campaign.

- Level 4 could contain market segments that are the targets of a marketing effort.

Note: The terms used above are just for the example. Your implementation would define the actual terms used for the levels in an initiative hierarchy.

A parent initiative may be set up for reporting purposes, in which case you could choose to configure the initiative so that no leads are generated for it. For example, a “strategy” may not have eligibility criteria or lead event type profile defined against it. It may simply have sub-initiatives to define segments, and those segments could be the initiatives for which leads are generated. Reporting is able to be performed at the multiple levels in order to summarize the effectiveness of the sub-initiatives.

The Big Picture of Leads

A lead is an instance of an initiative for a targeted customer. A lead may contain events or actions that are there to encourage a customer to participate in a program.

Refer to Maintaining Leads for more information about working with Leads.

Contents

How are Leads Created

The Components of a Lead

The Lifecycle of a Lead

Lead Information Can Be Overridden

Leads Are Highlighted As Alerts

How and When Are Leads Activated

How are Leads Completed

How to Discard a Lead

The Big Picture of Lead Events

How are Leads Created

Leads are created as follows:

- The system can generate a lead for each customer that satisfies the eligibility criteria defined on an initiative.

- Users can manually create a lead at their discretion.

Refer to section Creating Leads from an Initiative and Manual Creation of a Lead for more information.

The Components of a Lead

A lead has two components: A Lead Event and a Lead Log.

Lead Event

A lead has one or more lead events. These events are the actions designed to encourage a customer to participate in a program. For example, one event could be that a letter or an email is sent to a customer.

Refer to The Big Picture of Lead Events for more information.

Lead Log

Every lead has a log holding its history. Entries are added to the log when meaningful events occur, for example:

- When a lead is created

- When an lead’s status changes (e.g. transitions to the active, success or discard state)

- When a lead event executes

- Users can manually add log entries (you might want to think of these as "diary" entries) as desired.

The Lifecycle of a Lead

The following diagram shows the possible lifecycle of a Lead:

Pending state: Leads can be created in either the Pending or Active state. By generating them in the Pending state, you can verify the targeted customers before actively marketing the initiative.

Active state: Leads can be created in either the Pending or Active state. When a lead is created or transitioned to the Active state, lead events are created to encourage the customers to participate in the initiative. For example, one event could be that a letter or an email is sent to a customer. The lead events and the sequence in which they occur are defined on the initiative’s lead event type profile. The lead remains in the active state while it is being actively marketed to the customer.

Successful state: The system infers that a lead has succeeded by the creation of other data in the system, at which time the lead transitions to the Successful state. For example:

- If an active lead for a customer is related to a rebate claim conservation program, the lead is determined to be successful when that rebate claim is filed for the customer.

- If an active lead for a customer is related to a contract option, the lead is determined to be successful when the customer’s service agreement is linked to that contract option.

- If an active lead for a customer is related to a campaign, the lead is determined to be successful if a completed order exists for the customer for the campaign.

Discarded state: An unsuccessful lead transitions to the Discarded state after a certain amount of time has passed, as defined on the initiative. If the initiative does not specify a time period, the lead remains in the active state until a user manually discards it.

Refer to Maintaining Leads for more information.

Lead Information Can Be Overridden

“Lead info” is the concatenated string of information that summarizes a lead throughout the system. The base-package logic constructs this string by concatenating the following information:

- Initiative description

- Status of the lead

- Creation date/time of the lead.

If you'd prefer a different info string, you can develop a new algorithm and plug-it in on the Lead’s maintenance object.

Leads Are Highlighted As Alerts

If you plug-in the appropriate alert algorithm (C1-OPENLDALR) on the Installation record, alert(s) will be shown for open leads associated with the person, account and premise in context. A separate alert is shown for each unique Lead that is in a non-final state. Each alert message shows the Lead's info string.

How and When Are Leads Activated

Leads are activated as follows:

- The system can generate a lead for each customer that satisfies the eligibility criteria defined on an initiative. The leads can be created in either a Pending or Active state. These leads can then be activated by a background process when required by the user.

- Users can manually activate a lead at their discretion.

Refer to section Creating Leads from an Initiative and Maintaining a Lead for more information.

How are Leads Completed

The system infers that a lead has succeeded by the creation of other data in the system, at which time the lead transitions to the Successful state. For example:

- If an active lead for a customer is related to a rebate claim conservation program, the lead is determined to be successful when that rebate claim is filed for the customer.

- If an active lead for a customer is related to a contract option, the lead is determined to be successful when the customer’s service agreement is linked to that contract option.

- If an active lead for a customer is related to a campaign, the lead is determined to be successful if a completed order exists for the customer for the campaign.

Users can also manually transition a lead to the Successful state at their discretion. Refer to Maintaining a Lead for more information about working with Leads.

How to Discard a Lead

An unsuccessful lead transitions to the Discarded state after a certain amount of time has passed, as defined on the initiative. If the initiative does not specify a time period, the lead remains in the active state until a user manually discards it.

Refer to Creating Creating Lead Event Types and Maintaining a Lead for more information

The Big Picture of Lead Events

A lead has one or more lead events. These events are the actions designed to encourage a customer to participate in a program. For example, one event could be that a letter or an email is sent to a customer.

You define the number and type of events to be initially inherited by a lead by configuring the Lead Event Type Profile on an initiative. Refer to About Lead Event Type Profile for more information.

The topics in this section provide additional information about lead events.

Contents

How are Lead Events Created

The Components of a Lead Event

The Lifecycle of a Lead Event

Lead Event Information Can Be Overridden

How and When Lead Events Are Activated

Activating Events Should Add aLog Entry

How Lead Events Are Cancelled

How are Lead Events Created

If a lead is created in a Pending state, there are no lead events associated with the lead. It is only when leads are created in or transitioned to the Active state, that lead events are created for the lead. The initial number of events and when the events shall occur are inherited from the lead’s initiative.

The Components of a Lead Event

Lead Event Log

Every lead event has a log holding its history. Entries are added to the log when meaningful events occur, for example:

- When a lead event is created.

- When a lead event’s status changes (e.g. transitions to the completed or cancelled state).

- Details of the content sent (if applicable).

- Users can manually add log entries (you might want to think of these as "diary" entries) as desired.

The Lifecycle of a Lead Event

The following diagram shows the possible lifecycle of a Lead Event business object:

Pending state: Lead events are initially created in the Pending state. A lead event can take a number of paths after it is created; it all depends on how you’ve configured the system.

Complete state: A lead event contains a date when it should be activated. This is referred to as its trigger date. On this date, the system invokes the algorithm associated with the lead event to execute the event or action. A user may complete a pending event at their discretion.

Cancelled state: A pending event will be cancelled automatically by the system when a lead is canceled. A user may cancel a pending event at their discretion.

Refer to Maintaining Lead Events for more information.

Lead Event Information Can Be Overridden

“Lead Event info” is the concatenated string of information that summarizes a lead event throughout the system. The base-package logic constructs this string by concatenating the following information:

- Lead event type description

- Status of the lead event

- Trigger date of the lead event

If you'd prefer a different info string, you can develop a new algorithm and plug-it in on the Lead Event’s maintenance object.

How and When Lead Events Are Activated

A lead event contains the date it should be activated; this is referred to as its trigger date. On this date, the Lead Event Periodic Monitor Process (a background process (C1-LDEVT)) invokes the algorithm associated with a lead event's event type. The algorithm, in turn, will decide on the state in which to leave the lead event.

If a user can't wait for the Lead Event Periodic Monitor Process real-time, they can click a button on Lead Event – Main to activate / trigger an event online in real-time. Refer to Maintaining Lead Events for more information.

You control how a lead event's trigger date is populated by configuring the Lead Event Type profile in an initiative. You indicate the number of days the lead event should be activated after the creation of the lead. Refer to Maintaining Initiatives for more information.

Activating Events Should Add aLog Entry

As described previously, a lead and lead event have a log holding a history of meaningful events in their lives. Most algorithms associated with a lead event’s event type will add an entry to both the lead and lead event logs.

These log entries are more than just an audit trail as they also reference the objects that are created during execution. For example, if an algorithm creates a customer contact, the ID of the customer contact will be referenced on the log (and end-users will be able to drill down on the log entry to see the customer contact).

How Lead Events Are Cancelled

A pending lead event will be cancelled automatically by the system when the lead is canceled.

A user may cancel a pending lead event at their discretion. Refer to Maintaining Lead Events for more information.

The Big Picture of Sales Representatives

A sales representative is a group or individual who can be assigned to follow up leads.

Individual sales representatives can be members of one or more groups, and they can be an internal user or an external party.

Groups can be used to control which sales representatives are allocated to the leads for an initiative. For example, you can set up a group whose sales representatives are responsible for industrial customers. Initiatives that target industrial customers can then be configured so that this group is specified as the only one whose sales representatives can be assigned the initiative’s leads.

Because many reports will aggregate information for all sales representatives in a group, you may choose to set up a sales representative group just for reporting purposes.

The topics in this section provide additional information about Sales Representatives.

Contents

Sales Representative Log

The Lifecycle of a Sales Representative

Sales Representative Log

Every Sales Representative has a log holding its history. Entries are added to the log when meaningful events occur, for example:

- When a Sales Representative is created

- When a Sales Representative’s status changes (e.g. transitions to the inactive state)

- Users can manually add log entries (you might want to think of these as "diary" entries) as desired.

The Lifecycle of a Sales Representative

The following diagram shows the possible lifecycle of a Sales Representative:

Active state: A Sales Representative starts out in an active state.

Inactive state: A Sales Representative may be transitioned manually by a user to the inactive state when they want to deactivate the Sales Representative either temporarily or permanently. A user can manually place the Sales Representative back to the active state from the inactive state.

Refer to Maintaining Sales Representatives for more information.

Maintaining Initiatives

An initiative defines a structured campaign that outlines the efforts to encourage customers to participate in a program targeted at a specific market segment.

Refer to The Big Picture of Initiatives for more information about initiatives.

Contents

Initiative Portal

How To Perform Common Initiative Functions

Initiative Portal

You use the Initiative portal to maintain initiatives. This portal contains the following zones:

- Initiative: Displays the basic information about the initiative.

- Initiative Eligibility Criteria Overview: Displays eligibility criteria associated with the initiative.

- Initiative Hierarchy: Displays the entire hierarchy of initiatives that the selected initiative is a part of.

- Lead Summary by Representative: Displays the summary of leads for the initiative hierarchy, grouped by representatives.

- Lead Generation and Disposition: Allows you to submit the lead generation or lead disposition batch process.

- Initiative Leads: Displays the leads that are associated with the initiative.

- Lead Outcome Graph: Displays the number of leads linked to the initiative hierarchy that entered the final state within the last 24 months.

- Lead Statistics: Displays statistics for the leads associated with the initiative.

- Lead Monthly Statistics: Displays statistics for the leads associated with the initiative on a monthly basis.

How To Perform Common Initiative Functions

The topics in this section describe how to perform common initiative functions from the Initiative portal.

Contents

Creating Initiatives

Maintaining an Initiative

Viewing Initiative Hierarchy

Creating Leads from an Initiative

Managing Leads from an Initiative

Graphs and Statistics for an Initiative

Creating Initiatives

Use this procedure to create a new Initiative.

1. Select Main Menu > Sales & Marketing > Initiative + .

2. Select the business object that will define the initiative and click OK.

The C1-base package comes supplied with three initiative business object types:

- Initiative – Conservation Program: An initiative that can encourage customers to participate in a conservation program where a rebate claim can be filed.

- Initiative – Contract Option: An initiative that can encourage customers to sign up for special contract options.

- Initiative – Service Campaign: An initiative that can encourage customers to complete a marketing survey and recording the customer’s responses.

3. Enter the start date and end date for the initiative.

4. Specify if the initiative is a master or a subsidiary initiative.

- For a Master Initiative:

- For an Initiative – Conservation Program, search for and select the conservation program to be attached to this initiative.

- For an Initiative – Contract Option, search for and select the Contract Option ID to be attached to this initiative, and specify no for whether or not the initiative is part of the Contract Option Participation analysis.

- For an Initiative – Service Campaign, search for and select the campaign to be attached to this initiative.

- If the initiative is a Subsidiary Initiative, search for and select the initiative that is the parent to this initiative.

5. Specify whether or not leads can be generated for the initiative.

- If the initiative may have leads, specify if the leads can have representatives. If the initiative references a group representative, its leads will be assigned to one of the group's individual representatives. If an initiative references an individual representative, all of its leads must reference this individual. Valid values are Not Allowed and Required.
If a representative for the lead is required:

- Search for and select the default sales representative.

- In the Lead Reassignment Notification section, specify the notification method to occur if the sales representative for the lead is changed. Valid values are Not Applicable and Create a New Lead Event.
If the default notification method is Create a New Lead Event, search for and select a reassignment lead event type (e.g. sends an email to the sales representative if a lead is assigned to them).

- Specify the primary communication channel for the initiative. Eligibility criteria exists that targets customers who have positively responded to earlier leads based on the primary marketing channel for the successful lead’s initiative. For example, a customer may be eligible if they have a successful lead where the primary communication channel was email or bill message.

6. In the Statistics Notification section, specify how often, in hours, the statistics for the initiative should be updated.

A background process accumulates the statistics for an initiative when enough time has elapsed since the statistics were last updated. A user may also manually initiate the process to update the statistics for an initiative.

7. If this initiative will have leads, add lead event types in the Lead Event Type Profile section to define the events or actions that will occur during the lifetime of the lead to encourage the customer to participate in the initiative. To add lead event types in the Lead Event Type Profile section:

1. Assign an Event Sequence to each list entry.

2. Search for and select a Lead Event Type to indicate the type of lead event to generate for each list entry (for example send customer an email or create a customer contact).

3. Specify the number of Days After Lead Creation that the related lead event will be triggered.

8. Click Save.

Maintaining an Initiative

The topics in this section describe procedures for maintaining an initiative:

Contents

Allowable Record Actions on an Initiative

Defining Eligibility Criteria for an Initiative

Allowable Record Actions on an Initiative

Use this procedure to maintain an initiative using standard record actions.

1. Select Main Menu > Sales & Marketing > Initiative .

2. Enter your search criteria in the Initiative Query zone.

3. Click Refresh.

4. In the search results list, click the link for the initiative you want to maintain. The selected initiative opens in the Initiative portal.

5. Click the appropriate record action button:

- Edit – Click the Edit button to edit the main attributes of an initiative. When you click Save, the system updates the record.

- Duplicate – Click the Duplicate button to create a duplicate of the initiative being displayed. Before the new object is added to the database, a window appears asking you to enter the unique identifier of the new object. When you click OK, the system creates the record by copying the original record.

- Activate – Click the Activate button to transition a pending or inactive initiative to the active state.

- Deactivate – Click to Deactivate button to transition an active initiative to an inactive state.

- Refresh Statistics - Click the Refresh Statistics button to manually initiate the accumulation of the statistics for the initiative.

- Delete – Click the Delete button and click OK to delete the initiative from the database. Before you delete an initiative, the system verifies that the initiative is not referenced anywhere in the system. If it is, you cannot delete it. For example, if you attempt to delete an initiative, the system ensures the initiative has not been referenced on a lead, etc.

Defining Eligibility Criteria for an Initiative

Use this procedure to define eligibility criteria for an initiative. The following steps apply to each criterion.

Prerequisites: You must create an initiative that can have leads before you can define eligibility criteria for the initiative.

1. Select Main Menu > Sales & Marketing > Initiative .

2. Enter your search criteria in the Initiative Query zone.

3. Click Refresh.

4. In the search results list, click the link for the initiative you want to maintain. The selected initiative opens in the Initiative portal.

5. To define eligibility criteria for the initiative, click the Add link in the Initiative Eligibility Criteria Overview zone title bar. This zone is displayed for initiatives that can have leads.

6. Select the business object that will define the initiative criteria and click OK.

The C1-owned base package provides a number initiative criteria types including:

- Initiative Criteria – Current Communication Channels

- Initiative Criteria – Current Conservation Programs

- Initiative Criteria – Current Contract Options

- Initiative Criteria – Current Rates

- Initiative Criteria – Current SP Types

- Initiative Criteria – Current Service Types

- Initiative Criteria – Freeform

- Initiative Criteria – Retrieve Premise Cities

7. Enter a sequence number, description, and detailed description for the criterion.

8. Complete the Criteria Comparison section as follows:

- Algorithm: Select the appropriate algorithm

- Comparison Operator: Select the operator used in the comparison •

- Comparison Value: Specify a value (such as a contract option or conservation program) to which the retrieved value is compared using the comparison operator. The type of comparison value to choose depends upon the initiative criteria type.

Initiative Criteria Business Object (Type)

Examples of Algorithms Associated with Initiative Criteria

Valid Comparison Operators

Comparison Value

Initiative Criteria – Current Communication Channels

Refer to C1-ICGETCOCH for an example of an algorithm that retrieves all successful communication channels of leads link to the account

‘< >’ and ‘=’

Specify Primary Communication Channel

Initiative Criteria – Current Conservation Programs

Refer to C1-ICGETCOPR for an example of an algorithm that retrieves conservation programs with rebate claims (in any state) link to the account

‘< >’ and ‘=’

Search for and select Conservation Program

Initiative Criteria – Current Contract Options

Refer to C1-ICGETCOPT for an example of an algorithm that retrieves contract options for the account’s active and pending start service agreements

‘< >’ and ‘=’

Search for and select Conservation Option ID

Initiative Criteria – Current Rates

Refer to C1-GETACTVRT for an example of an algorithm that retrieves the effective rate schedules for the account’s active and pending start service agreements

‘< >’ and ‘=’

Search for and select Rate Schedule

Initiative Criteria – Current SP Types

Refer to C1-ICGETSPTY for an example of an algorithm that retrieves the SP Types for the account’s active and pending start service agreement’s service points

‘< >’ and ‘=’

Search for and select SP Type

Initiative Criteria – Current Service Types

Refer to C1-ICGETSVTY for an example of an algorithm that retrieves the service types for the account’s active and pending start service agreements

‘< >’ and ‘=’

Search for and select Service Type

Initiative Criteria – Freeform

Refer to:

- C1-ICDYLSTLD for an example of an algorithm calculates the number of days since the last lead was created for the account

- C1-ICCHKAPAY for an algorithm that checks if the customer is on automatic payments

- C1-ICCHKBUDG for an algorithm that checks if the customer is on a budget

- CI_GETOPTOUT for an algorithm that retrieves the attribute on the account for marketing opt-out preference

- CI_APPLREB for an algorithm that retrieves conservation programs with rebate claim (in any state) liked to the account for a specific conservation program

- CI_GETDIV for an algorithm that retrieves the CIS Division for the account

- C1-ICGETSPTY for an example of an algorithm that retrieves the SP Types for the account’s active and pending start service agreement’s service points

- C1-GETACTVRT for an example of an algorithm that retrieves the effective rate schedules for the account’s active and pending start service agreements

- C1-ICGETCOPR for an example of an algorithm that retrieves conservation programs with rebate claims (in any state) link to the account

- C1-ICGETCOPT for an example of an algorithm that retrieves contract options for the account’s active and pending start service agreements

- C1-ICGETSVTY for an example of an algorithm that retrieves the service types for the account’s active and pending start service agreements

- C1-ICGETCOCH for an example of an algorithm that retrieves all successful communication channels of leads link to the account

- CI_AVGKWH for an example of an algorithm that calculates the average historical consumption for the account’s service agreements

- C1-ICGETCITY for an algorithm that retrieves the cities from the account’s service agreements

- C1-ICGETCC for an algorithm that retrieves the customer class for the account

‘<’, ‘<=’, ‘< >’, ‘=’, ‘>’, ‘>=’, ‘Between’ and ‘In’

Specify Comparison Value

Initiative Criteria – Retrieve Premise Cities

Refer to C1-ICGETCITY for an example of an algorithm that retrieves the cities from the account’s service agreements

‘< >’ and ‘=’

Specify City

9. Complete the Comparison Results section as follows:

- If True: The action to take if the comparison is true. Valid actions are Check Next Condition, Eligible or Not Eligible.

- If False: The action to take if the comparison is false. Valid actions are Check Next Condition, Eligible or Not Eligible.

- If Insufficient Data: The action to take if there is insufficient data to perform the comparison. Valid actions are Check Next Condition, Eligible, Error or Not Eligible.

10. Click Save.

Repeat steps 5 to 10 to add additional criterion for the initiative.

Viewing Initiative Hierarchy

The Initiative Hierarchy zone on the Initiatives portal displays the hierarchy the selected initiative is a part of. By clicking on any initiative in the hierarchy, you will be navigated to the selected initiative.

Creating Leads from an Initiative

The topics in this section describe how to create leads from an Initiative.

Contents

Bulk Creation of Leads

Uploading Leads

Bulk Creation of Leads

Use this procedure for bulk creation of leads.

1. Select Main Menu > Sales & Marketing > Initiative.

2. Enter your search criteria in the Initiative Query zone.

3. Click Refresh.

4. In the search results list, click the link for the initiative you want to maintain. The selected initiative opens in the Initiative portal.

5. To create leads for the initiative, click Lead Generation on the Lead Generation and Disposition zone. This zone is displayed for initiatives in the active state, can have leads and allows a batch job to be submitted for the creation of leads.

- Select the Lead Status to leave the created leads in. Valid values are Pending or Active. Creating leads in a pending state allows a user to confirm the lead population prior to activating these leads

- Specify the Number of Leads to Generate. This may be used to create a sample set of leads to test the initiative’s eligibility criteria.

- Specify the Email Address. You may optionally specify an email address if you want to be informed when the batch job completes

6. Click OK.

Uploading Leads

Note: It is important to note that this functionality is to be used on small volume uploads.

1. Select Main Menu > Sales & Marketing > Initiative.

2. Enter your search criteria in the Initiative Query zone.

3. Click Refresh.

4. In the search results list, click the link for the initiative you want to maintain. The selected initiative opens in the Initiative portal.

5. To upload Leads for an initiative, click the Lead Upload link in the Initiative Leads zone title bar. This displays the Lead Upload page, which you can use to upload a CSV file containing account IDs for which leads will be generated.

6. Click Submit.

Managing Leads from an Initiative

The procedures in this section describe how to manage leads from an initiative.

Contents

Viewing Lead Summary by Representative

Initiatives Leads Zone

Activating / Deleting / Discarding Leads for an Initiative in Bulk

Viewing Lead Summary by Representative

The Lead Summary by Representative zone displays a summary of leads for the initiative (or initiative hierarchy group) by individual representative. If the Initiative is configured not have a sales representative, the zone will group those leads under ‘Leads without Representative’.

To limit the summary of leads by sales representative:

1. Select Main Menu > Sales & Marketing > Initiative.

2. Enter your search criteria in the Initiative Query zone.

3. Click Refresh.

4. In the search results list, click the link for the initiative you want to maintain. The selected initiative opens in the Initiative portal.

5. Specify Start Date and/or End Date to limit the summary to leads created within this date range. If specified, start date must be on or before the current date and end date must be on or after the start date. If left blank, end date is defaulted to the current date.

6. If Include Inactive Leads is set to No, leads for the initiative (or initiative hierarchy group) regardless of status are included.

The following is displayed in the result set:

- A summary line for the individual sale representative shows the total Lead Count.

- A breakdown is included beneath each sales representative summary line that shows a subtotal Lead Count by lead state.

- An icon is displayed that allows broadcasting of the representative, initiative, date range and lead state (if available) to other zones on the portal. Lead state broadcast is only available on the subtotal lines.

Initiatives Leads Zone

By default, the Initiative Leads zone is populated with all leads for the initiative (or initiative hierarchy group) for all sales representatives.

If you want to limit the result set, use the Lead Summary by Representative zone to the select the broadcast item for the appropriate row of representative, date range and lead state (if available) for the initiative (or initiative hierarchy group). This will populate the Initiative Leads zone on the Initiative portal with relevant lead information for the selected item.

The following is displayed in the result set for each lead:

- Basic Lead information for the initiative's lead. You can navigate to the lead by clicking on the lead.

- Customer Information related to the lead. You can navigate to the account related to the lead by clicking on the customer information.

- The Last Complete Event. You can navigate to the lead event by clicking on the last complete event for a lead.

- For open leads, the Next Pending Event. You can navigate to the lead event by clicking on the next pending event for a lead.

- The Sales Representative shows the rep assigned to each lead.

Activating / Deleting / Discarding Leads for an Initiative in Bulk

Use the following procedures to activate, delete or discard leads for an initiative.

1. Select Main Menu > Sales & Marketing > Initiative.

2. Enter your search criteria in the Initiative Query zone.

3. Click Refresh.

4. In the search results list, click the link for the initiative you want to maintain. The selected initiative opens in the Initiative portal.

5. To activate, delete or discard leads for the initiative, click Lead Disposition on the Lead Generation and Disposition zone. This allows a batch job to be submitted for the activation, deletion or discarding of leads.

- Select the Pending Lead Disposition to indicate what should occur to pending leads for the initiative. Valid values are Activate (pending leads), Delete (in case of erroneous generation) or Ignore.

- Select the Active Lead Disposition to indicate what should occur to active leads for the initiative. Valid values are Ignore or Discard.

- Select the Discard Reason why active leads are to be discarded. The values are maintained on the Status Reason admin table

- Specify the Email Address. You may optionally specify an email address if you want to be informed when the batch job completes

6. Click OK.

Graphs and Statistics for an Initiative

The following zones display graph and statistics for the leads associated with the initiative.

Note: The system periodically refreshes the statistics for an initiative when the time specified on an initiative has lapsed. A user may also manually initiate the refreshing of statistics if required.

Lead Outcome Graph

This Lead Outcome Graph zone shows the number of Leads linked to the initiative (or initiative group hierarchy) that entered the final state in the last 24 months starting from the most recent completed Lead.

The date shown on the X-axis will be the first day of the month. Note that the information displayed here is based on the most recent completed Lead as of the time the Initiative Statistics is accumulated.

Lead Statistics

The Lead Statistics zone has two charts to provide statistics for leads for the initiative:

- Leads by State: The chart shows the number of leads for each state in the lead's lifecycle as of the initiative’s Statistics Date/Time. Each state can be represented by a unique color. These colors are defined on the Program Management master configuration. Refer to About Program Management Master Configuration for setting up program management options for more information.

- Active Leads by Representative: The chart shows the top 5 individual sales representatives for the initiative (i.e. sales representatives with the largest number of active leads assigned to them as of the Statistics Date/Time). The top 5 sales representative can be represented by a unique color. These colors are defined on the Program Management master configuration. Refer to About Program Management Master Configuration for setting up program management options for more information.

Lead Monthly Statistics

The Lead Monthly Statistics zone has two charts to provide statistics for leads for the initiative:

- Leads by State: The chronological graph highlights the number of open, completed and discarded leads over time for the initiative in context. The date displayed on the x-axis represents the start date of the statistics period. For example, 01-01-2013 shows statistics for the period 01-01-2013 through 01-31-2013. Each State can be represented by a unique color. These colors, along with the number of months to display are defined on the Program Management master configuration. Refer to About Program Management Master Configuration for setting up program management options for more information.

- Active Leads by Representative: The chronological graph highlights the top 4 discard reasons over time for the initiative in context. Statistics for all other discard reasons are accumulated in a catch-all bucket. The date displayed on the x-axis represents the start date of the statistics period. For example, 01-01-2013 shows statistics for the period 01-01-2013 through 01-31-2013.Each Discard Reason can be represented by a unique color. These colors, along with the number of months to display are defined on the Program Management master configuration. Refer to About Program Management Master Configuration for setting up program management options for more information.

Maintaining Leads

A lead is an instance of an initiative for a targeted customer. A lead may contain events or actions that are there to encourage a customer to participate in a program

The topics in this section describe the common functions associated with leads.

Contents

My Leads

Navigating to Related Leads

How To Perform Common Lead Functions

My Leads

You can use the My Lead menu item to maintain leads.

- If your User ID is linked to a Sales Representative, you are navigated to the Sales Representative portal with the user in context.

- If your User ID is not linked to a Sales Representative, you are navigated to the Leads Query portal.

Lead Portal

You use the Leads portal to maintain leads. This portal contains the following zones:

- Lead: Displays the basic information about the lead.

- Lead Events: Displays the events associated with the lead in chronological order.

- Related Leads: Displays the leads that are related to the current lead’s related objects (e.g. account).

How To Perform Common Lead Functions

The topics in this section describe how to perform common lead maintenance functions from the Lead portal.

Contents

Manual Creation of a Lead

Maintaining a Lead

Adding New Lead Events to a Lead

Navigating to Related Leads

Manual Creation of a Lead

Use this procedure to manually create a new lead.

1. Select Main Menu > Sales & Marketing > Lead + .

2. Select the Initiative with which the lead will be associated and click OK.

3. Search for and select the sales representative for the lead.

4. Search for and select the account for which the lead will be generated.

5. Click Save.

Maintaining a Lead

1. Select Main Menu > Sales & Marketing > Lead .

2. Enter your search criteria in the Lead Query zone.

The C1-owned base package search options include:

- Name and address

- Related object

- Representative and initiative

- Lead ID

3. Click Refresh.

4. In the search results list (not applicable if Lead ID is specified in the search criteria), click the link for the lead you want to view maintain. The selected lead opens in the Lead portal.

Note: You may also navigate to the Lead portal by clicking on the appropriate lead from various portals and zones. Examples include:

- Dashboard Portal: Alerts zone

- Initiative Portal: Initiative Leads zone

- Sales Representative Portal: Initiative Leads zone or Initiative Lead Events

5. Click the appropriate record action button:

- Edit – Click the Edit button to allow you to edit the main attributes of the lead. When you click Save, the system updates the record.

- Activate – Click the Activate button to transition a pending lead to the active state. When a lead is activated, lead events for the lead are created to encourage the customers to participate in the initiative.

- Delete – Click the Delete button and click OK to delete a pending lead from the database. Before you delete a lead, the system verifies that the lead is not referenced anywhere in the system. If it is, you cannot delete it.

- Complete – Click the Complete button to indicate that an active lead has been successful.

- Discard - Select the Discard button to inactivate an active lead. Select a Status Reason indicating why the lead is being inactivated and click Save. The values are maintained on the Status Reason admin table

Adding New Lead Events to a Lead

1. Select Main Menu > Sales & Marketing > Lead .

2. Enter your search criteria in the Lead Query zone.

The C1-owned base package search options include:

- Name and address

- Related object

- Representative and initiative

- Lead ID

3. Click Refresh.

4. In the search results list, click the link for the lead you want to view maintain. The selected lead opens in the Lead portal.

5. To add a lead event to the lead, click the Add Lead Event link in the Lead Events zone title bar.

6. Search for and select the appropriate lead event type.

7. Specify the Trigger Date of when the lead event is to be executed.

8. Click Save.

Repeat steps 5 to 8 for add additional lead events.

Navigating to Related Leads

The Related Leads zone on the Leads portal displays the leads that are related to the current lead’s related objects (e.g. account). You can navigate to any of the related leads displayed in the zone by clicking on the lead.

Maintaining Lead Events

A lead event is an event or action in a lead to take place to encourage a customer to participate in a program. A lead may contain may lead events.

You use the Lead Event portal to maintain lead events. This portal contains the following zone:

- Lead Event: Displays the basic information about the lead event.

To maintain a lead event:

1. Select Main Menu > Sales & Marketing > Lead Event .

2. Enter your search criteria in the Lead Event Query zone.

The C1-owned base package search options include:

- Name and address

- Related object

- Initiative and representative

- Lead and lead event

3. Click Refresh.

4. In the search results list, click the link for the lead event you want to maintain. The selected lead opens in the Lead Event portal.

Note: You may also navigate to the Lead Event portal by clicking on the appropriate lead event from various portals and zones. Examples include:

- Initiative Portal: Initiative Leads zone

- Sales Representative Portal: Initiative Leads zone or Initiative Lead Events

5. Click the appropriate record action button:

- Edit – Click the Edit button to allow you to edit the main attributes of the lead event. When you click Save, the system updates the record.

- Complete – Click the Complete button to indicate a pending lead event is completed.

- Cancel - Select the Cancel button to cancel a pending lead event.

Maintaining Sales Representatives

A Sales Representative is a user or group of users who can be assigned to follow up on leads and responsible for selling the initiatives product or service to the customer.

The topics in this section describe the common functions associated with Sales Representatives.

Contents

Sales Representatives Portal

How To Perform Common Sales Representative Functions

Sales Representatives Portal

You use the Sales Representative portal to maintain sales representatives. This portal contains the following zones:

- Sales Representative: Defines the basic information about the representative.

- Initiative Lead Summary: Lists initiatives and information about leads for each initiative for the representative. Clicking the broadcast icon from the summary table in this zone displays the following additional zones:

- Initiative Leads: Displays leads for the initiative and representative.

- Initiative Lead Event Summary: Displays lead event statistics for the initiative lead and representative.

- Initiative Lead Events: Displays lead events for the initiative lead and representative.

- Group’s Representatives: This zone is displayed for a representative group and lists the individual representatives who are members of the group.

- Representative’s Groups: This zone is displayed for an individual representative and lists the representative groups of which this representative is a member.

How To Perform Common Sales Representative Functions

The topics in this section describe how to perform common sales representative functions from the Sales Representative portal.

Contents

Creating Representatives

Maintaining Representatives

Displaying Leads Associated Information for a Sales Representative

Creating Representatives

Use this procedure to create a new representative.

1. Select Main Menu > Sales & Marketing > Sales Representative +.

2. Select the sales representative type that will define the representative and click OK.

Valid values are: Group Sales Representative and Individual Sales Representative.

3. Enter the appropriate information for the representative:

- For a Group Sales Representative:

- Specify the Sales Representative name and description.

- Search for and select Individual Sales Representative who will be a member of the group.

- For an Individual Sales Representative:

- Specify the Sales Representative name and description.

- Search for and select User for the individual sales representative.

- Search for and select Group Sales Representative that the individual sales representative will be a member of.

4. Click Save.

Maintaining Representatives

1. Select Main Menu > Sales & Marketing > Sales Representative.

2. Enter your search criteria in the Sales Representative Query zone.

3. Click Refresh.

4. In the search results list, click the link for the sales representative you want to maintain. The selected sales representative opens in the Sales Representative portal.

Note: You may also navigate to the Sales Representative portal by clicking on the appropriate Sales Representative from various portals and zones. Examples include:

- Initiative Portal: The Initiative Zone or the Lead Summary By Representative.

- Lead Portal: Lead zone

5. Click the appropriate record action button:

- Edit – Click the Edit button to allow you to edit the main attributes of a sales representative. When you click Save, the system updates the record

- Duplicate – Click the Duplicate button to create a duplicate of the sales representative being displayed. Before the new object is added to the database, a window appears asking you to enter the unique identifier of the new object. When you click OK, the system creates the record by copying the original record

- Deactivate – Click the Deactivate button to transition an active sales representative to an inactive state

- Delete – Click the Delete button and click OK to delete the sales representative from the database. Before you delete a sales representative, the system verifies that the sales representative is not referenced anywhere in the system. If it is, you cannot delete it. For example, if you attempt to delete a sales representative, the system ensures the sales representative is not referenced on a lead, etc.

6. For an individual representative, you can add the representative to another group by clicking the Add Rep to Another Group link in the Representative’s Group zones title bar. Select a group sales representative and click Save. You can remove the representative from a group (or groups) by selecting the group(s) and clicking the Remove Rep from Group(s) button.

7. For a representative group, you can add a representative to the group by clicking the Add Rep To This Group link in the Group’s Representatives zone’s title bar. Search for and select the individual sales representative to add to the group and click Save. You can remove representatives from a group by selecting the representatives and clicking the Remove Rep(s) from Group button.

Displaying Leads Associated Information for a Sales Representative

The Initiative Lead Summary zone on the Sales Representative portal displays the leads that have been assigned to the sales representative. If the representative is a group, leads are summarized for all individuals in the group.

To limit the summary of leads for the sales representative:

1. Select Main Menu > Sales & Marketing > Sales Representative.

2. Enter your search criteria in the Sales Representative Query zone.

3. Click Refresh.

4. In the search results list, click the link for the sales representative you want to view or manage. The selected sales representative opens in the Sales Representative portal.

5. Specify Start Date and/or End Date to limit the summary to leads created within this date range. If specified, start date must be on or before the current date and end date must be on or after the start date. If left blank, end date is defaulted to the current date.

6. If Only Show Active Initiatives is set to Yes, only leads linked to initiatives in the active state are summarized. Otherwise, leads for all initiatives regardless of status are included.

7. Click Refresh.

The following is displayed in the result set:

- A summary line for each initiative shows the total Lead Count for the individual or group rep.

- A breakdown is included beneath each initiative summary line that shows a subtotal Lead Count by lead state.

- An icon is displayed that allows broadcasting of the representative, initiative, date range and lead state (if available) to other zones on the portal. Lead state broadcast is only available on the subtotal lines.

Displaying Leads and Lead Event Information for a Sales Representative

From the Initiative Lead Summary zone on the Sales Representative portal, you can broadcast a representative, initiative, date range and lead state (if available) to other zones on the portal.

Contents

Sales Representative Initiatives Leads Zone

Initiatives Lead Event Type Summary

Initiatives Lead Events Summary

Sales Representative Initiatives Leads Zone

By clicking on one of the broadcast items in the Initiative Lead Summary zone, the Initiative Leads zone on the Sales Representative portal is populated with relevant lead information for the selected item. If the sales representative is a group, leads for all individuals in the group are shown.

The following is displayed in the result set for each lead:

- Basic Lead information for the initiative's lead. You can navigate to the lead by clicking on the lead.

- Customer Information related to the lead. You can navigate to the account related to the lead by clicking on the customer information.

- The Last Complete Event. You can navigate to the lead event by clicking on the last complete event for a lead.

- For open leads, the Next Pending Event. You can navigate to the lead event by clicking on the next pending event for a lead.

- The Sales Representative shows the rep assigned to each lead.

For information about using this zone to reassign leads to another representative, see Reassigning Leads for a Sales Representative.

Reassigning Leads for a Sales Representative

To reassign leads from one sales representative to another sales representative:

1. On the Initiatives Leads zone, select the leads that you want to reassign and click Reassign Rep.

2. Select the Sales Representative to reassign the selected lead to and click Save.

Initiatives Lead Event Type Summary

By clicking on one of the broadcast items in the Initiative Lead Summary zone, the Initiative Lead Event Type Summary zone is displayed. If the representative is a group, lead events are accumulated for all individuals in the group. The summary spans the 14 day period on/after the Start Date which defaults to current date if blank. If you want to specify the start date, click Refresh to update the zone.

The following is displayed in the result set:

- The Event Count shows the total number of events for a specific Event Type on each day within the 14 day period. You can click on the broadcast icon to see a list of events for the Event Date and Event Type on the Initiative Lead Events zone.

- The Event Status bar provides a breakdown of the total event count by status. Each color segment shown represents a different event status for pending, completed and canceled events. Colors used are defined on the program management master configuration. Refer to Setting Up the Program Management Master Configuration for setting up program management options for more information.

- Hover the mouse pointer over a segment of the bar to see the respective count and status represented by the segment.

- Click on a segment of the bar to broadcast the event date, event type and event status. Broadcasting from the event status bar instead of the broadcast icon will limit the Initiative Lead Events zone to a particular status.

Initiatives Lead Events Summary

By clicking on one of the broadcast items in the Initiative Lead Event Type Summary zone, the Initiative Lead Events zone is populated. This zone displays lead events for the initiative, representative, lead event type (if available) and status (if available). If the representative is a group, events for all individuals in the group are shown. Only lead events with a trigger date on or after the Start Date are displayed.

The following is displayed in the result set:

- Event Date and Lead Event information is shown for each event. You can navigate to a specific lead event by clicking on a lead event.

- Lead shows the lead information for the initiative's lead. You can navigate to the lead by clicking on a lead.

- Customer Information related to the lead. You can navigate to the account related to the lead by clicking customer information for a lead.

- The Sales Representative shows the representative assigned to the lead.

Rates

When you set up a customer in the system, you create a service agreement for every service that you sell to the customer. The most important information specified on a service agreement is the rate. The rate controls:

- How the service's charges are calculated.

- How the charges are described on the customer's bills.

- How the general ledger is affected by the charges.

In addition to calculating charges for service, your implementation can also use rates to calculate adjustments.

Note:

Version 2.4 of Oracle Utilities Customer Care and Billing introduced a new rate engine. The new rate engine has many features to simplify the definition and maintenance of your rates. Probably the most significant feature is the ability to group common calculation rules into reusable calculation groups that can be executed by any rate. For example, if several rates have the same taxation calculations, you can create a single calculation group that contains the common taxation calculations and then simply reference this group in all rates that share the same taxation calculations. This functionality results in less initial set up because common pricing rules are not repeated in your rates. In addition, this lack of redundancy simplifies future changes as any changes need to be made only once (to the calculation group that encapsulates the rules). Refer to the section on the Rate Engine for a description of the new rate engine. The remainder of this document describes the original rate engine. When navigating the main men, please note that items on the Rates submenu that involve the original rate engine functionality include the term Classic.

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. Refer to Calculated Adjustments for how to use a rate to calculate an adjustment.

Note:

Not all service agreements reference a rate. It's important to understand that you may have service agreements that don't use a rate to calculate their charges. For example, you may have billable charge service agreements that exist to bill a customer for charges that have been calculated in a foreign system. Whether or not a service agreement uses a rate and the list of rates that can be specified on a service agreement are controlled by the service agreement's SA type.

Warning:

Do not equate a rate in your legacy system with a rate in this system. You may find that the system's flexibility will result in fewer rates than you have today. For example, your current rate structure may have 3 rates for water service because there are different prices depending on the geographic area in which the customer lives. However in this system, you can set up a single rate and vary the price depending on where the customer lives. Typically, you will only gain the intuitive understanding to make these types of decisions after attempting to set up your rates for the first time. In other words, the rate definition process is iterative and you may discover in later iterations that you can consolidate several existing rates into one flexible rate.

Contents

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 Bill Factors

Defining Rate Versions

Designing Rate Components

Defining Rate Components

Rate Version Merge

Rate Check

Use Sub Rate Schedules To Encapsulate Common Rate Components

Setting Up Estimated Consumption For Items

Setting Up Degree Days (and Average Temperatures)

Effective Dates & Price Proration

Rate Examples

How To Add A New Service Quantity Rule Algorithm

How To Add A New Register 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 3-January-2008, the other effective on 17-August-2009.

- 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.

- Bill 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" bill factor rather than specifying the specific tax percent. This allows the tax rate to be maintained in one place.

Note:

Bill factors have many uses. Bill factors have many uses in addition to specifying tax rates. Refer to An Overview Of Bill Factors for all the details.

The remainder of this chapter discusses the intricacies of setting up the rates and bill 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 SA types that can use the rate. You do this by referencing the rate on SA Type - Rate . Note that only primary rate schedules may be referenced on SA Types.

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.

Contents

Defining Frequency Codes

UOM versus TOU versus SQI

Defining Measured Quantity Manipulation Rules

Defining Service Quantity (SQ) Identifiers

Defining Frequency Codes

When you create a rate schedule, you must enter a code defining the frequency in which the prices are expressed, e.g., monthly, quarterly, biannual, etc. To set up frequency codes, open Admin Menu, Frequency.

Description of Page

Enter a unique Frequency ID and Description for each frequency.

Before entering the remaining fields, you must analyze the "proration provisions" in your rates. For example, consider a rate used to calculate charges for a "month's worth of service". Assume this rate's charges will not be prorated when the customer's service period is anywhere between 27 and 33 days. This rate requires a frequency that indicates:

- 12Periods / Year (because it's a monthly rate).

- Minimum Days Offset equal to 3 .

- Maximum Days Offset equal to 3 .

When the system creates a bill using a rate with this frequency, it compares the number of days of consumption on the bill to the minimum and maximum number of days inferred by the rate's frequency. In the example above, the minimum number of days would be 27 (365 days / 12 period per year - 3 offset for minimum days). The maximum number of days would be 33 (365 days / 12 periods per year + 3 offset for maximum days). Therefore, if a bill's consumption period is less than 27 days or more than 33 days, the bill's charges are 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, we have encountered companies who treat a year has have 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 primary Rate Schedule must have a frequency. Refer to Rate Schedule - Main for more information.

UOM versus TOU versus SQI

Almost all rates contain prices in respect of some number of something. This something could be anything from a therm of gas to a kilowatt-hour of electricity. We use three distinct codes to identify the "thing" being priced in a rate. These codes are UOM (unit of measure), TOU (time of use), and SQI (service quantity identifier). These codes must be set up before you can create a rate schedule.

You don't have to use all three codes when you specify a price in a rate. Rather, you use the codes that are needed to clearly identify the thing being priced. We'll use a few examples to clarify this concept.

Let's consider a rate that simply has a price per therm. For this rate, you'd only use a UOM code to identify the thing being priced (and this code should be something simple like THRM ).

Next, let's consider a rate that has a different price for kilowatts consumed during peak hours as compared to those used during off-peak hours. You would use a combination of UOM and TOU to define the thing being priced. In this example, we'd recommend using a single UOM for kilowatt-hours (labeled KWH ) and two TOU codes - one for the peak period (labeled PEAK ) and the other for the off-peak period (labeled OFFPEAK ).

Note:

Rule. If the thing being priced is measured by a meter, you must use the same UOM / TOU code(s) in the rate as are specified on the meter's register(s). Refer to Setting Up Unit Of Measure Codes for more information.

And finally, let's consider a rate that has a charge for "annual highest KW (demand) during peak hours". This is a very complicated thing to price. You have several options in respect of the combination of UOM, TOU, SQI to use to express this unit. The following table contains every conceivable combination to express this single thing:

Option

UOM

TOU

SQI

1

KW

PEAK

ANNHIGH - Annual Highest

2

KW

PEAKANHI - Peak Annual Highest

3

ANHIPKKW - Annual Highest Peak KW

4

KWAP - KW Annual Highest Peak

5

KW

AHPEAK - Annual Highest Peak

Note:

Rule Of Thumb. We strongly recommend using an SQI to identify things not measured by your meters. This means that you shouldn't use the last two options in the above table. Of the first 3 options, the choice is yours. It's really a question of how you prefer to record your billed consumption.

Fastpath:

For more information about UOM, TOU, and SQI, refer to Setting Up Unit Of Measure Codes , Setting Up Time Of Use Codes , and Defining Service Quantity (SQ) Identifiers . For more information about charging for units that are not measured by your meters, refer to Defining Measured Quantity Manipulation Rules.

Defining Measured Quantity Manipulation Rules

This section describes when and how you have the system manipulate measured consumption before it is applied to the charges in a rate.

Warning:

Quantity manipulation rules exist to support calculations performed by rate components. This means that you must design your rate components before you can design your quantity manipulation rules. We strongly recommend that you design "on paper" how every rate's rate components looks before you attempt to set up these rules.

Contents

When And How To Manipulate Measured Consumption

Setting Up Register Rules

Setting Up Service Quantity (SQ) Rules

When And How To Manipulate Measured Consumption

Many rates calculate charges based on measured consumption. For example, a simple electric rate has a price expressed as an amount per kilowatt-hour (kWh) and the customer's meter measures kWh. However, other rates contain charges for things that aren't measured directly by the customer's meters. Examples include the following:

- Most gas meters measure consumption in cubic feet, but the charges in gas rates are expressed in therms.

- A customer's service agreement may indicate that the number of kilowatts billed per month will be the greater of the measured kilowatts OR the minimum number of kilowatts as defined in the service agreement.

- A customer's meter may only contain two registers: one that measures kWh consumed during peak hours, and another that measures kWh consumed during off peak hours. However, there are charges in the rate based on the total kWh consumed regardless of when the power was used.

All of these examples share the same trait: the unit of measure being priced is not the same as the unit of measure being measured. If any of your rates possess this trait, then you have to tell the system about it so that it knows to perform extra manipulations before it calculates charges.

So, how do you tell the system to manipulate measured consumption? You have two options:

- Create a Service Quantity (SQ) Rule and link it to the rate schedule

- Create a Register Rule and link it to the rate schedule

When a rate schedule has either type of rule, the system executes the rule's algorithm immediately before it calculates charges. The rule's algorithms manipulate measured consumption so that the rate is supplied with consumption in the manner that it expects.

You must understand the difference between these two types of rules before you can set them up. The following diagram describes how the two types of rules are used and this should help you understand the differences between them:

Note:

Bottom line. Register rules are used when your rates require the manipulation of measured consumption and this manipulation requires attributes directly related to either the service point, the meter or the premise. SQ rules also manipulate measured consumption. However, this manipulation is done without regard to the individual service points or meters.

The following table defines which type of rule would be used for each of the earlier manipulation examples:

Situation

Type of Rule

Explanation

Cubic Feet (CCF) to Therm conversion

Register rule

A register rule is used because a given bill could contain many registers that measure CCF and each register could have a different therm conversion factor. If an SQ rule was used, a single conversion factor would be applied to the total CCF from all registers.

Minimum contract quantity

SQ rule

An SQ rule is used because we want to add together the total amount of consumption from all registers and then compare it to a contract quantity.

Add together peak and off peak consumption

SQ rule

An SQ rule is used because we want to add together the total amount of consumption from all registers.

Setting Up Register Rules

Warning:

Do NOT attempt to set up register rules until you have a very good understanding of what your meters measure and how your rates charge for this consumption. In addition, you should completely understand the concepts described in When And How To Manipulate Measured Consumption before creating these rules.

To set up register rules, choose Admin Menu, Register Rule.

Description of Page

Enter a unique Register Rule ID and a Description for the register rule.

Enter Comments that describe, in detail, what the rule does.

Select the Algorithm that controls how the system manipulates the consumption supplied to the rate. Define the Parameters to be used by the register algorithm.

The following table indicates the algorithms that are supplied with the system, its Algorithm Type and how each register algorithm uses its parameters.

Contents

Base Package Register Rules

How To Setup A Register Rule To Adjust A Cubic Foot Of Gas Based On Pressure

How To Set Up A Register Rule To Convert Cubic Feet To Therms

How To Set Up A Register Rule To Price Interval Consumption Using Interval Prices

Base Package Register Rules

Note:

If the register rule algorithms that are supplied with the base package are not sufficient for your rating requirements, you will have to write a new register rule algorithm. Refer to How To Add A New Register Rule for how to do this.

Register Algorithm

Alg Type

What It Does

Parameters Used

Bill Factor Based UOM Conversion

BU

Converts a measured quantity into a final quantity using the value specified on a bill factor.

Final Quantity (expressed in the UOM in param 2) =

Quantity for UOM (in param 1) *

Value for Bill Factor (in param 3)

This algorithm would be useful when you need to convert cubic feet (CCF) into therms based on the takepoint from which the premise gets its gas.

Param 1 = Measured UOM

Param 2 = Final UOM

Param 3 = Bill Factor containing conversion factor

Real Time Pricing

RT

Converts a measured quantity (UOM) into a final quantity (Result SQI) by multiplying the measured quantity by the price (Bill Factor) effective on the read's start date/time.

Final Quantity (expressed in the SQI in param 3) =

Quantity for UOM (in param 1) *

Value for Real Time Bill Factor (in param 2)

Note, this option is useful if you have simple real time pricing algorithms and do not use the interval billing subsystem. Refer to Pricing Interval Consumption Using Interval Prices for more information.

Param 1 = UOM

Param 2 = Bill Factor

Param 3 = Resultant SQI

Seasonal Register TOU Conversion

ST

Converts time-of-use codes of "current season" and "prior season" to "winter" and "summer" based on the billing period.

Summer Begin Date contains the MMDD when summer starts. Winter Begin Date contains the MMDD when winter starts. Current Season TOU contains the TOU code of the register that measures the current season's consumption. Prior Season TOU contains the TOU code of the register that measures the prior season's consumption. Winter TOU contains the TOU code to be used for winter consumption (the register read's TOU code is changed to this for winter consumption). Summer TOU contains the TOU code to be used for summer consumption (the register read's TOU code is changed to this for summer consumption).

Param 1 = Summer Begin Date (MMDD)

Param 2 = Winter Begin Date (MMDD)

Param 3 = Current Season TOU

Param 4 = Prior Season TOU

Param 5 = Winter TOU

Param 6 = Summer TOU

For more information about defining algorithm types, refer to Setting Up Algorithm Types .

Where Used

A primary Rate Schedule may have zero or more register rules. Refer to Rate Schedule - Register Rules for more information.

How To Setup A Register Rule To Adjust A Cubic Foot Of Gas Based On Pressure

Refer to Gas Pressure Factor Adjustments for an example.

How To Set Up A Register Rule To Convert Cubic Feet To Therms

Let's assume a gas rate contains therm-oriented charges, but the customer's meters only measure in cubic feet. This means that you will need a register rule to convert the measured consumption into therm-oriented consumption.

The following table shows the array that will be supplied to the rate assuming the customer's meter measures CCF:

Unit Of Measure

Time Of Use

Measured Quantity

Final Quantity

CCF

1000

1000

Now, let's assume the rate contains charges based on therms. This means that the rate needs to have the array changed as follow:

Unit Of Measure

Time Of Use

Measured Quantity

Final Quantity

CCF

1000

1000

TH

1010

As you can see, a new entry was added to the array. This new entry contains the amount of therms associated with the measured CCF. To do this you would need to create a register rule with the following attributes (and link it to the appropriate rates):

Field

Value

Register Algorithm

Bill factor based UOM conversion

UOM (Source)

CCF

UOM (Result)

TH

Bill Factor

CCFCONV

In addition, you will also have to set up the following bill factor and characteristic information:

- Add a characteristic type to define your various take points (call it, TAKEPT). Indicate this characteristic is specified on premises.

- Define characteristic values for the take point characteristic. These will be the take points in your service area.

- Add the bill factor you identified in the register rule (i.e., CCFCONV). Indicate that the type of characteristic to use is the take point characteristic type (i.e., TAKEPT). Add bill factor characteristics for each take point.

- Add a bill factor value for each bill factor characteristic. This value will contain the CCF to therm conversion factor to be used for the specific take point.

- Update the relevant postal defaults so that the appropriate take point will default onto your premises.

- Update existing premises with their respective take point (by specifying the appropriate characteristic value for the take point characteristic).

Fastpath:

For more information about bill factors and characteristics, refer to Setting Up Bill Factors and Setting Up Characteristic Types & Their Values .

How To Set Up A Register Rule To Price Interval Consumption Using Interval Prices

Refer to Pricing Interval Consumption Using Interval Prices for an example.

Setting Up Service Quantity (SQ) Rules

Warning:

Do NOT attempt to set up SQ rules until you have a very good understanding of what your meters measure and how your rates charge for this consumption. In addition, you should completely understand the concepts described in UOM versus TOU versus SQI before creating these rules. In addition, you should completely understand the concepts described in When And How To Manipulate Measured Consumption before creating these rules.

To set up Service Quantity (SQ) rules, choose Admin Menu, Service Quantity Rule.

Description of Page

Enter a unique SQ Rule ID and a Description for the SQ rule.

Enter a Long Description that describes, in detail, what the rule does.

Indicate the UOM, TOU and SQI to be output by the rule.

Every service quantity supplied to a rate has two quantities - the amount of service as it was initially measured, and the amount of service that should be priced by the rate. Most of the time, these two amounts will be the same. They will only differ when another SQ Rule has executed and caused the billable quantity to change (an SQ Rule NEVER changes initially measured quantities). Because these two amounts may differ, an SQ Rule needs to know if it should use the quantity as initially measured OR if it should use the quantity that will be priced in the rate. You use the SQ 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 SQ Rule is not able to execute successfully. For most SQ 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 customer base using the rate, you may not want a billing error to be issued if the rule cannot execute. For example, consider a rule used to derive total kWh by adding together peak kWh and off-peak kWh. You would only use such a rule if you measured peak and off-peak consumption, but you had prices in respect of total consumption. In the situation where this SQ Rule was linked to a rate used by customers with and without time-of-use meters, you would not want the system to issue a billing error for those customers without time-of-use meters (because their meter already measures total consumption).

Use SQ Rule Processing to indicate if the SQ rule is Always executed by rate application, even if the consumption details on the original bill segment are to be used when the system recalculates a bill segment (refer to Rebill (Bill Segment)). If the SQ rule should not be executed when the consumption details on the original bill segment are used, indicate that the SQ rule should only be executed on the Initial SQ Calculation . SQ rules that create a characteristic type / value (in the characteristic collection) used by one or more bill factors referenced in a rate component should typically be always executed. Refer to Base Package SQ Rules for examples of SQ rules that create a characteristic type / value.

Select the SQ Algorithm Type that controls how the system manipulates the consumption supplied to the rate. Define the Parameters to be used by the SQ algorithm.

Contents

Base Package SQ Rules

How To Set Up An SQ Rule To Add Together Two Service Quantities

Base Package SQ Rules

The following table describes the SQ rule algorithms that are supplied with the system.

Note:

If the algorithms described below are not sufficient for your rating requirements, you must write a new SQ rule algorithm. Refer to How To Add A New SQ Rule for how to do this.

SQ Algorithm

Alg Type

What It Does

Parameters Used

Bill Credits for Electric Consolidated Billing

BC

This SQ rule creates a Characteristic Type / Value to handle consolidated billing credits. These values are used by one or more bill factors referenced in the rate components to vary the amount associated with a given bill line.

The characteristic type and value are generated if a service provider (SPr) provides consolidated billing for its customer. These credits are applied irrespective of whether the SPr provides full or partial consolidated billing and whether or not the customer takes both gas and electric services.

SA Relationship Type tells the system the type of SA relationship (e.g., energy service provider versus meter agent) that is interrogated.

Service Type tells the system the service type associated with electricity (as the characteristic value returned differs for electric-only service providers).

The Characteristic collection will be updated with the Characteristic Type and an appropriate Value as follows:

- BR Dual Commodity Value if the SPr provides bill ready consolidation for more than one service

- BR Electric Only Value if the SPr provides bill ready consolidation for electric only

- RR Dual Commodity Value if the SPr provides rate ready consolidation for more than one service

- RR Electric Only Value if the SPr provides rate ready consolidation for electric only

Param 1 = SA Relationship Type

Param 2 = Service Type for Electric

Param 3 = Characteristic Type - Billing Credit

Param 4 = Characteristic Value - BR Dual Commodity Value

Param 5 = Characteristic Value - BR Electric Only Value

Param 6 = Characteristic Value = RR Dual Commodity Value

Param 7 = Characteristic Value = RR Electric Only Value

Bill Credits for Gas Consolidated Billing

CT

This SQ rule creates a characteristic type / value if a service provider provides consolidated billing for the customer being billed. These values are used by one or more bill factors in the rate components to vary the amount associated with a given bill line.

The characteristic type and value are generated if a customer's gas service provider (SPr) provides consolidated billing (i.e., the service provider has a billing relationship of " they bill for us ").

The Service Type tells the system how to identify gas service.

The SA Relationship Type tells the system the type of SA relationship (e.g., energy service provider versus meter agent) that is interrogated.

If the above conditions are true, the Characteristic collection will be updated with the Characteristic Type and an appropriate Value as follows:

- CTA Credit Residential if the customer class matches the Customer Class for Residential

- CTA Credit Non-Residential if the customer class does not match the Customer Class for Residential

Param 1 = Service Type

Param 2 = SA Relationship Type

Param 3 = Customer Class for Residential

Param 4 = Characteristic Type - CTA Credit

Param 5 = Characteristic Value - CTA Credit Residential

Param 6 = Characteristic Value - CTA Credit Non-Residential

Bill days (Days)

DY

This SQ rule calculates the total number of days in the bill period. This algorithm is necessary if you have charges that are based on the number of days of service (e.g., a minimum charge that varies based on the days of service). Refer to Calculated Minimum Charges and Step Boundaries Based On The Number Of Days Of Usage And The Region In Which The Customer Resides for good examples of when to use such an SQ rule.

No parameters are used.

Characteristic Value

CV

This SQ rule creates an entry in the SQ array containing the sum of the characteristic values of a given Characteristic Type. The values are accumulated from the entity defined in the parameter list.

Resulting Quantity (expressed in the Output UOM / TOU / SQI) = the sum of the characteristic values of a given Characteristic Type. Characteristic Source determines the entity that holds the characteristic values:

- If Characteristic Source is"SA", the characteristic value effective on the bill start date for the Characteristic Type (P1) and SA Id is returned.

- If Characteristic Source is "ACCOUNT", the characteristic value effective on the bill start date for the Characteristic Type (P1) and Account Id is returned.

- If Characteristic Source is "PREMISE", the characteristic values are accumulated from all premises linked to the SA ID.

- If Characteristic Source is "SP", the characteristic values are accumulated from all service points linked to the SA ID.

If Minimum Value is greater than zero and the resultant characteristic value is less than the specified Minimum Value, an error is generated.

Param 1 = Characteristic Type

Param 2 = Characteristic Source

Param 3 = Minimum Value

Check Load Factor

LF

This SQ rule generates a To Do entry if a customer's actual demand exceeds a fixed demand amount (and actual kWh exceeds a calculated kWh ).

The actual algorithm is as follows:

Retrieve maximum demand from SQ collection as the greatest of kW/Peak, kW/Part Peak and kW/Off-Peak. If this maximum demand <= Threshold Maximum Demand, escape the routine. If this maximum demand > Threshold Maximum Demand:

- Compute 'Calculated kWh' = Threshold Maximum Demand * total days in bill period, times 24.

- If Actual kWh/'Calculated kWh' > 1, create a To Do Entry (using the To Do Type and To Do Role (if specified)). The base package includes the To Do Type LF to use for this parameter value, unless you've set up your own.

Param 1 = UOM of demand (e.g., KW)

Param 2 = TOU of peak period

Param 3 = TOU of off-peak period

Param 4 = TOU of part peak period

Param 5 = UOM of actual KWH (e.g., KWH)

Param 6 = Threshold maximum demand

Param 7 = To Do Type

Param 8 = To Do Role (optional)

Consumption History

CH

This SQ rule adds an entry in the SQ array that contains a given amount of historical consumption.

This algorithm can return MAX (maximum), MIN (minimum), SUM (total) or AVG (daily average) consumption as defined by the Operator. It retrieves this consumption from the SA's historical bill segments (from the service quantities that are stored on the bill segments).

UOM / TOU / SQI define the type of historical consumption that is retrieved.

The historical period whose consumption is accessed is defined by EITHER:

- Number of Historical Periods (a period is defined by the rate schedule's frequency) or

- • The previous historical season (defined by Start Month/Day and End Month/Day).

PLEASE SPECIFY EITHER OF THE ABOVE PARAMETERS.

Note. If the system finds historical bills with a period outside the normal period for the rate's frequency, proration takes place if the input UOM does not Measure Peak. The algorithm accesses consumption data starting from the most recent bill going backwards. As soon as an irregular bill period is encountered, the system attempts to determine appropriate consumption for a "normal" period by prorating the irregular bill based on actual data from previous bills.

For example, if historic bills for a monthly rate cover

§ Jan 1 - Feb 1

- § Feb 1 - Mar 1

- § Mar 1 - Mar 15

When the next bill is generated, the system attempts to calculate the historic consumption going backwards. It will determine consumption for Feb 15 - Mar 15 by taking the consumption for the March bill and adding consumption the time from Feb 15 to Mar 1 by prorating the consumption on the February bill. Then, it attempts to determine consumption for Jan 15 - Feb 15 by taking the remaining consumption for February and adding consumption from the time from Jan 15 to Feb 1 by prorating the consumption on the January bill, etc. Once enough historical bills have been processed, any days "leftover" from the earliest bill as a result of this proration logic are simply ignored.

If the input UOM measures peak, no proration of historical quantities occurs. If no UOM is specified as input (i.e., only an SQI), the system assumes that the quantity should behave as if it does not measure peak.

Param 1 = Season Start Month / Day (MM/DD)

Param 2 = Season End Month / Day (MM/DD)

Param 3 = Number of Historical Billing Periods

Param 4 = UOM

Param 5 = TOU

Param 6 = SQI

Param 7 = Operator

Contract Quantity

CQ

This SQ rule is used to create an entry in the SQ array for a given Contract Quantity Type specified in a SA. If multiple values are effective during a bill period, the Proration Rule determines what happens. (See below).

Resulting Quantity (expressed in the Output UOM / TOU / SQI) = the value of a given Contract Quantity Type in a SA. If multiple values are effective during a bill period the Proration Rule determines what happens:

- If Proration Rule is 'Use Contract Quantity effective at Beginning of Bill Period' (i.e., CQBD ), SQ Amount = Contract Quantity effective at the start of the bill period.

- If Proration Rule is 'Use Contract Quantity effective at End of Bill Period' (i.e., CQED ), SQ Amount = Contract Quantity effective at the end of the bill period.

- If Proration Rule is 'Maximum' (i.e., CQMA ), SQ Amount = largest Contract Quantity effective in the bill period.

- If Proration Rule is 'Minimum' (i.e., CQMI ), SQ Amount = smallest Contract Quantity effective in the bill period.

- If Proration Rule is 'Prorate' (i.e., CQPR ), SQ Amount = Sum of all prorated contract quantities (calculate the number of days in the bill period (X); calculate the number of days in the bill period that each contract quantity is effective (Y(i)); prorate each contract quantity (i) = (Contract Quantity(i) * Y(i) /X)).

Param 1 = Contract Quantity Type

Param 2 = Proration Rule: CQBD, CQED, CQMA, CQMI, CQPR

Direct Access Credits

CD

This SQ rule creates a characteristic type / value to handle credits issued to the customer for participating in direct access. These values are used by one or more bill factors in the rate components to vary the amount associated with a given bill line.

This rule always creates a characteristic type equal to Characteristic Type DA Credit. The characteristic value will be set as follows:

- If the service agreement being billed has a service agreement relationship with either the ESP Relationship Type or the CTA Relationship Type, a characteristic value of Characteristic Value - DA Customer will be created.

- If not, a characteristic value of Characteristic Value - Non DA Customer will be created.

Param 1 = ESP Relationship Type

Param 2 = CTA Relationship Type

Param 3 = Characteristic Type - DA Credit

Param 4 = Characteristic Value - DA Customer

Param 5 = Characteristic Value - Non DA

Early Pay

EP

This SQ rule is only used if you provide customers with early payment discounts via a discount on their next bill segment. This rule works as follows:

- First, it determines if the prior bill segment's bill was paid before its due date. It does this by retrieving the customer's balance as of the prior bill's due date - 1 day. If this amount is <= zero, it checks if a payment exists with a payment date on or after the bill's bill date and before the bill's due date. If yes, processing continues.

- A characteristic type / value is created where the value holds the number of days early (and the characteristic type is equal to Char Type - Number of Days Early).

- In addition, this routine accumulates the sum of the bill lines on the prior bill segment for which the early payment discount is eligible. It does this by accumulating all bill lines that reference a given characteristic type and value (where characteristic type is equal to Char Type - Eligible For Early Pay Disc, and Char Value - Eligible For Early Pay Disc). It populates the total amount in the service quantity defined on the SQ rule. This means that you must define this characteristic type / value on each rate component whose resultant value is eligible to receive an early payment discount.

This rules anticipates the early pay discount being levied using two rate components:

- The first would be an FCPO rate component that holds the amount eligible to receive the discount. This would be an SQ rate component where the service quantity is the value produced by this SQ rule, and the price would be 1 (or -1). In addition, this rate component would need eligibility rules so that it is only applied if the number of days early (held in the characteristic type / value produced by this algorithm) is > 0.

- The second would be an "apply to" rate component (where the apply to value is a percentage applied to the first rate component). In addition, this rate component would need eligibility rules so that it is only applied if the number of days early is within a certain tolerance (e.g., > 0). You could create several of these types of rate components if the discount percent differs based on the number of days early.

Param 1 = Char Type - Number of Days Early

Param 2 = Char Type - Eligible For Early Pay Disc

Param 3 = Char Value - Eligible For Early Pay Disc

Mathematical Functions

MA

This SQ rule performs mathematical functions on service quantities prior to rate application.

There are three major groups of parameters:

1) Quantity 1 (identified by a service quantity's UOM/TOU/SQI).

2) Mathematical operand

3) Quantity 2 (identified by a service quantity's UOM/TOU/SQI or a Bill Factor)

For example, if you want to add together two SQ entries, these values would contain:

1) the unique identifier of one of the SQ's (in parameters 1 through 3)

2) the "+" symbol (in parameter 4)

3) the unique identifier of the other SQ (in parameters 5 through 7)

It should be stressed that Quantity 2 can either reference a bill factor (param 8) or an SQ entry (parameters 5 through 7). If both are specified, the bill factor is used.

The two default values (param 9 and param 10) are only used if Quantity 1 and/or Quantity 2 reference SQ's / bill factor that are not present at billing time. There are three ways to use these default values:

- If you want to multiply a SQ by a constant value, define the SQ in Quantity 1 and the constant value in Param 10, i.e., you don't have to specify anything in Param's 5 through 8.

- If you want a default value used if the system cannot find a SQ that matches the UOM/TOU/SQI, define this value in Param 9 and/or Param 10.

- If you use a bill factor to define Quantity 2 (in Param 8) and you want a default value used if the system cannot find a char type / value for a specific customer, the default value is defined in Param 10.

The following mathematical operands use only Quantity 1.

ABS, NEGATE, ROUND, FLOOR (meaning to round down), CEILING (meaning to round up), SIN, ASIN, COS, ACOS, TAN, ATAN, LOG, LOG10, EXP, EXP10, SQRT

The following mathematical operands use both Quantity 1 and Quantity 2:

+, -, *, /, **, MOD, <, <=, >, >=, =, <>, MAX, MIN, AVG

The following mathematical operands use both Quantity 1 and Quantity 2 and return a value of 1 if the comparison is true and a value of 0 if the comparison is false:

<, <=, >, >=, =, <>

Quantity 1:

Param 1 = UOM of service quantity entry

Param 2 = TOU of service quantity entry

Param 3 = SQI of service quantity entry

Or

Param 9 = Decimal number

Mathematical Operand:

Param 4 = operand symbol (i.e., +, -, *, /)

Quantity 2:

Param 5 = UOM of service quantity entry

Param 6 = TOU of service quantity entry

Param 7 = SQI of service quantity entry

Or

Param 8 = Bill factor ID

Or

Param 10 = Decimal number

Maximum Service Quantity

MQ

This SQ rule compares a quantity (either measured or created via a previous SQ rule) against a contract quantity and returns whichever is larger.

Resulting Quantity (expressed in the Output UOM / TOU / SQI) =

greater of quantity for UOM / TOU / SQI

OR

service agreement quantity for Contract Quantity Type

Param 1 = UOM

Param 2 = TOU

Param 3 = SQI

Param 4 = Contract Quantity Type

Meter Ownership

MO

This SQ rule returns SQI = number of meters that are not owned by the company per day.

It applies if a service provider owns a direct access customer's meter or a customer owns its own meter.

The system expects an SA Relationship to exist with the Meter Ownership/Services Relationship Type. If a Relationship exists where the service provider is a third party, the number of meters linked to this SA is counted and returned.

Param 1 = Meter Ownership/Services Relationship Type

Meter Service Credits

MD

This SQ rule creates a characteristic type / value to handle credits issued to the customer because a customer's meter is read by a 3 rd party service provider. These values are used by one or more bill factors in the rate components to vary the amount associated with a given bill line.

It applies if a service provider (SPr) provides meter reading services for its customer. These credits are applied irrespective of whether or not the customer takes both gas and electric service and the method the SPr uses to read the meter.

Meter Reading Relationship Type tells the system the type of SA relationship (e.g., energy service provider versus meter agent) that is interrogated.

Service Type tells the system the service type associated with electricity (as the characteristic value returned differs for electric-only service providers).

The Characteristic collection will be updated with the Characteristic Type and an appropriate Value as follows:

- MDMA Dual Commodity Value if the ESP provides meter reading for more than one service

- MDMA Electric Only Value if the ESP provides bill ready consolidation for electric only

Param 1 = Meter Reading Relationship Type

Param 2 = Service Type for Electric

Param 3 = Characteristic Type - MDMA Credit

Param 4 = Characteristic Value - MDMA Dual Commodity Value

Param 5 = Characteristic Value - MDMA Electric Only Value

Number of Meters

NM

This SQ rule calculates the number of meters (actually service points) linked to the service agreement.

No parameters are used

Power Factor

PF

This SQ rule calculates power factor. It will also create a To Do entry if the resultant power factor exceeds a user-defined threshold value.

Resulting Quantity (expressed in the Output UOM / TOU / SQI) = Average Power Factor Percentage (N3 format, no decimals) = COSINE (ARCTANGENT (value of UOM4/TOU5/SQI6 / value of UOM1/TOU2/SQI3)) * 100

If the calculated power factor exceeds Power Factor Threshold Percent, a To Do entry is created (using the To Do Type and To Do Role). The base package includes the To Do Type PF to use for this parameter value, unless you've set up your own.

Service Quantity ID of kWh

- Param 1 = UOM1

- Param 2 = TOU1

- Param 3 = SQI1

Service Quantity ID of kVARh

- Param 4 = UOM2

- Param 5 = TOU2

- Param 6 = SQI2

Param 7 = To Do Type

Param 8 = To Do Role

Param 9 = Power Factor Threshold Percent

Required UOM/TOU Validation

RP

This SQ rule verifies if one UOM/TOU quantity is non-zero then the other should be non-zero too.

UOM1/TOU1/SQI1 is the ID of the first SQ entry. UOM2/TOU2/SQI2 is the ID of the second SQ entry.

Service Quantity ID1

- Param 1 = UOM1

- Param 2 = TOU1

- • Param 3 = SQI1

Service Quantity ID2

- Param 4 = UOM2

- Param 5 = TOU2

- Param 6 = SQI2

Season Days

SD

This SQ rule is used to create an entry in the SQ array that contains the number of days in the current bill period that fall in a defined season.

Resulting Quantity (expressed in the Output UOM / TOU / SQI) = number of days in the current bill period that fall in Season Start and Season End. For example, if bill period = 03/15/99 to 04/15/99 and Season Start date = 04/01 and Season End date = 10/31, then resulting quantity = 15.

Param 1 = Season Start (MMDD)

Param 2 = Season End (MMDD)

Seasonal Usage

SU

This SQ rule is responsible for taking a non-seasonal UOM/TOU/SQI and producing a seasonal UOM/TOU/SQI, depending on the bill period. For example, if you have a meter which only measures on and off peak consumption, but a rate that bills for summer on peak and summer off peak consumption, then this rule will be used.

Resulting value = value of UOM1/ TOU1/ SQI1 * (value of UOM2/ TOU2/ SQI2 / value of UOM3/ TOU3/ SQI3)

Normal consumption

Param 1 = UOM1

Param 2 = TOU1

Param 3 = SQI1

Number of days in the season

Param 4 = UOM2

Param 5 = TOU2

Param 6 = SQI2

Number of days in the billing period

Param 7 = UOM3

Param 8 = TOU3

Param 9 = SQI3

Sum

SM

This SQ rule adds up several quantities (either measured or created via a previous SQ rule). This algorithm would be useful when you need to add together "time-of-use" registers because there are charges in the rate that are for the total amount of consumption regardless of when it was used.

Resulting Quantity (expressed in the Output UOM / TOU / SQI) =

Quantity for UOM (in param 1) TOU (in param 2) SQI (in param 3) +

Quantity for UOM (in param 4) TOU (in param 5) SQI (in param 6) +

Quantity for UOM (in param 7) TOU (in param 8) SQI (in param 9)

Quantity 1

Param 1 = First UOM

Param 2 = First TOU

Param 3 = First SQI

Quantity 2

Param 4 = Second UOM

Param 5 = Second TOU

Param 6 = Second SQI

Quantity 3

Param 7 = Third UOM

Param 8 = Third TOU

Param 9 = Third SQI

For more information about defining algorithm types, refer to Setting Up Algorithm Types .

Where Used

A Rate Schedule may have zero or more SQ Rules. Refer to Rate Schedule - SQ Rules for more information.

How To Set Up An SQ Rule To Add Together Two Service Quantities

Let's assume the rate contains charges based on the TOTAL amount of kilowatt hours (i.e., there is a price expressed per kWh with no TOU or SQI). However, some customers who use this rate have time-of-use meters that measure kWh in respect of peak and off-peak hours (i.e., the meters have two registers where one measures kWh peak and the other measures kWh off-peak). This means that you will need an SQ Rule to add together the two measured service quantities to derive total kWh.

The following table shows the array that will be supplied to the rate assuming the customer's meter measures kWh peak usage and kWh off peak usage:

Unit Of Measure

Time Of Use

SQ Identifier

Initial Quantity

Billable Quantity

KWH

PEAK

1000

1000

KWH

OFFPEAK

800

800

Now, let's assume the rate contains charges based on the TOTAL amount of kilowatt hours (i.e., the sum of KWH PEAK and KWH OFFPEAK). This means that the rate needs to have the array changed as follow:

Unit Of Measure

Time Of Use

SQ Identifier

Initial Quantity

Billable Quantity

KWH

PEAK

1000

1000

KWH

OFFPEAK

800

800

KWH

1800

As you can see, a new entry was added to the array. This new entry contains the sum of two existing service quantities. Notice that the new entry doesn't have an initial quantity. This is because an SQ Rule will create it and SQ Rules never populate initial quantity (only metered consumption can exist in initial quantity). To add this new entry, create an SQ Rule with the following attributes (and link it to the appropriate rates):

Field

Value

SQ Algorithm

Sum

UOM 1

KWH

TOU 1

PEAK

SQI 1

UOM 2

KWH

TOU 2

OFFPEAK

SQI 2

UOM 3

TOU 3

SQI 3

Quantity to Use

Billable Quantity (actually, it doesn't matter because both the Billable and Initial Quantities will contain the same value in this scenario).

Create a Billing Error

It depends on your situation. If all customers using this rate have time-of-use meters that need to be summed together to come up with the total kWh, then you'd want to create a billing error if the system is not supplied with the appropriate service quantities. If some customers using this rate have time-of-use meters and others just have summary meters that don't differentiate based on time-of-use, you would NOT select this option because you wouldn't want a billing error generated for customers without a time-of-use meter.

Defining Service Quantity (SQ) Identifiers

Consider a rate that contains a charge per "meter day" where the total number of meter days equals the number of days in the billing period multiplied by the number of customer-owned meters at the premise. At billing time, you'd need an SQ Rule to count the number of customer-owned meters and multiply this value by the number of days in the billing period. You could instruct the SQ Rule to place the resultant number of meter days in some unit of measure (meaning you'd have to create a UOM called "meter day"). Alternatively, you could instruct the SQ Rule to place the resultant number in a service quantity identifier (SQI) (meaning you'd have to create an SQI called "meter day"). The choice is yours. As a rule of thumb, we'd recommend creating an SQI for those things that are not measured by a meter.

Warning:

SQIs exist to support calculations performed by rate components. This means that you must design your rate components before you can design your service quantity identifiers. We strongly recommend that you design "on paper" how every rate's rate component looks before you attempt to set up your SQIs.

Note:

If you create an SQI, you must also have a corresponding SQ Rule to calculate the amount of the SQI to be priced by the rate. If not, it is impossible for the system to generate a bill line for the SQI because there will be no quantity associated with the SQI.

To define service quantity identifiers, open Admin Menu, Service Quantity Identifier.

Description of Page

Enter a unique Service Qty. Identifier and Description for every SQI.

Enter the appropriate number of Decimal Positions for each SQI. The rate application process uses this information to round the calculated service quantity prior to applying appropriate rate components.

Where Used

An SQ Rule may use an SQ Identifier to describe what it generates. Refer to Setting Up Service Quantity (SQ) Rules for more information.

A Service Quantity Rate Component may use an SQ Identifier to describe what it is pricing. In this situation, the rate must contain an SQ Rule that generates a quantity for this SQI; otherwise there will be a price without a service quantity. Refer to Rate Component - Main Information for more information.

Setting Up A Rate Schedule

A primary rate schedule is setup for every rate that you offer to your customers. A subsidiary rate schedule is setup to encapsulate common rate components shared by multiple primary rate schedules. 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.

Contents

Rate Schedule - Main

Rate Schedule - SQ Rules

Rate Schedule - Register Rules

Rate Schedule - Bill Messages

Rate Schedule - Meter Configuration Type

Rate Schedule - Sub Rates

Rate Schedule - Main

You start the rate definition process by selecting Main Menu, Rates, Rate Schedule. On this page 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 Rate Schedule Type that applies to the rate schedule. Rate schedules can be either Primary or Subsidiary. Primary rate schedules are the main type of rate schedule used to calculate charges and bills for customers. Subsidiary rate schedules can be used to define rate components that are shared by more than one primary rate. For example, if an organization has multiple rate schedules that reference the same tax rate components, these tax rate components could be placed into a subsidiary rate which the primary rates would reference. Note that subsidiary rate schedules may not be referenced on service agreements, or defined as default rate schedules on SA Types. See Use Sub Rate Schedules to Encapsulate Common Rate Components for more information about subsidiary rate schedules.

Note:

Service Type, Frequency, Currency Code and Allow Estimates defined for the primary rate schedule are used to drive the calculations at billing time and may not be specified on subsidiary rates

Select the Service Type that describes the service 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 SA Type. See Setting Up Service 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.

Note:

Frequency may also affect the read used to bill a customer. If you use the base package's get consumption algorithm to amalgamate reads during billing, the rates frequency also affects whether a bill segment is created AND the period of time during which the system will look for an "end read". Refer to Meter Read Snapshot for more information.

Select a Currency Code to define the currency in which the rate's prices are expressed. See Defining Currency Codes for more information.

Note:

Currency note. All bill 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 bill factors are used when the price is "soft" and all prices in a rate, be they hard or soft, must be in the same currency. Also note - all rates referenced on an account's service agreements must be denominated in the same currency as defined on the account.

Turn on Allow Estimates if the bill process is allowed to estimate consumption for service agreements that use this rate. Consumption is estimated if all of the following points are true:

- A real read cannot be found.

- The service agreement allows estimation.

- The bill cycle schedule allows estimation (if the bill is produced by the BILLING background process).

- The rate schedule allows estimation.

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 SQ Rules, Register Rules, Rate Versions, and Primary/Sub Rates (primary rate schedules list any linked sub rates including the sub rates SQ Rules, Rate Versions, etc.; subsidiary rate schedules list any linked primary rates). 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.

Where Used

Most SA Types contain a collection of valid Rate Schedules. Refer to SA Type - Rate for more information.

Most Service Agreements reference a Rate Schedule. Refer to Service Agreement - Rate Info for more information.

Rate Schedule - SQ Rules

When a rate contains prices for things that aren't measured directly by the customers' meters, you must link SQ Rules to the rate. When a rate schedule has SQ Rules, the system executes each rule's algorithm before it calculates the charges embodied in the rate's rate components. These SQ Rules manipulate measured consumption so that the rate is supplied with consumption in the manner that it expects. Open Rates, Rate Schedule and navigate to the SQ Rule to link SQ Rules to a rate.

Fastpath:

For more information , refer to Setting Up Service Quantity (SQ) Rules .

Note:

. The Rate Schedule Merge page enables you to build the SQ rule collection for your rate schedule by copying collections from existing rate schedules.

Description of Page

Enter a Service Quantity Rule for every type of service 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

Billing uses this information to create additional service quantities at billing time.

Rate Schedule - Register Rules

When a meter measures something in a unit of measure that has to be converted into a different unit of measure before it can be rated, you must link register rules to the rate. A good example is when a meter measures gas in cubic feet, but the rate contains prices in therms.

When a rate schedule has register rules, the system executes each rule's algorithm before it calculates charges. These register rules convert measured consumption so that the rate is supplied with consumption in the manner that it expects.

Fastpath:

For more information about register rules, refer to Setting Up Register Rules .

Note:

. The Rate Schedule Merge page enables you to build the register rule collection for your rate schedule by copying collections from existing rate schedules.

Select Main Menu, Rates, Rate Schedule and navigate to the Register Rule to link register rules to a rate.

Description of Page

Enter a Register Rule for every type of register rule to be executed before consumption is rated. 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.

Note:

Register Rules are not allowed onsubsidiary rate schedules.

Where Used

Billing uses this information to create or adjust service 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.

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.

Select Main Menu, Rates, Rate Schedule and navigate to the Bill Messages to link bill messages to a rate.

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 - Meter Configuration Type

Note:

. The Rate Schedule Merge page enables you to build the meter configurations collection for your rate schedule by copying collections from existing rate schedules.

Select Main Menu, Rates, Rate Schedule and navigate to Meter Configuration Type to define the types of meters that may be linked to service agreements that use this rate.

Description of Page

Use the Meter Configuration Type collection to define the recommended meter configuration types for meters linked to service agreements (by way of their service points) for a given rate schedule.

Note:

Meter Configuration Types are not allowed on subsidiary rate schedules.

Where Used

This information is used by the system to verify that meter configuration types for any meters linked to the SA's service points are valid for the SA's rate. This check exists when you change the rate for a service agreement or when you change the meter configuration type of a meter configuration that is currently linked to an active SA (via the meter and the SP). Note that if a meter configuration for the SA's service point's meter does not match one of the types in the list, a warning is issued, not an error.

Rate Schedule - Sub Rates

Select Main Menu, Rates, Rate Schedule and navigate to Sub Rates to define any subsidiary rate schedules associated with the current (primary) rate schedule.

Note:

. Sub Rates are only allowed on Primary rate schedules. See Use Sub Rate Schedules to Encapsulate Common Rate Components for more information about subsidiary rate schedules.

Description of Page

Use the Sub Rate Schedule collection to define the subsidiary rate schedules linked to the current rate schedule.

The Sequence is important when you have multiple sub rates linked to the primary rate, as it defines the order in which the sub rates will be calculated.

Where Used

At billing time, if there are sub rate schedules linked to the service agreement's primary rate schedule, rate components defined in the sub rate schedules are used to calculate charges. Bill segments contain separate bill calculation details for each primary rate schedule and sub rate schedule used in its calculation.

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 SQ rule, register rule, bill message and meter configuration type 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 offer a rate to your customer, which contains many optional components. Rather than building a generic rate schedule used by many customers, and using other logic to determine which options are applicable to which customer, you may choose to build a custom rate schedule for each customer, using only the components applicable to that customer. In this scenario, you may choose to create special 'mini' rate schedules, one for each of the various 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.

Open Main Menu, Rates, Rate Schedule Merge Classic 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 SQ Rule collection initially displays existing SQ 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 SQ 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 Register Rule collection initially displays existing register 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 Register 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 left portion of the Meter Configuration collection initially displays existing meter configuration records 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 Meter Configuration is displayed. In the right portion of the collection, the existing records in the merge from rate are displayed initially.

The topics, which follow, describe how to perform common maintenance tasks:

Contents

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 SQ Rule and Register 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.

You may also need to renumber the sequences so that your rules are executed in the proper order. The fields Start from sequence number and Increment By are used to define the sequence number to assign to the first rule and the subsequent values to assign to subsequent rules.

Note:

that once the record is saved, both register rules are marked as Original .

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 Bill Factors

This section describes bill factors and how they are used to levy the many charges referenced in a rate.

Warning:

Most bill factors exist to support calculations performed by rate components. This means that you must design your rate components before you can design your bill factors. We strongly recommend that you design "on paper" how every rate's rate components looks before you attempt to set up bill factors.

Contents

An Overview Of Bill Factors

The Structure Of A Bill Factor

An Illustration Of A Bill Factor And Its Characteristics

Deriving / Passing In Characteristic Values

Bill Factor Interval Values

Bill Factor TOU Values

Defining Bill Factors

Defining Bill Factor Values

Defining Interval Values

Bill Factor Interval Values Query

Upload Interval Values

Defining Bill Factor TOU Values

An Overview Of Bill Factors

The primary reason why rate components exist is to define how much to charge for the services sold by your company. When you create rate components, you have four ways to indicate how much to charge:

- Specify the value directly in the rate component.

- Tell the rate component to use the value defined in a bill 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 get the price.

The remainder of this section describes the bill factor approach. The other methods are discussed in Designing Rate Components and in Rate Examples.

Bill 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 bill 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 bill factors to define any of the following types of charges:

- A flat amount. This would typically be used to define service charges, minimum charges, and asset charges.

- An amount for a given unit of measure. This would typically be used to define the price for measured consumption (e.g., the price per therm).

- A percentage. This would typically be used for tax rates and discount percents.

As a rule of thumb, you would use a bill factor (rather than specify the value in the rate component) when any of the following situations exist:

- The same charge exists in many rates. For example, if there are 3 rates that all contain the same service charge, it would make sense to use a bill factor to levy this charge rather than specify the same value on 3 rate components.

- The amount being charged is dependent on some physical characteristic of the customer's equipment. For example, if the price differs depending on whether the customer owns the transformer, you would use a bill factor to specify the price.

- The amount being charged is dictated by some external organization and therefore can change independently from the rate. For example, tax percentages and use fees are set by 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 customer lives. If you have a rate where the price per gallon differs depending on where the customer lives, you should use a bill factor to levy this type of charge.

- A charge (or discount) is only levied for a subset of customers for defined periods of time. For example, if you have a discount that is only given to customers who have had service for more than 2 years, you would use a bill factor to specify the discount percent.

- The price differs per customer. For example, you may have a rate for large gas customers where the price per therm is different for every customer. In this situation, you would use a bill factor to specify the price.

- The price differs based on the number of weeks of consumption. This typically occurs in a deregulated environment when the price charge is based on the weighted average spot market price in effect during the bill period. Refer to Interval Prices Can Be Used For More Than Interval Prices for more information.

Warning:

As you can deduce, bill 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 pricing and taxation provisions in ALL of your rates. Only then can you make logical and pragmatic decisions in respect of the number and type of bill factors.

The Structure Of A Bill Factor

All bill factors share a common structure as illustrated below:

The above example shows a standard bill factor made up of the following tables:

- A bill factor contains descriptive information and attributes that control how the bill factor may be used in the system.

- All bill factors have the capability of having different values depending on some characteristic of the premise or service point. For example, a bill factor used to levy a state tax would have a different tax rate depending on the state in which the customer resides. A bill factor characteristic must exist for every state with a tax (states without a tax will not be linked to the state tax bill factor). At billing time, if the system cannot find a bill factor characteristic that corresponds with the customer's state of residence, the charge will be skipped.

- And finally, each bill factor characteristic may have many bill factor values over time. To continue with our state tax example, each state with a tax can have different tax rates over time. There are different ways in which a bill factor's values may be defined:

- For bill factors whose values are applicable to many customers where only one value is effective on a given date, e.g., a city tax, the values are defined using bill factor values. Refer to Defining Bill Factor Values for more information.

- For bill factors whose values are applicable to many customers where more than one value is effective on a given date, e.g., an interval price or a weighted average price, the values are defined on an interval value set. Refer to Defining Interval Values for more information about interval value sets.

- For bill factors that define values for a collection of time of use codes for a given date, the values are defined using bill factor TOU values. Refer to Bill Factor TOU Values for more information about TOU values.

- For bill factors whose value differs per customer, the value is defined in the customer's service agreement. Refer to Service Agreement - Contract Value for more information about bill factors in contract terms.

An Illustration Of A Bill Factor And Its Characteristics

The following picture illustrates how a bill factor and its characteristics are used to retrieve the relevant state 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 charges for a customer's consumption.

- The rate calculates charges without bill factors until it encounters the rate component used to levy state tax. This rate component references a bill factor. This means the rate must get the tax rate(s) in effect during the billing period from this bill factor.

- The state tax bill factor contains an attribute defining that the premise's taxing state characteristic controls the bill factor value. The bill factor therefore extracts the taxing state from the premise.

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 customers are located in a single state, you may not want to maintain the taxing state on every premise. To do this, you could setup the rate to "hard code" a taxing state of say Hawaii. This is an advanced topic, but it may prove useful for your implementation. Refer to Deriving / Passing In Characteristic Values for the details.

- The premise returns the taxing state and the bill 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 bill factors don't need a characteristic. There are bill factors whose value does not differ based on a characteristic. For example, if your organization offers employee discounts, the discount percent is probably the same for all employees and therefore this bill factor doesn't need a characteristic to select the bill factor value at billing time. However, because of the relational design of the system, every bill factor value must reference both a bill factor and a characteristic value. Therefore, if you have bill factors whose value is not related to a characteristic, you must specify a characteristic type on the bill factor with a characteristic value that is exactly the same as the characteristic type. Refer to Employee Discounts for an example.

Fastpath:

For more information about setting up characteristics, see Setting Up Characteristic Types & Their Values .

Deriving / Passing In Characteristic Values

Warning:

This is an advanced, technical concept.

In An Illustration Of A Bill Factor And Its Characteristics, we described how the system retrieves a characteristic value from a premise when a bill factor is encountered that uses a premise characteristic. This is a very common technique and is easy to understand. However, there are situations when an entity in Oracle Utilities Customer Care and Billing 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:

- There are implementations that only use the Oracle Utilities Customer Care and Billing rating engine. These implementations do not setup accounts, premises, etc. Rather, they simply setup their rate schedules, rate components, and bill factors and then call the rating engine from another application. This means the rate engine can't retrieve characteristic values from within Oracle Utilities Customer Care and Billing (because there are no objects on which the characteristic values can be defined). In this situation, the application that calls the rate engine must supply the characteristic types and values to be used when a bill factor requires this type of information.

- Assume you have a charge that is based on the account's customer class and the service agreement'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 service agreement being billed. In this situation, you can use an SQ rule to derive this characteristic type and value. This SQ rule would create a characteristic type and value real time by concatenating the account's customer class and the service agreement'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 bill 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.

Bill Factor Interval Values

A bill factor may also contain interval values.

Interval values are typically used to record interval prices (i.e., prices that are applicable to short time intervals of say 15 minutes). Just as with simple bill factors, they may have characteristics defined. In the above example, the characteristic is the "Market" where the prices are defined. This bill factor probably indicates that the Service Agreement has a characteristic indicating the market from which it gets its prices. This enables you to use a common rate for customers who get their prices from different markets.

The application of these interval values requires the use of an algorithm. Depending on your business needs, there are many ways that this can be implemented.

- If your business uses the interval billing subsystem, then functionality is available for applying these interval values to interval quantities. Refer to The Big Picture of Interval Billing for more information.

- If your business does not use the interval billing subsystem, then there is still functionality available in rates for using interval values. See Interval Values Can Be Used For More Than Just Interval Prices for one example. Refer to Pricing Interval Consumption Using Interval Prices for another example.

Contents

Interval Values Can Be Used For More Than Just Interval Prices

Interval Data is Stored in Data Sets

Interval Values Can Be Used For More Than Just Interval Prices

The interval value transaction can be used for more than recording interval prices. One such purpose is to record rolling average prices. Let's use an example to make the point. Assume the following:

- You operate in a deregulated environment and part of the price charged to your customers is based on the spot-market price.

- Your customers don't have interval meters. Rather, they simply have meters that are read once a month. When you calculate a customer's bill, you must determine the single price to be applied to the total amount of consumption for the month.

- The price applied to a customer's bill is based on the number of weeks of consumption and the end date of the bill period. For example, a customer whose bill ends on 12-Sept-2001 with 3 weeks of consumption would probably have a different price than a customer whose bill ends on the same date but has 6 weeks of consumption. Why? Because the spot market price varies during the different billing periods.

- Different prices may be calculated based on the customer's load profile. This would mean that a residential customer whose bill ends on 12-Sept-2001 with 3 weeks of consumption would have a different price than a commercial customer whose 3 week bill ends on the same date. Why? Because residential customers tend to consume in different time periods than do commercial customers (and therefore different spot market prices were in effect).

If you assume the above, then you'd need the ability to record different prices based on:

- The bill end date

- The number of weeks / days in the billing period

- The customer's load profile

You can use the interval pricing objects to record this information. You do this as follows:

- Create a characteristic type called LOADPROF. Associate with it characteristic values of RESID and COMMERCIAL.

- Create a bill factor called WAP and have it reference the LOADPROF characteristic type.

- Enter an interval pricing value set for each bill end week cutoff date. And for each interval pricing value set, add an interval value for each bill start week cutoff date.

The following table will help visualize an interval pricing value set for the bills ending the week of 17-Sept-2001:

Bill Factor: WAP - Weighted Average Price

Char Value: RESID - Residential Load Profile

Interval Value Date / Time: Bills ending the week of 17-Sept-2001

Bill Period

Bill Start Date

Weight Avg Price

4 Week Weighted Average PX Price

19-Aug-2001

0.03432

5 Week Weighted Average PX Price

12-Aug-2001

0.04594

6 Week Weighted Average PX Price

5-Aug-2001

0.02302

7 Week Weighted Average PX Price

29-July-2001

0.06039

8 Week Weighted Average PX Price

22-July-2001

0.02981

9 Week Weighted Average PX Price

15-July-2001

0.01921

10 Week Weighted Average PX Price

8-July-2001

0.05010

11 Week Weighted Average PX Price

1-July-2001

0.060929

12 Week Weighted Average PX Price

24-June-2001

0.03939

Below, we've illustrated how interval pricing information might look for a bill factor that holds the weighted average prices.

Fastpath:

Refer to Pricing Non-Interval Consumption Using A Weighted Average Price for how a rate component value algorithm makes use of the above information when a bill is calculated for a customer.

Interval Data is Stored in Data Sets

Interval data in the system will have many different origins.

- It may be contract-related data, which is setup at the beginning of the contract or contract year

- It may be data, which is interfaced from an external source periodically

Regardless of the origin of the data, all data will have similar characteristics

- Data will be received by the system, or created by the system periodically. The system will store whatever new data needs to be stored.

- The period represented by the batch of new data is variable.

- New data may be an update to previously received data

Refer to Interval Quantities are Stored in Data Sets for information about how interval data is stored. This same model is used for bill factor interval data. There is no difference.

Bill Factor TOU Values

A bill factor may also contain values, which differ by a TOU code. This enables you to set up prices that differ by TOU or to set up contract values, which differ by TOU.

Bill Factor TOU values are typically used to record prices, which vary by time of use code. TOU prices are used in conjunction with time of use mapping. The customer would typically have interval quantities, which are mapped, using a TOU Map, into a collection of time of use quantities. Defining a bill factor with prices per TOU allows you to set up a single rate component to apply charges to these quantities, resulting in multiple bill calculation lines.

Just as with simple bill factors, TOU bill factors may have characteristics defined. In the above example, the characteristic is the "Market" where the prices are defined. This bill factor probably indicates that the Service Agreement has a characteristic indicating the market from which it gets its prices. This enables you to use a common rate for customers who get their prices from different markets.

In addition to defining the characteristics, TOU bill factors must also indicate the TOU Group. The TOU group is a collection of time period definitions, which make up a TOU map. This enables you to define different prices for On Peak, when it is part of a 2 part TOU map versus when it is part of a 3 part TOU map.

Fastpath:

Refer to Grouping of TOU Codes for more information.

The TOU prices are defined for the combination of characteristic and TOU Group. In the examples below, a bill factor's characteristic is State. Also note that the effective date of the prices are the same for all time of use codes. If the price of any TOU value changes, then a new set of prices for all TOU codes must be entered.

The application of these time of use values requires the use of an algorithm. If your business uses the interval billing subsystem and uses time of use mapping and pricing, then functionality is available for applying these values to interval quantities, which have been mapped into time of use quantities. Refer to The Big Picture of Interval Billing for more information.

Contents

TOU Values Can Be Used For More Than Just Prices

TOU Values May Differ By Customer

TOU Values Can Be Used For More Than Just Prices

TOU values can be used for more than recording prices. Many contract-based values may also be recorded per TOU. For example, a contract for an interval billing customer may designate a hedge cover or a minimum demand value or a contract demand value. Although you may have interval quantity curves to define these values, that would be difficult to define and maintain. A more common scenario would be to define a TOU Map and to define these values for each TOU. A TOU Bill Factor could be used to define these values.

TOU Values May Differ By Customer

In the same way that simple bill factors may be used to define customer specific prices and values, TOU bill factors may also be used to define customer specific prices and values. Refer to Customer Specific TOU Values for more information.

Defining Bill Factors

You create a bill factor for every type of charge whose value is not specified directly in a rate component.

You use two windows to set up a bill factor. On the first, you define general information describing how the bill factor is used in the system. On the second, you define every characteristic value for which the bill factor has a value.

Contents

Defining General Bill Factor Information

Setting Up Bill Factor Characteristics

Defining General Bill Factor Information

You begin to define a bill factor by selecting Main Menu, Rates, Bill Factor.

Description of Page

Enter a unique Bill Factor code and a Description for the bill factor.

Use Bill Factor Type to indicate if this bill factor uses Regular , Interval (i.e., real time) or Time of Use values. If you choose Regular , this bill factor's values are specified on Bill Factor Value - Main or on Service Agreement - Contract Values . If you choose Interval , this bill factor's values are specified on Defining Interval Values . If you choose Time of Use , this bill factor's values are specified on Bill Factor TOU Values or on SA Interval Billing Info - TOU Contract Values.

Enter a Currency Code to define the currency in which the bill factor's prices are denominated. This field will be gray if the bill factor is referenced on a rate component.

Note:

Bill 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 bill factor. The Value Type options are:

Charge

The value maintained in this bill factor is a fixed amount (e.g., a flat charge).

Percentage

The value maintained in this bill factor is a percentage.

Unit Rate

The value maintained in the bill factor is a price per service quantity.

This field will be gray if the bill factor is already referenced on a rate component or if the bill factor already has values.

Turn on Error If No Value if the system should create a billing error when a bill factor value doesn't exist for the characteristic value linked to the customer. Confused? To clarify this, you need to be aware that there are different types of bill factors:

- Those that should have a value for every customer whose rate references the bill factor. A bill factor used to levy the relevant state tax is a good example (assuming every state has a tax). For this type of bill factor, if the system cannot find a bill factor value for the taxing state, it must generate a billing error because data is missing from the system. You would turn on Error if No Value for this type of bill factor.

- Those that only have a value when the customer has a characteristic value that levies a charge. A bill factor used to levy the relevant city tax is a good example (because not all cities levy taxes). For this type of bill factor, if the system cannot find a bill factor value for the city in which the customer lives, the rate component will be skipped and no billing error will be generated. You would turn off Error if No Value for this type of bill factor.

Bill factors used to levy taxes may or may not be eligible for tax exemptions; it's up to the respective taxing authority. Customers who are eligible for the tax exemption will have their tax obligation reduced (or nullified) at billing time. For bill factors that are eligible for tax exemptions, turn on Tax Exemption. If a service agreement is fully or partially exempt for the taxes defined by a given bill factor, the bill factor and the exemption information for the customer must be indicated on the Service Agreement page. This field will be gray if the bill factor is referenced as being tax exempt in a service agreement.

Note:

Tax Exemptions limited to Apply To Rate Components. Although bill factors marked as eligible for tax exemptions may be referenced on several different types of rate components, only Apply To rate components include the logic to check for tax exemption eligibility.

Fastpath:

For more information about how to make a customer tax exempt, refer to Service Agreement - Tax Exemptions.

Some types of bill factors do not have the same value for all customers. Rather, their value may be unique for every customer or it may be unique for some customers and common for others. For example, you may have rates where the price per kilowatt hour is defined for every customer using the rate. You may have other rates where certain customers have their own price per kilowatt hour defined and other customers who use the value defined on the bill factor. For any type of bill factor where a customer may have their own unique price, turn on Value In Contract Term. For any service agreement that has a unique value for a given bill factor, the bill factor and the service agreement's value must be indicated on the Service Agreement page. When applying the rate for a bill factor of this type, the system will first check for the existence of a contract value for the service agreement and if one is not found, it will use the value on the bill factor. This field will be gray if a contract term referencing this bill factor exists. Time of Use bill factors may follow this same logic. Customers may override their time of use values by using a contract term.

Note:

The Error if No Value switch also affects what happens if there is no contract term for the bill factor. If the error switch is on, a billing error will be generated. If the error switch is off, no billing error will be generated and the rate component will be skipped.

Fastpath:

For an example of a bill factor whose value is specified in a contract term, refer to Customer Specific Prices. For more information about how to specify a bill factor value in a customer's contract, refer to Service Agreement - Rate Info and Service Agreement - TOU Contract Values.

Contract riders are used when the charge associated with the bill factor is only applicable to some customers for some period of time. For example, if a bill factor is used to provide a discount during the first 3 months of service, then a contract rider would be used. Turn on Contract Rider Applicability if the bill factor's applicability is contingent on the existence of a contract rider. This field will be gray if a contract rider referencing this bill factor exists on a service agreement.

Fastpath:

For an example of a bill factor whose value is dependent on a contract rider, refer to Employee Discounts. For more information about how to establish a contract rider for a customer, refer to Service Agreement - Contract Riders.

The proration information tells the system how to handle changes to bill factor values and their optional contract riders that may occur during a customer's bill period. Turn on Allow Proration if changes to the bill factor's value and/or contract riders should be prorated. If the Bill Factor Type is not specified as Interval and if changes should not be prorated, indicate the Rate Selection Date Algorithm to use when the system retrieves bill factor values or determines if contract riders are applicable. Click here to see the algorithm types available for this system event.

If you have sub service agreements, turn on Use Sub SA Contract terms if billing should access contract riders, values, tax exemptions from the sub SA rather than the master. If this switch is off, the system will use the master SA's riders, contract value, and tax exemptions when it creates bills for a sub service agreement. Refer to Sub Service Agreements for more information.

If the Contract Management module is not turned off, which includes umbrella agreement management, and you have checked either Tax Exemption, Value in Contract Term or Contract Rider Availability, indicate the Terms of Service Usage. Valid values are Check SA Only , Check TOS Only and Check TOS First, then SA . Refer to Overriding Rate Terms for details about how to set this value based on your business needs.

Bill Factor Tree

The right half of this page is dedicated to a tree that shows the bill factors characteristics and their respective values (for Regular bill factors) or interval value Sets (for Interval bill factors). 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 Bill Factor to define the price being charged. Refer to Rate Component - Main Information for more information.

The BILPC-TOTAL algorithm type that is used to levy late payment charges references the bill factor that defines the late payment charge percent. Refer to SA Type - Main for more information about this algorithm.

A Service Agreement references Bill Factors as follows:

- When a service agreement's Apply To rate component references tax exemptable bill factors AND the customer is tax exempt, the service agreement will define the bill factors from which the customer is exempt. Refer to Service Agreement - Tax Exemptions for more information.

- When a service agreement's rate references bill factors whose prices are customer-specific (i.e., specified on a contract term), the service agreement will contain prices for these bill factors. Refer to Service Agreement - Contract Values for more information.

- When a service agreement's rate references bill factors that are contingent on contract riders, the service agreement will define the rider period (if any) for these bill factors. Refer to Service Agreement - Contract Riders for more information.

Register rules using the Bill factor based UOM conversion algorithm reference a bill factor to define the conversion amount. Refer to CCF To Therm Conversion and Gas Pressure Factor Adjustments for examples.

Setting Up Bill Factor Characteristics

After defining general information about a bill factor, open Main Menu, Rates, Bill Factor and navigate to the Bill Factor Characteristic tab to define characteristic values for which a charge is applicable. For example, a bill factor used to levy the applicable city tax would require the definition of every city that levies a tax.

Note:

If all values for a bill factor are specified in contract terms, you do not need to set up Bill Factor Characteristics.

Description of Page

Enter a Characteristic Type to indicate the type of characteristic that controls how the bill factor's value is defined. This field will be gray if Bill 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 service agreement'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 service agreement'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. Refer to Employee Discounts for an example.

Premise

The characteristic type's value will be retrieved from the service agreement's characteristic premise.

SA

The characteristic type's value will be retrieved from the service agreement.

SP

The characteristic type's value will be retrieved from the customer's service point. If multiple service points are linked to the service agreement, one will be chosen at random.

Fastpath:

For more information about characteristics, see Setting Up Characteristic Types & Their Values and An Illustration Of A Bill Factor And Its Characteristics.

Use the add and remove buttons to define the Characteristic Values that are relevant for the bill factor's Characteristic Type. For example, if the bill 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 Minutes Per Interval if your Bill Factor is of type Interval . This defines, for each characteristic value, the number of minutes expected between each record of interval data.

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.

If your Bill Factor is of type Interval and the installation record indicates that seasonal time shift is required, then you must enter the appropriate Seasonal Time Shift record applicable for the interval data. Please take special note of the issue described in the Evenly Sized Intervals section.

Fastpath:

For more information, refer to Seasonal Time Shifts.

Note:

If the bill factor's value is the same for all customers, you still must link a "dummy" characteristic value to the bill 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 bill factor, you reference the "n/a" characteristic type and on the above window, you indicate a characteristic value of "n/a".

Defining Bill Factor Values

After the bill factor and its characteristic values are defined, you define the price / percent and GL distribution associated with each bill factor characteristic. The topics in this section describe the pages used to set up this information.

Contents

Bill Factor Value - Main

Bill Factor Value - GL Distribution

Bill Factor Value - Main

After the bill factor and its characteristic values are defined, select Main Menu, Rates, Bill Factor Values to define the price / percent applicable to each bill factor characteristic.

Important:

You do not set up Bill Factor Values for bill factors whose values are specified in an interval value data set or if all the values are customer specific an are defined as contract terms. Refer to Defining Interval Values for more information about interval value sets. Refer to Service Agreement - Contract Value for more information about bill factors in contract terms.

Description of Page

Enter the Effective Date and respective Value for the bill factor and characteristic value. The first date should be the earliest date on which the bill 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.

Bill Factor Value - GL Distribution

Select Main Menu, Rates, Bill Factor Value and navigate to the GL Distribution tab to define the GL account affected by the bill factor characteristic.

Important:

If you do not specify this information for a bill factor characteristic, the distribution code defined on the rate component that references the bill factor will be used.

Description of Page

If the bill 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 bill 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 bill factor will be used.

Defining Interval Values

Open Main Menu, Rates, BF Interval Values to maintain interval values.

Note:

Interval values must reference a bill factor. You must set up a bill factor before you can define interval prices. Refer to Setting Up Bill Factors for more information.

Description of Page

Interval Value Set is a concatenation of important information about the data set. The Interval Value Set ID is a system-assigned random number that stays with an interval value set for the life of the system. This value is assigned when the set is first added.

All interval pricing information must reference a predefined Bill Factor, Characteristic Type and Characteristic Value. Use the Bill Factor Characteristic search button to select all three values. Refer to Setting Up Bill Factors for more information.

Use Set Date / Time to define the effective date of the set of prices or values defined in the following grid. This is considered a server date and will follow the seasonal time shifting as defined on the base time zone. Refer to Seasonal Time Shifts for more information.

Use the Start Date / Time to indicate the starting point for the display of the interval data.

At least one interval data record must exist in the collection of interval data. For each interval data record, the Interval Value Date / Time and the Interval Value are captured. This date is considered a logical date and will follow the seasonal time shifting as defined on the bill factor / characteristic. Refer to Seasonal Time Shifts for more information.

If seasonal time shift records are linked to both the base time zone and the bill factor/characteristic, the Seasonal Time Shift associated with your bill factor/characteristic is displayed. Refer to Setting Up Bill Factor Characteristics for more information.

If seasonal time shift records are linked to both the base time zone and the bill factor/characteristic, the Seasonal Time Shift Remark indicates whether the data is displayed and should be entered in legal time or standard time. Refer to Interval Time Display for more information. If the data is displayed in legal time use the Show in Standard button to toggle to standard time. If the data is displayed in standard time use the Show in Legal button to toggle to legal time. If either the bill factor/characteristic or the base time zone do not indicate a seasonal time shift record, then the toggle button will not be visible and data is displayed and expected in standard time.

Where Used

Various rate component algorithms make use of interval pricing information.

Bill Factor Interval Values Query

This query shows the most recent interval values for an interval value bill factor/characteristic and a time period as of a given time.

Open Main Menu, Rates, BF Interval Values Query to display interval bill factor values.

Description of Page

Information describing the Bill Factor, Characteristic Type and Characteristic Value whose data you wish to query is displayed.

Use the Start Date / Time and End Date / Time if you want to limit the query to a specific time period.

Use the Set Date / Time to indicate the "as of what date" to use for retrieving interval data. Only data sets with a set date/time prior to this date/time will be accessed.

The Selection Type is used to determine what data to show

History This option will display all bill factor interval data for the Bill Factor/Characteristic and time period, if specified. It will include data in data sets of any status value.

Most Recent Complete Data This will find the most recent bill factor interval value data for each interval from completed data sets only.

Once you have selected your criteria, use the search button to display the data. The interval value data collection will contain the following information:

The Interval Value Date/Time and Interval Value for each interval is displayed. Adjacent, information about the data set to which this interval is linked is displayed, including the Set Date / Time and Interval Value Set ID.

If seasonal time shift records are linked to both the base time zone and the bill factor/characteristic, the Seasonal Time Shift associated with your bill factor/characteristic is displayed.

The Seasonal Time Shift Remark indicates whether the data is displayed and should be entered in legal time or standard time. Refer to Interval Time Display for more information. If the data is displayed in legal time use the Show in Standard button to toggle to standard time. If the data is displayed in standard time use the Show in Legal button to toggle to legal time.

Note:

If seasonal time shift information is missing for the bill factor/characteristic or for the base time zone, then data is always displayed and expected in standard time.

Upload Interval Values

The following diagram illustrates the processes involved in the uploading of interval values into the system.

The topics in this section describe how these processes work.

Contents

Process X - Populate Interval Data

Interval Value Set

Interval Value

Interval Value Set Key

Process X - Populate Interval Data

Process X refers to the mechanism used by your organization to populate the Interval Value tables. Process X will have the following responsibilities:

- It will determine the appropriate Bill Factor and Characteristic to which this data belongs. Recall that the bill factor / characteristic may reference an external id.

- It will create a new Interval Value Set for this bill factor characteristic with the current date and time

- If the interval data is from a different time zone, or is not in standard time for the base time zone, the time of each interval must be converted to the base time. Refer to Time Zone and Time Changes for more information.

- All prices being uploaded for the same bill factor and characteristic should be inserted into the Interval Value table and should reference the same Interval Value Set

- Inserts a record in the interval value set key table.

The topics in this section describe the tables to populate.

Interval Value Set

You must create a data set for each batch of records being uploaded in the system for the same bill factor / characteristic. The name of this table is CI_INTV_VAL_SET . The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

INTV_VAL_SET_ID

12

Y

A/N

This is a random unique key. This key is referenced on the interval value record.

It's suggested that this is a random number. If your process that inserts records on this table is capable of calling a COBOL routine, call CIPZKEYG and it will supply a 12 digit random number for you.

BF_CD

8

Y

A/N

This along with CHAR_TYPE_CD and CHAR_VAL indicate the bill factor / characteristic to which this interval value set belongs.

Refer to Setting Up Bill Factors for more information.

CHAR_TYPE_CD

8

Y

A/N

This along with BF_CD and CHAR_VAL indicate the bill factor / characteristic to which this interval value set belongs.

Refer to Setting Up Bill Factors for more information.

CHAR_VAL

16

Y

A/N

This along with BF_CD and CHAR_TYPE_CD indicate the bill factor / characteristic to which this interval value set belongs.

Refer to Setting Up Bill Factors for more information.

SET_DTTM

26

Y

DateTime

This is the data/time that the data set was received. This must be populated with the current date / time. This is considered a server date and will follow the seasonal time shifting as defined on the base time zone. Refer to Seasonal Time Shifts for more information.

Refer to Algorithms Find the Most Up To Data for information about why this date/time is important.

Interval Value

Each piece of interval data for the same bill factor/characteristic will be stored as an Interval Value record linked to the newly created data set. The name of this table is CI_INTV_VAL . The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

INTV_VAL_SET_ID

12

Y

A/N

This is a foreign key reference to the Interval Value Set that groups the interval values together. This should be your newly created id from above.

INTV_VAL_DTTM

26

Y

DateTime

This is the date and time of the interval value. This must be stored relative to the base time zone. Refer to Time Zone and Time Changes for more information.

INTV_VAL

18.7

Y

N

This is the value (price) for the interval.

Interval Value Set Key

When a system-generated key value is assigned to a record, you need to also store the key value in a key table that corresponds to the record's database table. The name of this table is CI_INTV_VAL_SET_K . The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

INTV_VAL_SET_ID

12

Y

A/N

This should be your newly created Interval Value Set ID from above.

ENV_ID

6

Y

N

This is the environment id defined on the installation options.

Defining Bill Factor TOU Values

Open Main Menu, Rates, BF TOU Values to maintain time of use bill factor values.

Note:

TOU Bill Factor values must reference a bill factor and characteristic. You must set up a bill factor and its characteristics before you can define TOU values. Refer to Setting Up Bill Factors for more information.

Description of Page

The BF Characteristic TOU Group search button gives you the ability to search for existing TOU BF values for a Bill Factor, Characteristic and TOU Group combination.

The BF Characteristic search button gives you the ability to search for a Bill Factor, Characteristic combination to which the TOU values will be linked.

Once a bill factor and characteristic combination are chosen, the system displays the values of the Bill Factor, Characteristic Type, Characteristic Value and Value Type.

Choose the TOU Group to determine the collection of time of use codes to which prices will be defined.

Indicate the Effective Date of the collection of Time of Use codes and their Values.

Where Used

Various rate component algorithms make use of TOU value information. This information is also available for any type of algorithm that may need to use the information, for example interval data derivation algorithms.

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 a service agreement, 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.

Contents

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 Main Menu, Rates, Rate Version Classic 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 a service agreement, 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.

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 customers' 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 prices. This message will only be substituted when the rate version is prorated.

The following are examples 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

Gas service %D

Gas service (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., price 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 customer'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 customer. This way, if you want to suppress some calculation details, you can, but still show the details to the customer service rep.

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.

Note:

The rate component results in the creation of a bill segment calculation line, but an indicator exists to tell the extract program that this should not be included. This is true, except in the following cases when the system does not create a zero bill segment calculation line:

Note:

1. Apply To rate components where the cross referenced amount is zero

2. Calculation Algorithm rate components that result in a zero amount

3. Summary,Minimum,MaximumandExact Charge rate components that do not apply

4. Stepped rate components where both the low and high boundaries equal zero

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 customer 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 generate the bill (or who submitted the batch billing process).

%B

Replaces the substitution character with the begin/start date covered by the bill calculation line.

If the charge is proratable, %B may be used in conjunction with %E to display the period covered by the bill calculation line.

%C

Replaces the substitution character with the number of items being billed. Leading zeroes are suppressed.

%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 prices. 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 price / percent into the bill line.

If the charge is proratable, %D should be used in conjunction with %R to print an appropriate message when the charges are prorated.

%E

Replaces the substitution character with the end date covered by the bill calculation line.

If the charge is proratable, %E may be used in conjunction with %B to display the period covered by the bill calculation line.

%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.

%H

Replaces the substitution character with the high value defined on the calculation rule used to calculate the specific stepped charge on the bill line. This is only used when the new rate engine calculated the charge.

See About Calculation Groups and Rules for more information about calculation rules.

%I

Replaces the substitution character with the value specified in the rate component / bill 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 generate the bill (or who submitted the batch billing process).

Either this character OR %R should be used when you desire to substitute the price / 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.

%L

Replaces the substitution character with the low value defined on the calculation rule used to calculate the specific stepped charge on the bill line. This is only used when the new rate engine calculated the charge.

See About Calculation Groups and Rules for more information about calculation rules.

%M

Replaces the substitution character with the item type defined on the calculation rule used to calculate the specific item type charge on the bill line. This is only used when the new rate engine calculated the charge.

See About Calculation Groups and Rules for more information about calculation rules.

%O

Replaces the substitution character with the description of the time-of-use (TOU) code being billed on this line

%Q

Replaces the substitution character with the service quantity being billed. Leading zeroes are suppressed. The decimal places shown are specified in a field on the Unit Of Measure control table.

If you wish to suppress trailing zeroes after the decimal, you must set up the Allow Consumption Zero Suppression In Bill Description option type on the Financial Transaction Options Feature Configuration.

%R

Replaces the substitution character with the value specified in the rate component / bill factor. Either this character OR %I should be used when you desire to substitute the price / percent into the bill line. Using %R causes the prorated price / percent to be printed in the bill line (%I causes the price / 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.

%T

Replaces the substitution character with message 10103 from message category 4. This message is maintained in the standard message table.

We recommend this message be set to "(%1% exempt)" where %1 will be substituted with the tax exemption percent as specified in the service agreement. This message will only be substituted when the rate component's bill factor is eligible for tax exemptions AND the customer is exempt from the tax. Note, %1 is not required.

%V

Replaces the substitution character with the "C1-ADDSC" characteristic ad hoc value retrieved by the calculation rule used to calculate the charge on the bill line. This is only used when the new rate engine calculated the charge.

See About Calculation Groups and Rules for more information about calculation rules.

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 CUSTOMER!" This message appears in the bill line that appears in the billing windows but does not appear on the customer's bill.

The following are examples of the content of common Description on Bills along with how the line would look on the customer's bill:

Description on Bill On Rate Component

How It Looks On A Bill

%C lamp pole(s) at %I per pole %F

1,234 lamp pole(s) at $5.00 per pole (prorated by .3333)

%C lamp pole(s) at %R per pole %D

1,234 lamp pole(s) at $1.50 per pole (prorated for 10 of 30 days)

First %Q kWh at %I per kWh %F

First 100.32 kWh at $0.12349 per kWh (prorated by .3333)

First %Q kWh at %R per kWh %D

First 100.32 kWh at $0.12349 per kWh (prorated for 10 of 30 days)

%Q kWh at %I per kWh

100.32 kWh at $0.12349 per kWh

State sales tax %R %T

State sales tax 6.25% (50% exempt)

Minimum charge of %I %F

Minimum charge of $10.00 (prorated by .3333)

Subtotal of %S

Subtotal of $1,123.23

Charges for %O: %Q kW at %I per kW

Charges for Off Peak Winter: 234.43 kW at $0.05 per kW

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 bill calculation algorithms. All of the other rate and bill 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 bill factors, register rules, SQ rules, SQ 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.

Warning:

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.

Contents

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 customers' printed bills. If the rate has optional charges (e.g., employee discounts or charges that only apply after the customer has consumed a large volume), 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:

- "Monthly service charge: $50.00". This is a simple service charge that appears regardless of how much the customer consumed. This line doesn't really have any variables that affect its amount. Rather, the amount is a constant value of $50.00.

- "1,250 kWh at $0.07892". This charge is based on how much the customer consumed. The variables involved are the number of kilowatt-hours (kWh) and the price per kWh.

- "1,000 20K Lumen Mercury Vapor Lamps at $20.00 per lamp". The variables involved are the number of devices (also called "items") used by the customer and the price per item.

- "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 customer'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 service charges and fees that aren't based on how much the customer uses. The monthly service charge shown above would be levied using this type of rate component.

Service Quantity

This type of rate component is used to create bill lines that levy charges based on some type of consumption. The kWh charge shown above would be levied using this type of rate component.

Frequently the amount consumed is measured by a meter's registers and sometimes it's calculated using Service Quantify (SQ) Rules linked to the rate and sometimes it's derived based on the type of item (e.g., for lamps). Regardless of how the amount consumed is calculated, the charge for the consumption amount is levied using this type of rate component.

You'll find it helpful to differentiate your service quantity rate components into two categories - stepped and non-stepped. Stepped charges are those where there's a different price for different ranges of consumption (e.g., the first 50 therms are $0.43 a therm, anything in excess of 50 therms is charged at $0.71 per therm). We recommend doing this because a) you frequently show a subtotal of the steps on the customer's bill, b) steps, by definition, mean you have several rate components that are dependent on each other, and c) they frequently involve complex calculations in order to define the step boundaries.

Item Type

This type of rate component is used to create bill lines that levy charges based on the number and type of items used by a customer. The system keeps track of items on the service point(s) linked to the customer's service agreement. The lamp charge shown above would be levied using this type of rate component.

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. The county surcharge shown above would be levied using this type of rate component.

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.

Note - these types of rate components are rare. You tend to only see them in deregulated markets where customers have agreed to pay the market rate but want a cap on the maximum they'll pay each bill period.

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).

Note - these types of rate components are rare. You tend to only see them in deregulated markets during the transition period between regulated rates and complete deregulation. In this situation, you show on the bill what the charges would be, given a deregulated environment, but then adjust the bill back to an amount equal to the regulated rate. This charge is called a Competition Transition Charge (CTC) in California.

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.

Interval Pricing

This type of rate component is used to apply interval prices to interval quantities. See Interval Pricing Rate Application for more information.

TOU Pricing

This type of rate component is used to map and/or price interval quantities into time of use quantities given a TOU map. See Time of Use Mapping and Pricing for more information.

- For each rate component, determine if the customer must meet some form of eligibility criteria before the rate component is applied. For example, you may have a rate component that calculates an employee discount. 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 bill 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 customers regardless. For example, if you see a provision in the rate that says to charge $0.05674 per kWh, you'd specify 0.05674 directly in the rate.

Use a bill factor to define the value

The following paragraphs describe when you'd use a bill factor to define a unit rate / percent / flat amount.

The same charge exists in many rates. For example, if there are 3 rates that all contain the same service charge, it would make sense to use a bill factor to levy this charge rather than specify the same value on 3 rate components.

The amount being charged is dependent on some physical characteristic of the customer's equipment. For example, if the price differs depending on whether the customer owns the transformer, you would use a bill factor to specify the price.

The amount being charged is dictated by some external organization and therefore can change independently from the rate. For example, tax percentages and use fees are set by 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 customer lives. If you have a rate where the price per gallon differs depending on where the customer lives, you should use a bill factor to levy this type of charge.

The price differs per customer. For example, you may have a rate for large gas customers where the price per therm is different for every customer. In this situation, you would use a bill factor to specify the price.

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 price / 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. See the Calculated Minimum Charges example for an illustration of when this method is useful.

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 price / percent / charge.

One example that would require the use of an algorithm would be when the price differs based on the total amount consumed. For example, if the customer uses less than 10 CCF, the price is $1.50; whereas if the customer uses more than 10 CCF, the price is $2.00.

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 service quantity rate components under Rate Component - Main Information for more information about this type of algorithm.

Please note that this scenario could also be implemented without invoking an algorithm by setting up two rate components that have eligibility rules to indicate their required respective consumption levels. Refer to The Big Picture of Rate Component Eligibility for more information.

- 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.

Note:

Examples. Refer to Rate Examples for many sample rate components.

Rate Component Rounding

The topics in this section describe how to control how each rate component's final value is rounded.

Contents

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.00001 (5 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.00001 (5 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 remaining steps depend on whether or not a tax exemption is applicable

- If NO tax exemptions are applicable, the temporary field is rounded based on the rate component's rounding rules to produce the final amount.

- If there are tax exemptions, the temporary field is rounded to the nearest .01 decimal precision prior to applying the tax exemptions. When the tax exemption is applied, the result is rounded according to the currency precision and stored as the Exempt Amount. The system calculates the final amount by subtracting the exempt amount from the rounded temporary amount and then applying the rate component's rounding rules.

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,

- You may have a rate component that calculates an employee discount. 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 identify employees) before the rate component is applied.

- You may have a rate component that calculates a surcharge if the customer 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.

Contents

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 customer is a low income customer and has used more than 1,000 kWh

- OR, the customer isn't a low income customer and has used more than 500 kWh

This rate component requires two eligibility groups because it has two distinct conditions:

- IF (Customer is low income AND the customer has used more than 1,000 kWh)

- IF (Customer is NOT low income AND the customer has used more than 500 kWh)

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

Customer is a low income customer and has used more than 1,000 kWh

Eligible

Check next group

2

Customer is NOT a low income customer and has used more than 500 kWh

Eligible

Ineligible

The following criteria will be required for each of the above groups:

Group 1: Customer is a low income customer and has used more than 1,000 kWh

Seq

Logical Criteria

If Eligibility Criteria is TRUE

If Eligibility Criteria is FALSE

If Insufficient Data

10

Customer is low income

Check next condition

Group is false

Group is false

20

Customer has used more than 1,000 kWh

Group is true

Group is false

Group is false

Group 2: Customer is NOT a low income customer and has used more than 500 kWh

Seq

Logical Criteria

If Eligibility Criteria is TRUE

If Eligibility Criteria is FALSE

If Insufficient Data

10

Customer is NOT low income

Check next condition

Group is false

Group is false

20

Customer has used more than 500 kWh

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 service agreement being billed

- The service agreement's account

- The main person linked to the service agreement's account

- The characteristic premise linked to the service agreement

- One of the service points linked to the service agreement

- In addition, you can also use a characteristic value that is derived while the rate is being calculated (characteristic values can be created by SQ rules, register rules and many other rate component algorithms)

- You can retrieve the value of a given service 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.

Contents

A Rate Component With A Service Quantity Comparison

A Rate Component With A Time Span Comparison

A Rate component With Service Type Comparison

A Rate Component With A Service Quantity Comparison

Imagine a rate component that is only eligible if the customer is a low-income customer and has used more than 1,000 kWh. This rate component would need the following eligibility rules:

- Customer is a low income customer

- The customer has used more than 1,000 kWh during the bill period

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

Customer is a low income customer and has used more than 1,000 kWh

Apply rate component

Skip rate component

The following criteria will be required for this group:

Group 1: Has gas service and user is part of user group A, B or C

Seq

Field to Compare

Comparison Method

If TRUE

If FALSE

If Insufficient Data

10

Main person characteristic:

Characteristic type = Low income indicator

= YES

Check next condition

Group is false

Group is false

20

SQ value:

UOM = KWH

>= 1,000

Group is true

Group is false

Group is false

Both criteria are similar - they retrieve a value and compare it to something:

The first criteria is fairly simple:

- Field to Compare. We indicate that the value of the Low Income Indicator characteristic type kept on the main person linked to the account should be retrieved. We've assumed that this characteristic type has values of YES and NO .

- Comparison Method. We indicate that if the person has a characteristic value of YES , then we should check the next condition; otherwise we indicate the group is false (and if the group is false, the rate component is skipped).

The second criterion works similarly:

- Field to Compare. We indicate the service quantity (SQ) that holds the total amount of KWH should be retrieved.

- Comparison Method. We simply compare the value to 1,000.

If the second criterion is true, then the group is true and the rate component will be applied; otherwise, the group is false and the rate component will be skipped.

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

Customer 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 customer 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 customer'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 customer'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 Service Type Comparison

Imagine a rate component that is only eligible if the current customer has gas service AND electric service. This rate component would need the following eligibility rules:

- Customer has gas service, and

- Customer has electric service

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 gas service AND electric service

Apply rate component

Skip rate component

The following criteria will be required for this group:

Group 1: Has gas service AND electric service

Seq

Field to Compare

Comparison Method

If TRUE

If FALSE

If Insufficient Data

10

Algorithm: check if customer has gas service

= TRUE

Check next condition

Group is false

Group is false

20

Algorithm: check if customer has electric service

= 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 service agreements that belong to a given set of service types. It returns a value of TRUE if the customer has an active service agreement that matches one of the service types in the algorithm. In our example, the "check if customer has gas service" algorithm returns a value of TRUE if the customer has at least one active service agreement whose SA type references the gas service type. The "check if customer has electric service" algorithm is almost identical, only the service 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

Warning:

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).

Contents

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 Main 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.

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.

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.

Warning:

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 Percent .

- 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 customer 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 examples of rates that use the FCPO functionality, refer to Calculated Minimum Charges, Hours-Based Electric Rate and Step Boundaries Based On The Number Of Days Of Usage And The Region In Which The Customer Resides.

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 are 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 Bill Factor , then a prompt to indicate the Bill 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 consumption 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 SQ. This option is only pertinent if you have:

- Seasonal service quantity (SQ) charges, AND

- Meters that measure seasonal consumption on separate registers, 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 SQ rate component based on the number of days in the adjacent season that is included in the rate version's calculation period. For example, if two rate versions are in effect on a bill segment and one of them only becomes effective during the summer; only the summer consumption should be priced using the rate version (i.e., winter consumption should not be used on a rate version that is only effective during the summer period).

Note:

The Seasonal periodis 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.

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. For example, perhaps the seasonal period is determined dynamically based on the scheduled meter read date of the bill cycle. Or perhaps a seasonal rate component should not be prorated and the date used to determine whether the rate component is applicable is not in the list provided by the system.

Description On Bill, Print, and Print If Zero all control if the rate component contributes a line to the customer'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.

How To

Contents

How To Set Up Flat Charge Rate Components

How To Set Up Service Quantity Rate Components

How To Set Up Item Type 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 Interval Pricing Rate Components

How To Set Up TOU Pricing 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 customer'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 Service Quantity Rate Components

When setting up an SQ rate component, additional fields become available for you to define.

The following information will help you to set up your SQ rate components.

Select a Value Type of Unit Rate if the type of charge is an amount per some unit of consumption. In the rare situation where the amount of the charge is flat for the first X units of consumption, 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 bill factor / value field wasa price per some unit of some thing. This thing must be identified using the Unit Of Measure, Time Of Use, and Service Qty. Identifier fields.

Fastpath:

For more information about UOM / TOU / SQI, refer to UOM versus TOU versus SQI.

Turn on Error if No Value if a bill error should be generated if the UOM / TOU / SQI specified on the rate component was not supplied at billing time. For example, if every customer using a time-of-use rate should be on a meter with ON and OFF peak register, you'd turn on this switch for the ON and OFF rate components. This way, if a customer somehow was put on a time-of-use rate, but their meter wasn't a time-of-use meter, an error would be generated.

If the charge is only applicable to consumption within some tier (e.g., the first 500 therms, or all kilowatt hours in excess of 1,000), 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 consumption charge is applicable to. For example, if the charge is applicable to the first 300 kilowatt hours, you would enter Step Low Value 0 and Step High Value 300. When multiple tiers exist, the high value of the first tier is the low value of the second tier (and so on). To extend our example, the second tier would have a low value of 300; the high value may be left blank because the system assumes a blank high value means "to infinity".

Note: The Step Low Value and Step High Value fields support values of up to 9 digits and 2 decimal places (e.g. a maximum value of 999,999,999.99).

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.

Note:

Retaining Step Algorithm High/Low Boundaries. Step Algorithms are invoked during rate application to adjust step values prior to the system performing step value proration. Depending on the step value proration that occurs, the step value may be modified by the system after the rate component step algorithm has adjusted it. If you wish the adjusted step value to be modified by the system during step value proration, you must set up the Adjust Rate Component Step Values After Proration option type on the Financial Transaction Options Feature Configuration. The Adjust Rate Component Step Values After Proration option must have a value of Y in order to have the adjusted step values modified by the system. Otherwise, set the value to N.

Fastpath:

For an example of when dynamic steps are needed, refer to Hours-Based Electric Rate and Step Boundaries Based On The Number Of Days Of Usage And The Region In Which The Customer Resides.

Warning:

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 GL Statistical Quantity if GL journal lines generated for this rate component should also contain the service 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.

Warning:

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.

Fastpath:

Refer to Determining the Statistical Quantity for more information.

Turn on Measures Peak Qty if the UOM / TOU / SQI is associated with electric demand.

Note:

Default note. The value of Measures Peak Qty is defaulted from the UOM table (if a UOM is specified).

Enter the verbiage to appear on the customer'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 Item Type Rate Components

When setting up an Item Type rate component, additional fields become available for you to define.

The following information will help you to set up your Item Type rate components.

Select a Value Type of Unit Rate . 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 item's Item Type.

Turn on Error if No Value if a bill error should be generated if the item type specified on the rate component was not supplied at billing time. For example, if every customer using a lamp rate must have at least one 20K lumen mercury vapor lamp and one pole, you'd turn this switch for the lamp and pole rate components.

Enter the verbiage to appear on the customer'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.

Note:

Multiple bill lines. Most rate components cause one bill line to appear on a customer's bill. Item type rate components are unusual. If there are effective-dated changes to the customer's items during a bill period, one line will be generated for each time period. For example, if a customer had 2 lamps installed from 1-Jan to 15-Jan and had 4 lamps installed from 16-Jan to 31-Jan and the bill is from 1-Jan to 31-Jan, two lines will appear on the customer's bill - one for each period.

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 consumption, 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 customer'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 customer'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 customer'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 customer'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 customer'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 Interval Pricing Rate Components

For more information about setting up interval pricing rate components, refer to Setting Up Interval Pricing Rate Components in the Interval Billing documentation.

How To Set Up TOU Pricing Rate Components

For more information about setting up TOU pricing rate components, refer to Setting Up TOU Pricing Rate Components in the Interval Billing documentation.

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:

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 SQ or register read collection 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. Currently the only types of audit algorithms supplied by the system are those which audit interval pricing details or those which audit TOU pricing details.

Fastpath:

Refer to Setting Up Interval Pricing Rate Components and Setting Up TOU Pricing Rate Components for more information about the audit algorithms provided with the system.

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 / SQI specified on the rate component was not supplied at billing time.

Turn on the Derive SQ switch when your calculation algorithm will be creating entries in the SQ array for the UOM / TOU / SQI defined on your rate component. In this case, the system will not attempt to locate an entry in the SQ collection matching the rate component's UOM / TOU / SQI before calling your calculation algorithm.

Enter the verbiage to appear on the customer'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 Main Menu, Rates, Rate Component Classic 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 SQ, item, interval pricing 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 Main Menu, Rates, Rate Component Classic 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 service agreement's SA Type's Revenue Class, enter a Distribution Code. If the rate component's charges are booked to a different GL account depending on the service agreement'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 Main Menu, Rates, Rate Component Classic 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 Main Menu, Rates, Rate Component Classic 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.

Warning:

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 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 customer is eligible for the rate component if the customer'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 service agreement being billed

- The service agreement's account

- The main person linked to the service agreement's account

- The characteristic premise linked to the service agreement

- One of the service points linked to the service agreement (selected at random)

- The bill segment's bill

- In addition, you can also use a characteristic value that is derived while the rate is being calculated (characteristic values can be created by SQ rules, register rules and many other rate component algorithms)

Note:

For effective-dated characteristics, the system selects the characteristic value effective on the start date of the bill segment consumption period. Refer to Determine The Consumption Period For Metered Service for information about how the consumption period is calculated before applying the rate.

- Get the most effective characteristic value for the given characteristic type and bill segment start date

- 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 Service Quantity if you want to compare the final value of a service quantity to a given value. Push the adjacent search button to select the service quantity's UOM / TOU / SQI.

- 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.

Note:

The comparison value field expects the comma as a delimiter between values. This means that if the values involve decimals, the comma cannot be used as a decimal symbol regardless of what your implementation has set up in your display profile. For decimal values, use " . " as the decimal symbol.

- 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 customer-specific rates that are very similar, but still unique. You can use this transaction to build a customer-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.

Open Main Menu, Rates, Rate Version Merge Classic 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:

Contents

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.

This logic is difficult to explain succinctly, so we'll use an example. Imagine that the Merge From rate components look as follows:

The Rate Component - Cross Reference tab for the merge from rate version shows the following cross-reference information for sequence 210 :

Assume that only rate components 10, 20 and 210 are copied to the new rate version and assume that the Original rate version already contains a rate component with sequence number 10 that is moved to the second position.

After saving, the second service quantity rate component is renumbered and the State tax rate component will reflect the renumbering in the cross-reference and will not include the rate components that were not copied.

Here is the view on the merge page after saving:

If you navigate to the Rate Component - Cross Reference tab for the original rate version for sequence 40 - State tax , it will look as follows:

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.

Contents

Rate Check - Main

Rate Check Results - Calc Lines

Rate Check Results - SQ Details

Rate Check Results - Register Read

Rate Check Results - Characteristics

Rate Check - Main

Open Main Menu, Rates, Rate Check Classic 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 primary 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 a SA ID, the service agreement's current rate will be defaulted.

While using a SA ID is not strictly required to check a rate, we strongly recommend finding a representative service agreement to check a rate. Why? Because charges in a rate may be affected by values in a service agreement. For example, consider the following types of rate components that use service agreement-specific values:

- Rate components with bill factors that are subject to the presence of contract riders. In fact, if a bill factor requires a contract rider and you do not specify a SA ID rate check assumes that the rider is applicable.

- Rate components with bill factors that are subject to tax exemptions.

- Rate components with bill factors with customer-specific prices.

- Rate components with service quantity (SQ) rules that use characteristics on service agreement, account or the service agreement's characteristic premise.

- Rate components with SQ rules that use contract quantities.

In other words, if you don't specify a SA ID, you will not be able to check rates with the above characteristics.

Enter a Bill Seg ID if you want to test the rate with actual usage for a given bill segment. This is useful if you want to compare the actual bill segment results with the results of the same usage under a different rate schedule. If you indicate a Bill Seg ID, rate check's SA ID will be populated with the bill segment's service agreement ID (and SA ID will be protected).

Note:

Overriding consumption. If you enter a Bill Seg ID, the bill segment's consumption will be defaulted into the consumption array that follows. You may override this consumption 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 customer'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.

Note:

Consumption Period. Refer to Determine The Consumption Period For Metered Service for information about how the consumption period is calculated before applying the rate.

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/ SQI combination, enter a register quantity.

Note:

Default note. If you indicate a bill segment, the quantity grid will be populated with data from the bill segment's meter read snapshot collection. This includes the UOM/TOD/SQI quantities and the Service Points associated with these quantities.

Enter the Service Point ID if your rate uses register rules that require characteristic values from the service point or premise. For example, the register rule that converts CCF to therms uses a bill factor to store the conversion factor. This bill factor may have been configured to use characteristics on the service point / premise (e.g., the conversion factor may differ based on the storage location associated with the service point).

Note:

Overriding service points. If you specify a SA ID, you may indicate a service point that is not connected to your service agreement (if you want to experiment with the effect of different service point characteristics on the rate).

The collection of Characteristic Types and Characteristic Values is used to apply the appropriate bill factor values. If these values are entered, these values will be used to apply the appropriate bill factors (even if you have specified a service agreement from which characteristics can be derived). If these values are blank AND there is no SA 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 primary Rate Schedule (and any applicable sub rates) 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 Hdr, the following information will be displayed above the calculation line grid.

Sequence This identifies which Bill Seg Hdr 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 customer'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 customer's bill.

- The App 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 service quantity priced on the calculation line.

- TOU is the time-of-use code of the service quantity priced on the calculation line.

- SQI is the service quantity identifier of the service quantity priced on the calculation line.

- Billable Service Quantity is the service quantity priced on the calculation line. This quantity will be different from the measured consumption is there are SQ 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.

- 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 priced on the calculation line is used to measure a peak quantity.

- Exempt Amount is the amount of the calculated charge that the customer doesn't have to pay because they are tax exempt. This will only be calculated if you have provided an SA ID on the main page.

- 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 - SQ Details

After you have pressed the Check Rate button on the Main page, you can navigate to the SQ Details tab to view the service quantities that supplied to (or derived by) you rate. Please be aware that a rate can derive service quantities if there are register rules, service quantity rules or time-of-use mapping 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 SQ details grid is a snapshot of the service quantities amassed from:

- The quantities input on the main page OR the quantities taken from the service quantity collection for the bill segment, if it was input on the main page.

- The SQ rules defined on the input rate.

- The register rules defined on the input rate.

The following information is displayed in the grid:

- UOM is the unit of measure of the service quantity.

- TOU is the time-of-use code of the service quantity.

- SQI is the service quantity identifier of the service quantity.

- Initial Service Quantity is the initial quantity amassed by the system before application of the rate's SQ rules.

- Billable Service Quantity is the service quantity that will be priced by the service agreement's rate. This amount differs from the initial service quantity when the rate's SQ rules manipulate consumption.

Rate Check Results - Register Read

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 SQI) that were derived by your rate's register rules.

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 Register Read collection for the bill segment indicated on the main page of Rate Check

The final quantities will reflect any changes to the measured quantities resulting from applied register rules.

The following information is displayed in the grid:

- UOM is the unit of measure of the measured quantity.

- TOU is the time-of-use code of the measured quantity.

- SQI is the service quantity identifier of the measured quantity.

- Measured 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 SQI is the service quantity identifier of the resultant billing quantity.

- Register Quantity is the resultant billing quantity.

- Service Point ID displays information about the service point used by rate check to determine any characteristic values needed for the register rules.

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.

Use Sub Rate Schedules To Encapsulate Common Rate Components

Many implementations have multiple rate schedules that share common rate components. For example, the following illustration shows two rate schedules that use identical rate components to calculate taxes:

Two Rate Schedules That Share Common Rate Components

Rather than duplicate the taxation rate components on both rates, a sub rate schedule can be constructed that references the shared rate components. The sub rate schedule can then be included on each of the primary rate schedules:

Setting Up A Sub Rate Schedule To Encapsulate Common Rate Components

The primary reason to encapsulate common rate components into sub rate schedules is to simplify long-term maintenance. For example, if a new tax is introduced, only the sub rate schedule in the above example would require modification. The converse is also true. For example, if pricing structures are changed, only the affected primary rate schedules require modification. Both of these scenarios result in reduced rate construction and testing time.

The topics in this section describe sub rate schedules in more detail.

Contents

Sub Rate Schedules and Primary Rate Schedules Have Similar Features

Primary Rates May Reference Many Sub Rates

How To Set Up A Sub Rate Schedule

Sub Rate Schedules and Primary Rate Schedules Have Similar Features

Most of the rich functionality described above is shared by both sub rate schedules and primary rate schedules. The following points highlight the major differences:

- Only primary rate schedules can be referenced on a customer's service agreement and on an adjustment type's generation algorithm.

- Only primary rate schedules can reference sub rate schedules.

- Sub rate schedules cannot reference a service type, a currency code, the allow estimates indicator, register rules or valid meter configurations. This is because these attributes are defined for the primary rate schedule used to drive the calculation.

- When charges are calculated for a primary rate schedule's sub rate schedules, the primary rate schedule's frequency is used. This allows a single sub rate schedule to be referenced on any primary rate schedule regardless of the primary rate schedule's frequency. This means that sub rate schedules do not reference a frequency.

- Because sub rate schedules inherit the frequency of the primary rate schedule at execution time, Rate Check cannot be used to verify sub rate schedules directly. Rather, use a primary rate schedule that references the sub rate schedule on Rate Check.

Primary Rates May Reference Many Sub Rates

There is no limit to the number of sub rate schedules that can be referenced on a primary rate schedule. If multiple sub rate schedules are defined on a primary rate schedule, the primary rate schedule defines the invocation order of each.

A bill segment that is calculated using a rate will contain separate bill calculation details for each primary rate schedule and sub rate schedule used in its calculation. Please be aware of the following special scenarios that can affect the number of bill calculation details on a bill segment:

- If a given primary or sub rate schedule has multiple rate versions effective during a bill segment's calculation period, a separate bill calculation detail will be created for each version of every primary and sub rate schedule.

- It is possible for a sub rate schedule to not contribute any charges to a bill segment (for example, if its rate components have eligibility rules that inhibit the creation of calculation lines). If a sub rate schedule does not contribute additional charges or service quantities to a bill segment, the system will suppress the bill calculation detail. In other words, an empty bill calculation detail is not created if a subsidiary rate schedule contributes nothing new to a bill segment.

An adjustment that is calculated using a primary rate schedule will contain a separate calculation line for every rate component on the primary and sub rate schedules that contribute charges to the adjustment.

How To Set Up A Sub Rate Schedule

Sub rate schedules are set up using the same transactions as primary rate schedules. With the exception of the differences outlined above, the design and construction of sub rate schedules is virtually identical to that of primary rate schedules.

The major difference occurs when a sub rate schedule has rate components that require the value of lines calculated by the primary rate schedule or earlier sub rate schedules. Rate components that levy taxes using the monetary value calculated by earlier rate schedules are good examples. In order to implement these types of rate components on a sub rate schedule, follow these instructions:

- Set up a Rate Component - Calculation Algorithm that references the base-package algorithm type called C1-RC-CLAMT . Algorithms of this type calculate the value of a rate component by summarizing the value of lines calculated by earlier rate components. Please note that you can limit the summarized lines to those calculated by rate components that are marked with a given characteristic type and value.

- Add a rate component to the sub rate schedule:

- Choose a Rate Component Typeof Calculation Algorithm .

- Select the Calculation Algorithm defined above.

- Turn on FCPO (for calculation purposes only) to prevent the value of this line from being added to the total charges.

- Set up Apply To rate components as normal for each tax to be calculated. These rate components will reference the rate component described above in their cross reference.

Setting Up Estimated Consumption For Items

Some types of physical devices (i.e., items) use power but a meter does NOT measure the power consumed. The most common example is a street light. If this situation exists for your company AND if the amount charged for the lamp varies based on the amount of estimated power used, then you will have to maintain estimated DAILY consumption for each type of item. The system uses this information at billing time to estimate how much power was used by the customer's items and then prices the estimated consumption as per the terms in the service quantity rate component.

Select Admin Menu, Item Type SQ Estimate to define estimated consumption.

Description of Page

Select the Item Type using the search.

Enter the estimated daily consumption in the Daily Service Quantity. Each Service Quantity has an Effective Date so that changes in the estimated quantities may be recorded over time.

Note:

The unit of measure of the daily service quantity is displayed adjacent to the item type description. This value is defined on the item type table. Refer to Setting Up Item Types for more information.

Where Used

This information is used when the system calculates a bill segment for a service agreement that references service points with items. If the items reference item types for which the system should estimate consumption, the system extracts the daily consumption amount from this table.

Setting Up Degree Days (and Average Temperatures)

Many organizations print degree-day and/or average temperature information on their customers' bills. Select Admin Menu, Degree Days to define these values for a given trend area.

Description of Page

The easiest way to define degree days is to select a Trend Area and Month In Year and tab out of the field. The system generates one row in the Degree Days collection for each day of the month. After the days exist in the collection, you should define the following for each day:

Degree Day This is a unit of measure used to express the extent to which temperatures vary from a specific reference temperature on a given date.

Maximum Temperature This is the maximum temperature on a given date.

Minimum Temperature This is the minimum temperature on a given date.

Average Temperature This is the average temperature on a given date.

Where Used

This information may be used by your bill print routines.

Effective Dates & Price 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.

- The customer's tax exemption changes.

- The customer-specific price can change.

- etc.

Contents

Types of Proration

Proration Factors

Overriding Proration Factors

Service Quantity Proration

Rate Component Value Proration

Bill Factor Value Proration

Example of Generating Prorated Bill Calculation Lines

Seasonal Proration

Price Changes and Interval Quantities

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.

Contents

Consumption Period Proration

Calculation Period Proration

Bill Factor Proration

A Service Agreement Rate Changes Are Not Prorated

Consumption Period Proration

A rate schedule specifies its frequency. Bill segments generated using a rate are expected to have a consumption period that corresponds to this frequency. When a bill segment's consumption period falls outside of the rate frequency's normal period, proratable service quantities may be adjusted to match the normal period for calculation. The service quantities are then re-adjusted based on calculation period proration.

Fastpath:

Refer to Service Quantity Proration for more information about these calculations.

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 consumption 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 customer.

Fastpath:

Refer to Defining Rate Versions for more information about rate versions.

Bill Factor Proration

A rate contains rate components. The primary reason a rate component exists is to define how much to charge for the services sold by your company. 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 bill factor that contains the value.

Bill factors are effective-dated (i.e., their values may change over time). When the system detects that a rate component's bill factor has multiple values 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 bill factor's proration parameters.

Fastpath:

Refer to Defining Bill Factors and Bill Factor Value Proration for more information.

Contents

Tax Exemption Proration

Contract Value Proration

Contract Rider Proration

Tax Exemption Proration

Bill factors that levy taxes may or may not be eligible for tax exemptions; it's up to the respective taxing authority. Customers who are eligible for tax exemptions will have their tax obligation reduced (or nullified) at billing time.

Whether or not a customer is tax exempt (and the percent exempt) is defined on the service agreement's tax exemption page. A customer's tax exemptability is effective-dated (i.e., it may change over time). If a customer's tax exemptability changes during a bill period, the system may or may not prorate the charges. You control exactly how the system handles this situation using the bill factor's proration parameters.

Contract Value Proration

Some types of bill factors do not have the same value for all customers. For example, you may have rates where the price per kilowatt-hour can be different for every customer using the rate.

For bill factors whose value is customer-specific, the value is defined on the service agreement's contract value page. The contract value is effective-dated (i.e., it may change over time). If a customer's contract value changes during a bill period, the system may or may not prorate the changes. You control exactly how the system handles this situation using the bill factor's proration parameters.

Contract Rider Proration

Contract riders are used when the charge associated with a bill factor is only applicable to some customers for some period of time. For example, if a bill factor is used to provide a discount during the first 3 months of service, then a contract rider would be used.

A customer's contract rider applicability period is defined on the service agreement's contract rider page. A rider's applicability may change during a customer's bill period. You control exactly what the system does when a rider's applicability changes during a bill period using the bill factor's proration parameters.

A Service Agreement Rate Changes Are Not Prorated

A service agreement's rate is effective-dated (i.e., it may change over time). When the system calculates a service agreement's bill segment when multiple rates are effective during the bill period, it will use a single rate from the service agreement's rate history. The system chooses the rate as per the service agreement's SA type's rate selection date.

Fastpath:

Refer to SA 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. Service quantities, step boundaries, rate values, and bill factor values may all be prorated as part of applying a rate.

We need to establish some terms in order to understand the calculations.

Contents

Normal Days

Consumption Period Factor

Calculation Period Factor

BF Value Period Factor

Normal Days

As mentioned previously, the rate schedule references a frequency that specifies the number of times per year that service agreements 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.

Consumption Period Factor

Before applying a rate, the bill segment's consumption period is determined. The ratio of normal days to consumption period days is the consumption period factor.

The system uses the Minimum and Maximum Days Offset on the rate's Frequency to determine whether or not the rate component should be prorated due to a short or long consumption period.

If the number of days in the consumption period is within the tolerance of days determined by the specified on the rate's frequency, the consumption period factor is 1 (not applicable).

Example:

If the consumption period spans 60 days and the rate's normal days equals 30 days then the consumption period factor is:

- 30 days / 60 days = 0.5.

If the consumption period spans 31 days and the rate's normal days equals 30 days and the maximum offset is 3 days, the consumption period factor is 1 (not applicable) because the consumption period days falls within the tolerance specified on the frequency.

Fastpath:

For more information on how a bill segment's consumption period is determined, refer to How The System Determines How Much Was Consumed. For more information on specifying minimum and maximum offset days on frequency, refer to Defining Frequency Codes.

Calculation Period Factor

The calculation period is the date range where a rate version is effective during the consumption period. For each rate version that is effective during the consumption 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 consumption period factor is 1 (not applicable), then the calculation period factor is the ratio of calculation period days to consumption period days.

Example:

If the consumption period covers April 1 to April 30 and there was a new effective rate version as of April 21, there are two calculation periods.

- Calculation period April 1 to April 20, calculation period factor = 20 days / 30 days = 0.6666667.

- Calculation period April 21 to April 30, calculation period factor = 10 days / 30 days = 0.3333333.

BF Value Period Factor

The bill factor value period is the date range where a proratable bill factor value is effective during the calculation period.

When a bill 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 BF value period factor. When the bill factor is set up not to prorate, the BF 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 bill factor value periods.

- Bill factor value period April 1 to April 15, BF value period factor = 15 days / 30 days = 0.5.

- Bill factor value period April 16 to April 30, BF value period factor = 15 days / 30 days = 0.5.

Fastpath:

Refer to Defining Bill Factors for more information on specifying whether the bill 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.

Service Quantity Proration

When a bill calculation line is generated for a service quantity type rate component, the applicable service quantity is multiplied by the consumption period factor. That product is then multiplied by the calculation period factor to determine the prorated service quantity for the bill calculation line.

Example:

Customer's electricity bill segment's consumption period is from April 1 through May 15. A new rate version for the rate schedule is effective as of April 16. 100 kWh is consumed.

Assuming a monthly frequency, if the consumption period spans 45 days and the first calculation period spans 15 days, and the applicable service quantity is 100 kWh; then:

- Consumption period factor = 30 normal days / 45 days = 0.6666667.

- Calculation period factor = 15 days / 30 normal days = 0.5.

- Prorated service quantity = 100 kWh x 0.6666667 x 0.5 = 33 kWh.

The next calculation period extends to the end of the consumption period (30 days):

- Consumption period factor does not change = 0.6666667.

- Calculation period factor = 30 days / 30 days = 1.0.

- Prorated service quantity = 100 kWh x 0.6666667 x 1.0 = 67 kWh.

Contents

Measures Peak

Step Proration

Step Multipliers

Measures Peak

If the rate component specifies that the service quantity measures peak, then service quantity proration is not performed. Although service quantities are not prorated if a rate component measures peak, rate component values (like price per kW) are prorated.

Fastpath:

Refer to Rate Component Value Proration for more information about how rate component values are prorated.

Step Proration

If a rate component's charges are based on stepped pricing 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.

Example:

Assuming a monthly frequency, if the rate component's step boundaries are 100 kWh to 300 kWh, and the calculation period is 45 days; the step boundaries are prorated as:

- 45 days / 30 days x 100 kWh = 150 kWh.

- 45 days / 30 days x 300 kWh = 450 kWh.

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 bill 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 bill factor value change, bill 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 bill factor value changed on the referenced rate component, bill factor value proration still applies.

Example:

A rate component a rate version charges $2.00 per kW. The rate schedule's normal days equals 30, and the calculation period spans 15 days. The peak kW service quantity is 50 kW.

- The calculation period factor is 0.5 (15 days / 30 days).

- Rate component value proration yields $2.00 x 0.5 = $1.00 per kW.

Fastpath:

For more information on bill factor value proration, refer to Bill Factor Value Proration.

Bill Factor Value Proration

Bill factor value proration behaves the same way any time a bill factor value changes within a calculation period. This could be due to a change in a tax rate, a contract rider becoming effective, a tax exemption expiring, etc.

Multiple bill calculation lines are generated for a given rate component when a proratable bill 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 BF value factor period April 1 to April 15, so BF 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 bill factor value period is April 16 to April 30, so the BF 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%.

Example of Generating Prorated Bill Calculation Lines

Let's say that 1200 kWh was consumed from March 17 to April 30. The peak kW for the consumption period is 20 kW.

A monthly rate schedule E-COM1 exists with two rate versions.

Rate version effective prior to April 1 has the following components:

- $0.05 per kWh.

- $1.00 per kW.

Rate version effective as of April 1 has the following rate components:

- $0.04 per kWh; as of April 16, $0.07 per kWh (new effective bill factor value).

- $1.50 per kW; as of April 16, $1.25 per kW (new effective bill factor value).

Calculation Period March 17 to March 31

The consumption period spans 45 days, so the consumption period factor is 30 normal days / 45 days = 0.6666667.

This calculation period spans 15 days, so the calculation period factor is 0.5.

Service quantity proration for the first calculation period yields:

- 1200 kWh x 0.6666667 (consumption period factor) x 0.5 (calculation period factor) = 400 kWh.

- 20 kW x 1 (not applicable) = 20 kW.

Rate component value proration for the first calculation period yields:

- $0.05 x 1 (not applicable) = $.05 per kWh.

- $1.00 x 0.5 (calculation period factor) = $0.50 per kW.

First Set of Bill Calculation Lines

Bill calculation line 1: 400 kWh x $0.05 = $20.00.

Bill calculation line 2: 20 kW x $0.50 = $10.00.

Calculation Period April 1 to April 30

This calculation period spans 30 days, so the calculation period factor is 1.

Service quantity proration for the calculation period yields:

- 1200 kWh x 0.6666667 (consumption period factor) x 1 (calculation period factor) = 800 kWh.

- 20 kW x 1 (not applicable) = 20 kW.

Rate component value proration for the first calculation period yields:

- $0.04 x 1 (not applicable) x 0.5 (BF value period factor) = $0.02 per kWh.

- $0.07 x 1 (not applicable) x 0.5 (BF value period factor) = $0.035 per kWh.

- $1.50 x 1 (calculation period factor) x 0.5 (BF value period factor) = $0.75 per kW.

- $1.25 x 1 (calculation period factor) x 0.5 (BF value period factor) = $0.625 per kW.

Second Set of Bill Calculation Lines

Bill calculation line 1: 800 kWh x $0.02 per kWh = $16.00.

Bill calculation line 2: 800 kWh x $0.035 per kWh = $26.00.

Bill calculation line 3: 20 kW x $0.75 per kW = $15.00.

Bill calculation line 4: 20 kW x $0.625 per kW = $12.50.

Seasonal Proration

Seasonal proration adds another layer of complexity. If rate components are specified to prorate seasonally, the seasonal period specified on a given seasonal rate component dictates how a rate component's value or associated service quantity is prorated.

There are two proration methods, Prorate and Prorate seasonal SQ , which may be specified on seasonal rate components. Both of these proration methods behave the same way with respect to rate component value proration. If a given seasonal rate component is eligible for Rate Component Value Proration, the ratio of days in the season that are applicable during the calculation period to the days in the calculation period determines the seasonal factor. When it comes to service quantity proration, the two proration methods are different. If a given seasonal rate component is eligible for Service Quantity Proration, it prorates the service quantities as follows:

- Prorate . A seasonal factor is calculated as the ratio of days in the season that are applicable during the calculation period to the days in the calculation period. This ratio is applied along with the consumption period factor and calculation period factor to determine the prorated service quantity.

- Prorate seasonal SQ . In this case, it is assumed that either the meter measures seasonal consumption on separate registers or the consumption has been split into separate service quantities by other means (like an SQ rule). To determine a prorated seasonal service quantity, the seasonal proration factor is calculated as for a Prorate seasonal rate component. The seasonal factor is then multiplied by another ratio of total consumption period days to days in the season that are applicable for the total consumption period. This modified seasonal factor is applied along with the consumption period factor and calculation period factor to determine the prorated service quantity.

Note:

Prorate seasonal SQ. Specify this option only if you can determine the seasonal consumption as an independent service quantity for use by rate application. Because the service quantities themselves dictate the applicability of the rate component, a given service quantity need not appear in rate versions effective outside the season (i.e. a rate version effective on October 1 may not include rate components that charge for kWh/summer).

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. For example, perhaps the seasonal period is determined dynamically based on the scheduled meter read date of the bill cycle.

Example ( Prorate ):

Let's say that 600 kWh and 50 kW are the billable service quantities for a consumption period from April 1 to April 30. Prorate seasonal rate components are defined on a monthly rate that charge $0.05 per kWh and $0.75 per kW from January 1 to April 15. Prorate seasonal rate components are defined on the same rate version that charge $0.06 per kWh and $0.80 per kW between April 16 and December 31. Assume only one rate version is effective for the consumption period.

- The consumption period factor is 1 (not applicable).

- The calculation period factor is 1.0.

- The seasonal factor for the kWh rate component whose season is effective from January 1 to April 15 is 0.5 (15 season days in calculation period / 30 days in the calculation period).

- The resulting bill calculation line uses service quantity proration:

- 600 kWh x 0.5 (seasonal factor) x $0.05 = $15.00.

- The seasonal factor for the kW rate component whose season is effective from January 1 to April 15 is also 0.5.

- The resulting bill calculation line uses rate component value proration:

- 50 kW x $0.75 x 0.5 (seasonal factor) = $18.75.

- The seasonal factor for the kWh rate component whose season is effective from April 16 to December 31 is 0.5.

- The resulting bill calculation line uses service quantity proration:

- 600 kWh x 0.5 (seasonal factor) x $0.06 = $18.00.

- The seasonal factor for the kW rate component whose season is effective from April 16 to December 31 is also 0.5.

- The resulting bill calculation line uses rate component value proration:

- 50 kW x $0.80 x 0.5 (seasonal factor) = $20.00.

Example ( Prorate seasonal SQ ):

Let's say that a given meter measures winter consumption separate from summer consumption. The meter itself measures kWh/summer on a register between June 21 and September 18, and measure kWh/winter on another register at other times of the year.

We are generating a bill segment with a consumption period from September 2 to October 30. A monthly rate schedule has two rate versions effective during the consumption period. The latest rate version is effective on October 1.

Each of the rate versions has Prorate seasonal SQ seasonal rate components defined. The first rate version's rate components charge $0.06 per kWh/summer and $0.05 per kWh/winter. The second rate version has a single rate component that charges $0.05 per kWh/winter.

Assume that the billable service quantities are 800 kWh/summer and 1600 kWh/winter.

First set of bill calculation lines (September 2 to September 30):

- The consumption period factor is 30 normal days / 60 consumption days = 0.5.

- The calculation period factor is 30 calculation days / 30 normal days = 1.0.

- Rate Component 1 ($0.06 per kWh/summer):

- The seasonal factor 17 seasonal days / 30 calculation days = 0.5666667.

- The modified seasonal factor is 0.5666667 x 60 consumption days / 17 seasonal days = 2.0.

- The resulting bill calculation line:

- 800 kWh/summer x 0.5 (consumption period factor) x 2.0 (modified seasonal factor) x $0.06 = $48.00.

- Rate Component 2 ($0.05 per kWh/winter):

- The seasonal factor is 12 seasonal days / 30 calculation days = 0.4.

- The modified seasonal factor is 0.4 x 60 consumption days / 42 seasonal days = 0.571428.

- The resulting bill calculation line:

- 1600 kWh/winter x 0.5 (consumption period factor) x 0.571428 (modified seasonal factor) x $0.05 = $22.86.

Second set of bill calculation lines (October 1 to October 30):

- The consumption period factor is 30 normal days / 60 consumption days = 0.5.

- The calculation period factor is 30 calculation days / 30 normal days = 1.0.

- Rate Component 1 ($0.05 per kWh/winter):

- The seasonal factor 30 seasonal days / 30 calculation days = 1.0.

- The modified seasonal factor is 1.0 x 60 consumption days / 42 seasonal days = 1.428571.

- The resulting bill calculation line:

- 1600 kWh/winter x 0.5 (consumption period factor) x 1.428571 (modified seasonal factor) x $0.05 = $57.14.

Fastpath:

For more information on specifying seasonal proration options, refer to Defining Rate Components.

Price Changes and Interval Quantities

All of the above sections described situations where the service quantities will be prorated due to changes in the price during the billing period. The above sections assume that the bill contains a simple metering scenario, where reads will not exist on the date of the price break.

However, consider an interval billing example. There are two basic pricing scenarios for interval quantities:

- Interval prices are applied to interval quantities. In this case, proration is not applicable because the prices are changing at small intervals and the appropriate algorithms understand how to apply the prices to the interval quantities. Refer to Interval Pricing for more information.

- Time of use prices. In this case, interval quantities are being mapped to time of use codes before applying time of use prices. The standard rate component algorithm will compare interval quantities to a time of use map resulting in new entries in the bill segment's SQ collection. The algorithm will then apply the appropriate price for each SQ based on the TOU Pricing bill factor. In the time of use pricing scenario, it is possible for the TOU prices to change during the bill period. When this happens, proration should not be necessary because readings will exist for the date of the price break. Refer to Time of Use Mapping and Pricing for more information.

Rate Examples

In this section, we provide examples of how to set up some charges that occur in many organizations. While your rates may not possess these exact charges, this section should help solidify your understanding of how to set up your company's rates.

Contents

A Simple Electric Rate

Adding Measured Quantities Together

CCF To Therm Conversion

How To Adjust Measured Consumption By A Minimum Contract Quantity

Elevation Charges

Gas Pressure Factor Adjustments

Pricing Interval Consumption Using Interval Prices

Pricing Non Interval Consumption Using Weighted Average Prices

Employee Discounts

Customer Specific Prices

Hours-Based Electric Rate

Step Boundaries Based On The Number Of Days Of Usage And The Region In Which The Customer

Calculated Minimum Charges

Stepped Taxes

A Simple Electric Rate

The following table illustrates the rate components necessary to levy a simple rate that contains the following charges:

- Monthly service charge: $10.00.

- First 300 kilowatt hours at $0.0382 per kWh.

- Remaining kilowatt hours at $0.0673 per kWh.

- State Tax at the prevailing rate (this tax is a percentage of a dollar value).

- County Use Tax at the prevailing rate (this tax is an amount per kilowatt hour).

Seq #

RC Type

Value Type

Value

Bill Factor

Item

Type

UOM/TOU/SQI

Step Range

Cross Reference

10

Flat Charge

Charge

10.00

20

Service Quantity

Unit Rate

0.0382

KWH

0 to 300

30

Service Quantity

Unit Rate

0.0673

KWH

300 to 99999999

40

Summary

20, 30

50

Apply To

Percent

STTAX

10, 20, 30

60

Apply To

Unit Rate

COUNTYTAX

20, 30

The following table illustrates how you might want to define the Description on Bill for these rate components.

Seq #

Description on Bill

10

Monthly service charge of %R %D

20

First %Q kWh at %I per kWh %F

30

Remaining %Q kWh at %I per kWh %F

40

Subtotal

50

State sales tax %R %T

60

County use tax %R per kWh %T

Adding Measured Quantities Together

Fastpath:

Refer to the how to section under Setting Up Service Quantity (SQ) Rules for more information.

CCF To Therm Conversion

Fastpath:

Refer to the how to section under Setting Up Register Rules for more information.

How To Adjust Measured Consumption By A Minimum Contract Quantity

Fastpath:

Refer to the how to section under Setting Up Service Quantity (SQ) Rules for more information.

Elevation Charges

Assume you have rates that charge a different amount per gallon depending on the elevation. For example, customers on rate X who live between sea level and 500 feet are charged $0.001 per gallon; customers living over 500 feet are charged $0.0015 per gallon. Customers on rate Y who live between sea level and 500 feet are charged $0.002 per gallon; over 500 feet are charged $0.0025.

Contents

Elevation Charges - Characteristics

Elevation Charges - Bill Factors

Elevation Charges - Rate Schedule and Rate Components

Elevation Charges - Characteristics

Given the elevation gradients are the same for rates X and Y, you can set up a characteristic called ELEV and assign it characteristic values of < 500 and > 500 . If possible, you should indicate the appropriate characteristic value for each postal default so that new premises will receive their appropriate characteristic value. If premises already exist, you must populate this characteristic value accordingly.

Elevation Charges - Bill Factors

Because each rate charges a different price per gallon depending on the characteristic, you'll need two bill factors - one for rate X, the other for rate Y. Both will reference the newELEVcharacteristic. The only difference will be their bill factor values.

Elevation Charges - Rate Schedule and Rate Components

You will create two rate schedules - one for rate X, the other for rate Y. Rate X will have a rate component that references the rate X elevation bill factor. Rate Y will have a rate component that references the rate Y elevation bill factor.

Note:

Alternatives. The design of the system would allow you to create a single rate rather than two rates. How? In the single rate you would have two rate components referencing the two elevation bill factors. You would indicate that both bill factors are contingent on the presence of a contract rider by turning on the bill factors' contract rider flags. When you set up a service agreement for a customer, you would create a contract rider referencing the necessary bill factor. We don't recommend this approach because you are not accurately reflecting your actual rates with corresponding rates in the system. We showed this approach to provide an alternative way of thinking about your rates.

Gas Pressure Factor Adjustments

Assume you have rates that require a cubic foot of gas converted based on the pressure factor associated with the premise. Assume there's a different pressure factor based on the take point from which the gas is pumped.

Contents

Pressure Factor - Characteristics

Pressure Factor - Bill Factors

Pressure Factor - Register Rule

Pressure Factor - Rate Schedule

Pressure Factor - Characteristics

Create a characteristic called TAKEPT and assign it characteristic values for each take point in your service area. If possible, you should indicate the appropriate characteristic value for each postal default so that new premises will receive their appropriate characteristic value. If premises already exist, you must populate this characteristic value accordingly.

Pressure Factor - Bill Factors

Set up a bill factor called PF ADJ . On the bill factor, indicate that it uses the TAKEPT characteristic. Create a bill factor value for each take point to define its respective pressure factor.

Pressure Factor - Register Rule

Create a register rule called CCFPFADJ . Populate it with the following information:

Field

Value

Register Algorithm

Bill factor based UOM conversion

UOM (Source)

CCF

UOM (Result)

CCF PF

Bill Factor

PF ADJ

This register rule will convert a metered amount of cubic feet to a pressure factor adjusted amount of cubic feet using the bill factor.

Pressure Factor - Rate Schedule

Link the CCFPFADJ register rule to every rate that requires a pressure factor adjustment.

Pricing Interval Consumption Using Interval Prices

Assume you have interval meters that measure how much was consumed at various times during a day. You may need to price each interval read using the real time price that's effective on the read's start date and time.

Note:

, this example assumes that you do not have the interval billing subsystem and are recording your interval reads in the Meter Read table.

Contents

Real Time Pricing - Bill Factors

Real Time Pricing - Service Quantity Identifier

Real Time Pricing - Register Rule

Interval Billing - Rate Schedule

Real Time Pricing - Bill Factors

Set up a bill factor called RTP . On the bill factor, indicate that it uses the N/A characteristic. Also, set the bill factor type to Interval . You will also have to Maintain Interval Values for the bill factor.

Real Time Pricing - Service Quantity Identifier

Set up a service quantity identifier called $ .

Real Time Pricing - Register Rule

Create a register rule called REALTIME . Populate it with the following information:

Field

Value

Register Algorithm

Real time pricing

UOM

KWH

Bill Factor

RTP

SQI (Result)

$

This register rule will convert a metered amount of KWH into a dollar value using the real time price in effect on the read's start date and time.

Interval Billing - Rate Schedule

Link the REALTIME register rule to every rate that requires such. These rate will also require a SQ rate component with a price of $1 and a SQI of $ .

Pricing Non Interval Consumption Using Weighted Average Prices

Refer to Interval Values Can Be Used For More Than Just Interval Meters to understand the business situation.

Contents

Weighted Average Pricing - Bill Factors

Weighted Average Pricing - RC Algorithm

Weighted Average Pricing - Rate Component

Weighted Average Pricing - Bill Factors

Set up a bill factor called WAP . If you assume you have different WAP's depending on the customer's load profile, indicate that it uses the LOADPROF characteristic type. Also set the bill factor type to Interval . You will also have to Define Interval Values for the bill factor.

Weighted Average Pricing - RC Algorithm

Create an algorithm called WAP . Populate it with the following information:

Field

Value

Algorithm Type

PX VALUE

Bill Factor

RAP

Refer to PX VALUE for information about this algorithm.

Weighted Average Pricing - Rate Component

Create a SQ rate component on the respective rate(s).

Seq #

RC Type

Value Type

Value

Source

Value

Algorithm

20

Service Quantity

Unit Rate

Algorithm

WAP

Employee Discounts

Assume your organization provides discounts of 25% to employees for their residential consumption.

Contents

Employee Discounts - Characteristics

Employee Discounts - Bill Factors

Employee Discounts - Rate Schedule and Rate Components

Employee Discounts - Start Option

Employee Discounts - Service Agreements

Employee Discounts - Characteristics

Because the discount amount is the same for all employees, you just need a dummy characteristic to keep the relational model consistent. You should set up a characteristic type called N/A and with a characteristic value of N/A . It's important that the characteristic value is identical to the characteristic type otherwise billing will generate an error.

Employee Discounts - Bill Factors

Set up a bill factor called EMPDISC . On the bill factor, indicate that it uses the characteristic described above and that it is contingent on the presence of a contract rider. Create a bill factor value with an amount of -25%.

Employee Discounts - Rate Schedule and Rate Components

On every residential rate that is eligible for employee discounts, you will have a rate component that references the EMPDISC bill factor.

Employee Discounts - Start Option

Create a start option for every SA type that can use one of your employee discount rates. The start option should contain a contract rider that references the EMPDISC bill factor.

Employee Discounts - Service Agreements

On existing service agreements of employees eligible for a discount, add a contract rider referencing the EMPDISC bill factor.

Customer Specific Prices

Assume your organization has some rates where the customer may negotiate specific prices.

Contents

Customer Specific Prices - Bill Factors

Customer Specific Prices - Rate Schedule and Rate Components

Customer Specific Prices - Start Option

Customer Specific Prices - Service Agreements

Customer Specific Prices - Bill Factors

Set up a bill factor called KWHCUST . On the bill factor indicate that it:

- Uses a N/A characteristic (you need a characteristic on all bill factors). Refer to Employee Discounts for an example.

- Has a value type of Unit Rate .

- Has its value specified in a contract term.

- Should generate an error if it finds no value in the contract.

Define the standard bill factor value to use for those customers who do not elect to negotiate a specific price.

Customer Specific Prices - Rate Schedule and Rate Components

On every rate that may allow a customer specific price, you will have a rate component that references the KWHCUST bill factor.

Customer Specific Prices - Start Option

Create a start option for every permissible price on every SA type with such rates. The start option should contain a contract value that references the KWHCUST bill factor. You will also have a start option to use for those customers to do not elect to negotiate a specific price. This start option will not define a contract value.

Customer Specific Prices - Service Agreements

For existing service agreements using this rate where the customer has negotiated a specific price, add a contract value referencing the KWHCUST bill factor.

Hours-Based Electric Rate

Warning:

If your organization does not sell electric service (or if you do and don't use hour-based steps) you might want to skip this example as it involves understanding a fairly complex electric concept - kwh / kw = hours.

The following table illustrates the rate components necessary to levy a rate that contains the following charges:

- Monthly service charge: $10.00.

- First 10 hours of use at $0.0673 per kWh.

- Remaining hours of use at $0.032 per kWh.

- State Tax at the prevailing rate (this tax is a percentage of a dollar value).

- County Use Tax at the prevailing rate (this tax is an amount per kilowatt hour).

Seq #

RC Type

Value Type

Value

Bill Factor

Item

Type

UOM/TOU/SQI

Step Range

Cross Reference

Calc Only

Result Type

10

Flat Charge

Charge

10.00

N

20

Service Quantity

Unit Rate

1.0

KW

Y

Unit Rate

30

Service Quantity

Unit Rate

0.0673

KWH

0 to 10 Multiply by RC: 20

N

40

Service Quantity

Unit Rate

0.032

KWH

10 to 99999999 Multiply by RC: 20

N

50

Summary

30, 40

N

60

Apply To

Percent

STTAX

10, 30, 40

N

70

Apply To

Unit Rate

COUNTYTAX

30, 40

N

Contents

Hours-Based - For Calculation Purposes Only Rate Component

Hours-Based - Dynamic Stepped SQ Rate Components

Hours-Based - Descriptions On Bill

Hours-Based - For Calculation Purposes Only Rate Component

The strange thing about this rate is rate component 20. It is used "for calculation purposes only". Notice what it's calculating - the number of kilowatts (KW). Why is it necessary? Because hour-based steps have to be multiplied by the number of KW used by the customer in order to derive the real KWH based steps. Why? Because number of KWH / number of KW = number of hours. Therefore an hour * number of KW = number of KWH.

Hours-Based - Dynamic Stepped SQ Rate Components

Notice that rate components 30 and 40's step boundaries are multiplied by the amount calculated by rate component 20 (i.e., the number of KW).

Hours-Based - Descriptions On Bill

The following table illustrates how you might want to define the Description on Bill for these rate components.

Seq #

Description on Bill

Print on Bill

10

Monthly service charge of %R %D

Y

20

Calculate only rate to determine Hourly charge step multiplication factor.

N

30

First %Q hours of usage at %I per kWh %F

Y

40

Remaining %Q hours of usage at %I per kWh %F

Y

50

Subtotal

Y

60

State sales tax %R %T

Y

70

County use tax %R per kWh %T

Y

Step Boundaries Based On The Number Of Days Of Usage And The Region In Which The Customer Resides

The following table illustrates the rate components necessary to levy a simple rate that contains the following charges:

- Monthly service charge: $10.00.

- Charge $.0832 for the first "x" kWh. X is equal to the number of days in the billing period multiplied by a factor that varies depending on where the customer lives.

- Charge $.1112 for the remaining kWh.

- State Tax at the prevailing rate (this tax is a percentage of a dollar value).

- County Use Tax at the prevailing rate (this tax is an amount per kilowatt hour).

Seq #

RC Type

Value Type

Value

Bill Factor

Item

Type

UOM/TOU/SQI

Step Range

Cross Reference

Calc Only

Result Type

10

Flat Charge

Charge

10.00

N

20

Service Quantity

Unit Rate

BASEQTY

DAYS

Y

Unit Rate

30

Service Quantity

Unit Rate

0.0832

KWH

0 to 1 Multiply by RC: 20

N

40

Service Quantity

Unit Rate

0.1112

KWH

1 to 99999999 Multiply by RC: 20

N

50

Summary

30, 40

N

60

Apply To

Percent

STTAX

10, 30, 40

N

70

Apply To

Unit Rate

COUNTYTAX

30, 40

N

Contents

Dynamic Steps - SQ Rule On The Rate Schedule

Dynamic Steps - For Calculation Purposes Only Rate Component

Dynamic Steps - Bill Factors

Dynamic Steps - Dynamic Stepped SQ Rate Components

Dynamic Steps - Descriptions On Bill

Dynamic Steps - SQ Rule On The Rate Schedule

This rate's rate schedule must have an SQ rule that calculates the number of days in the rate's bill period. This SQ rule will add a new service quantity to the measured service quantities supplied to the rate by billing. This new service quantity would be labeled with an SQI of DAYS and would contain the number of days in the bill period. This service quantity is needed by rate component 20.

Dynamic Steps - For Calculation Purposes Only Rate Component

The strange thing about this rate is rate component 20. It is used "for calculation purposes only". Notice what it's calculating - the number of days (SQI = DAYS ) multiplied by some factor that differs based on the region (Bill factor = BASEQTY ).

Dynamic Steps - Bill Factors

Because the daily amount differs based on the region in which the customer resides, you'll need a bill factor - BASEQTY - with a characteristic that matches the region. This characteristic will be specified on the customer's premise. Then, at billing time, the system extracts the appropriate base quantity based on where the customer lives and multiplies it times the number of days in the customer's bill. The step boundaries are then multiplied by the resultant value (notice that they are set to 1).

Dynamic Steps - Dynamic Stepped SQ Rate Components

Notice that rate components 30 and 40's step boundaries are multiplied by the amount calculated by rate component 20 (i.e., amount based on the number of days of consumption).

Dynamic Steps - Descriptions On Bill

The following table illustrates how you might want to define the Description on Bill for these rate components.

Seq #

Description on Bill

Print on Bill

10

Monthly service charge of %R %D

Y

20

Calculate only rate component to determine Step multiplication factor

N

30

First %Q kWh at %I per kWh %F

Y

40

Remaining %Q kWh at %I per kWh %F

Y

50

Subtotal

Y

60

State sales tax %R %T

Y

70

County use tax %R per kWh %T

Y

Calculated Minimum Charges

The following table illustrates the rate components necessary to levy a simple rate that contains the following charges:

- First 300 kilowatt hours at $0.0382 per kWh.

- Remaining kilowatt hours at $0.0673 per kWh.

- Minimum charge of $0.15 per day.

- State Tax at the prevailing rate (this tax is a percentage of a dollar value).

- County Use Tax at the prevailing rate (this tax is an amount per kilowatt hour).

Seq #

RC Type

Value Type

Value

Bill Factor

Item

Type

UOM/TOU/SQI

Step Range

Cross Reference

Calc Only

Result Type

30

Service Quantity

Unit Rate

0.0382

KWH

0 to 300

N

40

Service Quantity

Unit Rate

0.0673

KWH

300 to infinity

N

50

Summary

30, 40

N

52

Service Quantity

Unit Rate

.15

DAYS

Y

Charge

54

Minimum

Charge

52

30, 40

N

60

Apply To

Percent

STTAX

30, 40, 54

N

70

Apply To

Unit Rate

COUNTYTAX

30, 40

N

Contents

Calculated Minimums - SQ Rule On The Rate Schedule

Calculated Minimums - For Calculation Purposes Only Rate Component

Calculated Minimums - Description On Bill

Calculated Minimums - SQ Rule On The Rate Schedule

This rate's rate schedule must have an SQ rule that calculates the number of days in the rate's bill period. This SQ rule will add a new service quantity to the measured service quantities supplied to the rate by billing. This new service quantity would be labeled with an SQI of DAYS and would contain the number of days in the bill period. This service quantity is needed by rate component 52.

Calculated Minimums - For Calculation Purposes Only Rate Component

The strange thing about this rate is rate component 52. It is used "for calculation purposes only". Notice what it's calculating - the number of days (SQI = DAYS ) multiplied by 1 (i.e., the number of days in the billing period).

Calculated Minimums - Description On Bill

The following table illustrates how you might want to define the Description on Bill for these rate components.

Seq #

Description on Bill

Print on Bill

30

First %Q kWh at %I per kWh %F

Y

40

Remaining %Q kWh at %I per kWh %F

Y

50

Subtotal

Y

52

Calculate only rate component to determine number of days

N

54

Minimum charge %S

Y

60

State sales tax %R %T

Y

70

County use tax %R per kWh %T

Y

Stepped Taxes

Warning:

This is a difficult example. You should take the time to understand it even if you don't have stepped taxes because it illustrates the power of the various rate algorithms.

The following table illustrates the rate components necessary to levy a simple rate that contains the following charges:

- $0.10 per kWh.

- Service charge of $6.00

- Taxes are stepped:

- 6.383% for the anything up to $10

- 9.89% for everything above $10
Note that the dollar amount should be prorated if the bill is prorated.

Seq #

Description

RC Type

Value Type

Value

UOM/TOU/SQI

Cross Reference

Calc Only

Result Type

10

Energy Charge

Service Quantity

Unit Rate

0.10

KWH

N

20

Customer Charge

Flat

Charge

6.00

N

30

Total Taxable Revenue

Summary

10, 20

Y

Charge

40

Taxable Rev for 1st tax tier

Maximum

Charge

10.00

30

Y

Charge

50

Taxable Rev for 1 st tax tier

Summary

30, 40

Y

Charge

60

Taxable Rev for 2 nd tax tier

Apply To

Percent

-100.00

50

Y

Charge

70

Taxable Rev for 2 nd tax tier

Summary

30, 60

Y

Charge

80

Tax for 1 st tier

Apply to

Percent

6.383

50

N

90

Tax for 2 nd tier

Apply to

Percent

9.89

70

N

Notice that sequences 30, 40, 50, 60 are calculation-only rate components that are used to calculate the amount of revenue applicable for each tax rate. We'll let you work the math.

How To Add A New Service Quantity Rule Algorithm

Warning:

This section is meant for technicians only!

If the SQ rule algorithms that are supplied with the base package are not sufficient for your rating requirements, you will have to write a new SQ 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 Service Quantity Rules.

Warning:

Do NOT attempt to set up a new service quantity algorithm until you have a very good understanding of what your meters measure and how your rates charge for this consumption. In addition, you should completely understand the concepts described in UOM versus TOU versus SQI before creating a new algorithm. In addition, you should completely understand the concepts described in When And How To Manipulate Measured Consumption before creating a new algorithm.

Follow the following steps to define a new service quantity (SQ) rule:

- Assign a two-digit identifier to the SQ rule. This identifier should begin with an X or Y . For example, you could give your first SQ rule the identifier X1 , the second X2 , etc.

- Create an algorithm type for your new SQ rule. This algorithm type exists to define the types of parameters supplied to your SQ rule. Refer to Base Package SQ Rules for examples. This algorithm type must be identified by the two-digit identifier allocated above.

While SQ rules require an algorithm type, they do NOT require an algorithm. Why? Because you set up an SQ 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. This program should be named CMPRQ 'nn' X - where 'nn' is the same two-digit identifier. When you create the new program, please copy an existing SQ rule program (their program names are all in the format CIPRQ__X). This way you will automatically inherit the copybooks necessary to support the routine.

Warning:

Do NOT alter any of the copybooks contained in the linkage section of the COBOL algorithm routine. If you do need extra information for your algorithm you should execute SQL to get the information. If you do alter a linkage section copybook the upgrade process will be greatly complicated. Note, however, that virtually all information available to the rate application is being passed to the rule algorithms - so it is likely the information you need will be at hand.

How To Add A New Register Rule Algorithm

Warning:

This section is meant for technicians only!

If the register rule algorithms that are supplied with the base package are not sufficient for your rating requirements, you will have to write a new register 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 Register Rules.

Warning:

Do NOT attempt to set up a new Register algorithm until you have a very good understanding of what your meters measure and how your rates charge for this consumption. In addition, you should completely understand the concepts described in UOM versus TOU versus SQI before creating a new algorithm. In addition, you should completely understand the concepts described in When And How To Manipulate Measured Consumption before creating a new algorithm.

Follow the following steps to define a new Register (register) rule:

- Assign a two-digit identifier to the register rule. This identifier should begin with an X or Y . For example, you could give your first register rule the identifier X1 , the second X2 , etc.

- Create an algorithm type for your new register rule. This algorithm type exists to define the types of parameters supplied to your register rule. Refer to Base Package Register Rules for examples. This algorithm type must be identified by the two-digit identifier allocated above.
While register rules require an algorithm type, they do NOT require an algorithm. Why? Because you set up a register 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 REG_RULE_ALG_FLG . This should have a Field Value equal to the two-digit identifier allocated above.

- Write your new program. This program should be named CMPRR 'nn' X - where 'nn' is the same two-digit identifier. When you create the new program, please copy an existing register rule program (their program names are all in the format CIPRR__X. This way you will automatically inherit the copybooks necessary to support the routine.

Warning:

Do NOT alter any of the copybooks contained in the linkage section of the COBOL algorithm routine. If you do need extra information for your algorithm you should execute SQL to get the information. If you do alter a linkage section copybook, the upgrade process will be greatly complicated. Note, however, that virtually all information available to the rate application is being passed to the rule algorithms - so it is likely the information you need will be at hand.

Quotes

A quote allows you to show a customer how their bill segments will look if a given set of pricing terms is applied to a given amount of consumption. If the customer accepts a quote, one or more real service agreements are created.

Fastpath:

Refer to Defining Quotation Options for how to setup the system to enable quotation functionality.

Note:

Separate module. Please note that the quoting functionality is part of the Contract Management module. If this module is not applicable to your business you may turn it off. Refer to Turn Off A Function Module for more information. .

The topics in this section describe the quotation functionality.

Contents

The Big Picture Of Quotations

Maintaining Quotes

The Big Picture Of Quotations

The topics in this section provide background information about a variety of quotation features and functions.

Warning:

If you are not familiar with the concepts described under Sales and Marketing, Billing, Rates and Interval Billing (assuming you have quotes generated using interval consumption) the quotation functionality will be difficult to understand.

Contents

Basic Quotation Concepts

Printing Quotes

Basic Quotation Concepts

The section describes basic quotation concepts.

Contents

A Quote Shows How Bill Segments Might Look

Proposal Service Agreements Must Exist

Creating Quotes And Quote Details

Completing A Quote Creates Quote Routings (And More)

Accepting / Declining Quote Details

Tinkering With Proposal SAs After Quote Generation

Closing Quotes

Alerts

Trees

A Quote Shows How Bill Segments Might Look

A quote shows how a customer's bill segments will look if a given set of pricing terms is applied to a given amount of consumption. The following example illustrates how a quote might look that provides a customer with two different options for their electric service. If the customer elects either option, a new service agreement would be created.

Please note the following about a quote:

- A quote is related to an account.

- A quote can contain many quote details. A quote detail shows how bill segments will look if a given set of pricing terms (e.g., rates, riders, contract quantities, time-of-use-maps, contract options, etc.) is applied to a given amount of consumption.

- A quote detail may contain many simulated bill segments. For example, a quote detail could show the customer what their monthly bills would be if a given set of pricing terms were used over the course of several months (where each month has different consumption levels and different prices).

- A quote may contain multiple quote details for the same service. For example, a quote can contain four different pricing options for the same service (where each option is shown using a separate quote detail). The customer can then compare them and choose the optimum option.

- A quote may contain quote details for multiple premises and multiple services at each premise. For example, a quote can contain quote details for electric and gas service at multiple premises.

Proposal Service Agreements Must Exist

You cannot create a quote unless its account has at least one proposal service agreement (SA). A proposal SA contains the pricing terms, legal terms, and template consumption used to generate the simulated bill segments that appear on a quote. It might be helpful to view a proposal SA as special type of service agreement that is ignored when a bill is produced for an account.

The topics in this section provide detailed information about proposal SAs.

Contents

Proposal SAs Contain Pricing Terms

Legal Terms and Conditions May Be Specified On Both Proposal And Real SAs

Proposal SAs Contain Billing Scenarios And Template Consumption

Proposal SAs Differ From Real SAs

Proposal SA State Transition

Orders Are Used To Create Proposal SAs

Proposal SAs May Be Grouped Under An Umbrella Agreement

Proposal SAs And Interval Consumption

Proposal SAs Contain Pricing Terms

The pricing terms (e.g., rates, contract quantities, riders, bill factor values, load curves, TOU maps, etc.) used to generate a quote detail's simulated bill segments reside on a special type of service agreement (SA) referred to as a "proposal SA". Proposal SAs are like real SAs in many respects. In fact, you can view and change a proposal SAs pricing terms using the same transaction used to maintain real service agreements (i.e., service agreement maintenance).

Note:

Quote details are rather empty. A quote detail doesn't contain the pricing terms or template consumption. Rather, a quote detail references a proposal SA and the proposal SA contains the pricing terms and template consumption.

Legal Terms and Conditions May Be Specified On Both Proposal And Real SAs

In addition to containing pricing terms, proposal SAs also contain the legal terms and conditions (T&Cs) that govern the proposal.

Your master list of terms and conditions are defined when you setup your control tables. The system defaults a service agreement's T&Cs from the start option used to initially create it. You can change a SA's T&Cs at will.

Note:

Real SAs and proposal SAs can reference T&Cs. It should be noted that both proposal and real SAs can reference T&Cs. The T&Cs on a proposal SA are those that will apply if the customer accepts the related quote detail. The T&Cs on a real SA are those that apply while the SA is active.

Proposal SAs Contain Billing Scenarios And Template Consumption

In addition to the pricing terms and the legal terms and conditions, a proposal SA also contains billing scenarios. A billing scenario defines:

- The number of simulated bill segments that will be generated when a quote detail is produced for the proposal SA.

- The bill period of each simulated bill segment.

- The amount of consumption to be priced under each simulated bill segment. Note this statement is only true for non-interval consumption. Refer to Proposal SAs And Interval Consumption for a description of how interval consumption is defined on a proposal SA.

A proposal SA's billing scenarios can be created as follows:

- A plug-in spot exists on SA type called Proposal SA Creation . Algorithms plugged into this spot can setup billing scenarios. Refer to Enabling The Automatic Generation Of Billing Scenarios for more information about how to do this.

- A user can add / change / delete billing scenarios on a proposal SA using Service Agreement - Billing Scenario.

- You could design a workflow process to initiate a request to the customer to send their template consumption to you. When the customer sends this information to you (via a notification), the proposal SA's billing scenarios can be setup. Refer to Workflow and Notifications for more information.

Proposal SAs Differ From Real SAs

A proposal SA is just like any other SA in that it contains the pricing terms that are used to generate how much the customer owes for service. In fact, the service agreement maintenance transaction is used to maintain both types of service agreements (however, you cannot use this transaction to create a proposal SA; proposal SAs can only be created using the order transaction).

However, there are differences between proposal SAs and real SAs:

- Billing ignores proposal SAs.

- Proposal SAs cannot have financial transactions.

- Proposal SAs are not subject to credit and collections.

- Proposal SAs do not appear on lists of "active" SAs in the system's various zones, grids and trees.

- Fieldwork is not performed for proposal SAs.

- A proposal SA's state transition is very different from a real SA. Refer to The Lifecycle Of A Service Agreement for an illustration of a real SAs state transition. Refer to Proposal SA State Transition for an illustration of a proposal SAs state transition.

Proposal SA State Transition

The following diagram shows the possible lifecycle of a proposal SA.

You should never see an Incomplete proposal SA as this is a transitory state used when a proposal is first initiated using the Order transaction. The system always transitions such proposal SAs to the Pending state. Please note that when a proposal SA becomes Pending , the system executes any Proposal SA Creation algorithms plugged in on the proposal SA's SA type. You might use such algorithms to generate billing scenarios or initiate a workflow process that requests template consumption from the prospect.

A proposal SA exists in the Pending state while you are working on the proposal. For example, you might want to leave the proposal SA in this state while you wait for the prospect to send you their historical consumption.

A proposal SA is Quotable when a quote detail can be generated for it (at least one billing scenario must be linked to the proposal SA before it can become Quotable ). Note, proposal SAs can be modified when they are Quotable .

Note:

Automatically transitioning a proposal SA to the Quotable state when it's first created. As described earlier, you can setup a proposal SA creation algorithm to automatically create billing scenarios when a proposal SA is created. The base package algorithm can also automatically transition the proposal SA to the Quotable state (thus making it ready for quotation). Refer to Enabling The Automatic Generation Of Billing Scenarios for more information.

A proposal SA becomes Accepted when a customer accepts one of its quote details.

A proposal SA becomes Declined when a customer declines one of its quote details (or its quote expires). A Declined proposal SA can be "reopened" (by making it Quotable ). You may need to do this if you want to change a proposal SA's terms in preparation of generating a new quote detail.

A proposal SA becomes Canceled when a quote detail is withdrawn (or its quote expires). You may need to do this if you want to change a proposal SA's terms in preparation of generating a new quote detail.

Incomplete , Pending and Quotable proposal SAs may be deleted.

Orders Are Used To Create Proposal SAs

Proposal SAs can only be created using the order transaction. This transaction allows a user to pose eligibility-oriented questions to a customer or prospect. The system determines which packages of goods and services for which they are eligible based on the answers to the questions. If the customer is interested in receiving a package, one or more SAs (real and/or proposal) are created using the SAs To Create information defined on the selected package.

Note:

You must setup campaigns and packages before you can create an order. If you are not familiar with the order transaction, you should take the time to form an intuitive understanding of the concepts described under Sales & Marketing. With this knowledge in place, you can design and set up the campaigns and packages necessary to allow an order to create proposal SAs. Keep in mind that a single switch controls whether real SAs or a proposal SAs are created when a package is selected on the order transaction. This switch resides on Package - SAs To Create.

A package could create a combination of real and proposal SAs. When a customer elects to take a package of goods and services (via the order transaction), the system creates a service agreement for each SA type / start options defined on the package's SAs To Create. It is possible to setup a package to create both real and proposal SAs. For example, the customer may be calling you to start electric service, but they may also be interested in seeing a proposal for gas service.

You don't create special SA types for proposal SAs. The SA type on a proposal SA is the same as the SA type on the real SA that's created when the proposal SA is accepted. This is because the business rules on your SA types govern both real and proposal SAs.

You don't need special start options for proposal SAs. The start options that you setup to default information onto new, real service agreements are also referenced on the SA To Create information used to create proposal SAs.

Proposal SAs May Be Grouped Under An Umbrella Agreement

Each proposal SA may be part of a larger contract for multiple services that you are negotiating with a customer or group of customers. You may use an umbrella agreement and its collection of terms of service records to group together multiple proposal service agreements.

Proposal SAs And Interval Consumption

Note:

Assumption. This section assumes you are very comfortable with the concepts described under Interval Billing.

Service agreements with interval data have rates that price the interval consumption using time-of-use prices and / or direct prices. Proposal SAs for interval service agreements require billing scenarios to define the time period of each simulated bill segment on the quote detail. However, these billing scenarios typically won't have template consumption (unless regular meters are used in addition to interval meters on the service agreement). Rather, interval billing proposal SAs require interval profiles and datasets, time-of-use maps, and contract options because their rates use this information to calculate the simulated bill segments.

The following points provide an overview of how interval information can be populated on proposal SAs:

- As described under Orders Are Used To Create Proposal SAs, a proposal SA is populated using the start option defined on the package specified when an order is completed (note, a package can cause multiple proposal SAs to be created where each proposal SA references a different start option).

- Start options can reference all types of interval information (interval profiles, time-of-use maps and contract options). If you're familiar with interval billing concepts, you know that the system treats "common" interval information differently from "SA-owned" information when a start option is used to create a service agreement:

- "Common" interval information referenced on a start option is simply copied to the newly created service agreement. This is exactly what you want. For example, when you create a proposal SA using a start option that references a "deemed profile" or a "standard time-of-use (TOU) map", you don't want a new deemed profile or TOU map created. Rather, you want the start option's deemed profile and time-of-use map to be referenced on the proposal SA.

- "SA Owned" interval information on a start option doesn't work this way. Rather, the system creates new interval information and references these on the newly created service agreement. For example, if a start option indicates the service agreement should have an SA-owned interval profile for actual consumption and another for derived consumption (e.g., excess demand), the system creates two interval profiles and links them to the new service agreement. For real SAs, this logic is perfect. For proposal SAs, this logic is perfect for interval profiles that are derived during billing. However, for interval profiles that contain actual consumption, this isn't what you want. This is because, for actual consumption on proposal SAs, you just need to reference an existing profile whose consumption can be used as the template consumption. The next point provides a few options.

Note:

Although the above describes issues related to SA owned interval profiles, similar issues may apply for SA owned TOU maps or to contract options that are specific to a specific service agreement. To successfully generate a quote for a customer, you may need to create template data for these entities as well.

- You can choose from the following methods to populate a proposal SA with "actual consumption":

- You could design a workflow process that asks the customer to send their template consumption to you. This could be done by creating a Proposal SA Creation plug-in on the proposal SA's SA type (note, as of the current release, this algorithm does not exist in the base package, but it would be very simple to write). When the customer sends this information to you (via a notification), the datasets on the interval profile that contain the proposal SA's simulated actual consumption can be setup. Refer to Workflow and Notifications for more information.

- You could ask the user (during the order taking process) to define the type of consumption profile (e.g., are they a doctor's office, bakery, laundry, etc). If you're familiar with campaigns and orders, you'll know that you can do this by setting up a question on the campaign. For example, you could design the campaign to pose a question like, "Please choose the consumption profile to be used when the quote is generated". Then, based on the user's answer, you could set up the proposal SA using profiles consistent with the selected type. The following would be required to setup this type of question:

- Create a "substitute" start option for each consumption profile. Each start option will contain the normal common and derived interval profiles that are used for a real interval SA. The interval profile on the start option that's used for actual consumption would also use a common profile. This common profile would contain the "template" actual consumption that will be used in place of the customer's actual consumption. This template consumption can be used on any interval profile created using this start option.

- Setup a campaign that asks a user to identify the consumption profile to be used to generate the quote as described above.

- Setup a package under the campaign for each consumption profile. Each package will have eligibility rules to indicate that it is only selectable if the respective consumption profile is chosen on the order.

- Each package will also reference the "substitute" start option that corresponds with its consumption profile.

- At this point, you have everything setup to create a proposal SA with a consumption profile that can be used to generate simulated bill segments (remember, the proposal SA's SA type needs a Proposal SA Creation algorithm that creates billing scenarios). If the customer accepts this proposal SA, you need to setup a real SA with the correct profiles (you don't want the consumption profile on the real SA, nor do you want any derived profiles that were created when the simulated bill segments were generated). The remaining points describe how to do this.

- You want these proposal SAs to contain a characteristic that defines the true start option that should be used to create the real SA. To do this, simply define a default char type / value on the "substitute" start option that contains the real start option (this default information is copied onto the proposal SA when it's created). Note. The SA type of the "real" start option should be the same as the proposal SA type.

- As described under Accepting / Declining Quote Details, you must plug-in a Proposal SA Accepted algorithm that has a parameter of the char type on the proposal SA that contains the start option to use when the real SA is created. It then does the work for you. Refer to PSAA-PS for more information about this algorithm.

- Other solutions are only limited by your imagination.

Creating Quotes And Quote Details

Once an account has quotable proposal SAs, you can generate a quote for the account using the quote maintenance transaction. When you generate a quote for an account, you can include quote details for any / all of the account's quotable proposal SAs.

The logic used to create a quote detail's simulated bill segments is not hard-coded. Rather, the system calls the algorithm plugged in on the proposal SA's SA type in the Proposal SA - Bill Segment Generation plug-in spot. Refer to Enabling The Generation Of Simulated Bill Segments for information about this plug-in spot.

The major difference between a bill segment linked to a quote detail and one linked to a bill is that a quote detail's bill segments are calculated using simulated consumption. This means that the financial information on quote details is not a guess - it's what the bill would be if a given amount of consumption was priced using the pricing terms (as long as you opt to use rate application to calculate the simulated bill segments).

In addition to this major difference, there are a few minor differences between a real bill segment and a simulated bill segment:

- A quote detail bill segment does not have a foreign key to a bill. Rather, it references a quote detail.

- A quote detail bill segment's prime key is inherited from its quote detail (rather than its bill).

- A quote detail bill segment can never have a financial transaction linked to it.

- A quote detail bill segment doesn't have read details (unless you perform TOU mapping of interval data).

- A quote detail bill segment's state transition is simpler (it's either in the Error state or OK ).

Completing A Quote Creates Quote Routings (And More)

When a quote's quote details are all OK , you change the status of the quote to complete to indicate the quote is ready to be sent to the customer or prospect.

When a quote is completed, the system creates a quote routing for each person who receives a copy of the account's quotes. When you indicate a person should receive a copy of the account's quotes, you define the routing method (e.g., email, fax, post) and the appropriate address.

Note:

Recipients of quotes. You define who receives a copy of an account's quotes on the Account - Persons page. The system assumes (by default) that the main person linked to the account should receive the account's quotes. You can subsequently indicate any person linked to the account should receive its quotes (and turn off the creation of quotes for the main person). In addition, you can manually add additional quote routings to a quote if you need to send the quote to individuals not currently linked to the account. Refer to How To Reprint A Quote for more information.

The information that appears on the quote routing record is controlled by the quote route type specified on the respective account / person information:

- If the quote route type indicates the person's quotes are routed via fax, the person's fax number is used as the routing information. The system knows which of a person's phone numbers is a fax number by the phone type.

- If the quote route type indicates the person's quotes are routed via email, the person's Email address is used as the routing information.

- If the quote route type indicates the person's quotes are routed via the postal service, the address constituents are populated with the address specified on the bill address sourcethat is also specified on the account / person information. 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.

Regardless of whether the quote is routed via fax, email or post; the routing record is also stamped with the batch process and run number that performs the download of the quote information. The batch process is defined on the quote route type. Refer to Printing Quotes for more information about this batch process.

In addition to creating routing information at completion time, the system executes any quote completion algorithms plugged in on the account's customer class. For example, you may want to create a workflow process to manage the processing of the quote. To do this, you plug in a Quote Completion Algorithm that creates a workflow process on the respective customer class .

Accepting / Declining Quote Details

A customer can accept or decline each quote detail on a quote.

When a quote detail is accepted, the system:

- Changes the state of the related proposal SA to accepted .

- Executes the Proposal SA - Acceptance algorithms plugged in on the proposal SA's SA type. The base package algorithm creates a real SA by copying the information from the proposal SA. The real SA is created in the pending start state. This new SA behaves similarly to a pending start SA that's created via the Order or Start/Stop transactions (e.g., field activities are initiated if the SA type has been setup accordingly).

When a quote detail is declined, the user must supply a decline reason. The system then changes the state of the related proposal SA to declined .

Fastpath:

Refer to Proposal SA State Transition for more information about a proposal SA's states.

Note:

Reopening a declined proposal SA. If a customer changes their mind about a declined proposal SA, you can return it to the quotable state using the service agreement maintenance transaction.

Rejecting an entire quote. If all details on a quote are being declined, you can simply change the state of the quote to closed rather than reject each quote detail. Refer to Closing Quotes for more information.

Tinkering With Proposal SAs After Quote Generation

The system allows a quotable proposal SA to be changed, EVEN IF QUOTE DETAILS HAVE BEEN GENERATED. This is intentional as otherwise you would have to create an entirely new proposal SA if you wanted to send another quote for slightly different terms. Your technical team could always introduce a user exit to prevent this from happening if you really didn't want this to take place.

Because the system allows this, a potential issue is that the customer may end up accepting a proposal SA that differs from the terms on his quote (e.g., you could change the SA after the quote detail is generated). For this reason, we snapshot the version number of the proposal SA on the quote detail at the time it's generated. If a proposal SA is accepted and its version number differs from the value on its quote details, a warning is produced.

A warning is also issued if you change a proposal SA and a quote detail exists (reminding you to generate a new quote / quote detail).

In addition to the above, it's also important to understand that the system intentionally allows multiple quotes to reference a given proposal SA. This allows you to leave multiple quotes open that reference the same proposal SA(s).

Closing Quotes

Every quote has an expiration date. The CLOSEQTE background process closes quotes on their expiration date. This process changes the state of all related proposal SAs to canceled or declined (an input parameter of this process controls which state is used).

You can also close a quote real time using the quote maintenance transaction. When you do this, the system asks if the related proposal SAs should be left as quotable or if they should be changed to canceled or declined .

Note:

Reopening a declined proposal SA. If a customer changes their mind about a declined proposal SA, you can return it to the quotable state using the service agreement maintenance transaction.

Alerts

The alert zone highlights if:

- The selected account has pending or complete quotes. Refer to Quote Lifecycle for more information.

- The selected account has pending or quotable proposal SAs. Refer to Proposal SA State Transition for more information.

Trees

The account tree highlights:

- The existence of non-closed quotes

- The existence of proposal SAs and their related quote details

Printing Quotes

The contents of this section describe the technical implementation of printing quotes.

Contents

Quote Routings Are Created For Each Recipient Of A Quote

Quote Route Types Control The Information Merged Onto Quotes

Technical Implementation Of Online Quote Image

Technical Implementation Of Printing Quotes In Batch

Reproducing The Quote Print Flat File

How To Reprint A Quote (For The Original Recipients or For Someone New)

The Documaker Records

Quote Routings Are Created For Each Recipient Of A Quote

Refer to Completing A Quote Creates Quote Routings for a description of how the system constructs the information used to route a quote to one or more recipients.

Quote Route Types Control The Information Merged Onto Quotes

Every quote routing references a quote route type . The route type controls the following quote functions:

- It contains an algorithm that is responsible for extracting the information merged onto your quotes. Specifically, algorithms of this type create the "flat file records" that are passed to your quote-print software. Algorithms of this type are called under the following scenarios:

- The background process that builds the flat file that's passed to your quote-print software calls these algorithms to construct the "flat file records" for each quote. Refer to Technical Implementation of Printing Quotes In Batch for the details.

- If your quote-print software has the ability to construct a real-time image of a quote (in a PDF), you can plug in an Online Quote Image algorithm on the Installation Record. This type of algorithm calls the quote's dispatch group extract algorithm to extract the information that is merged onto the quote. Refer to Technical Implementation Of Online Quote Image for the details.

- Refer to The Documaker Records for examples of the record layouts passed to the Documaker print software.

- It contains the ID of the background process that builds the flat file that's passed to your quote-print software. The base package example of this process (known by the batch control ID of QUOTROUT) simply calls the extract algorithm on the routing record's route type to format the information placed onto the flat file.

Technical Implementation Of Online Quote Image

Users can view an image of any quote if you set up the following:

- Plug in an Online Quote Image construction algorithm on the Installation Record. Refer to ONQD-DOC1 for an example of such an algorithm. Note if your quote-print software is not capable of producing a PDF containing an image of a quote, users will not be able to view images of quotes.

- Plug in the appropriate extract algorithm on each quote route type . Algorithms of this type format the records that contain the information that is passed to your printing software. Refer to QTEX-EX for an example of such an algorithm.

When you plug in these algorithms, a button appears on Quote - Main. When a user clicks this button, the following takes place:

- The installation record's Online Quote Image construction algorithm is executed.

- This algorithm calls the quote's route type's extract algorithm. This algorithm constructs the information that's merged onto the quote and returns it to the Online Quote Image algorithm. This algorithm, in turn, passes it to the quote-print software.

- The quote-print software renders an image of the quote in a PDF and returns it to the Online Quote Image algorithm.

- And finally, the Online Quote Image algorithm displays the PDF in a browser session. Note that the client must have Adobe Acrobat Reader installed to view PDF files.

Technical Implementation Of Printing Quotes In Batch

The batch process that extracts quote information reads all quote routing records in a given run number that are marked with its batch control ID. For each quote routing record, it creates numerous records on a flat file. These records contain the information that is merged onto your quotes.

The base package example of this process (known by the batch control ID of QUOTROUT) simply calls the extract algorithm on the routing record's route type to format the information placed onto the flat file. Refer to Quote Route Types Control The Information On Quotes for more information.

Note:

If your software doesn't support online quote images. The algorithm that formats quote extract records that's plugged in on quote route type serves two purposes: 1) it formats the records used to construct online images of a quote, and 2) it formats the records downloaded to your quote print software in batch. If your quote printing software does not support the rendering of quote images real time, there is no need to create an extract algorithm. Rather, you should simply develop your own download process that both formats the extract records and downloads them (and then specify this batch process on your quote route type).

Reproducing The Quote Print Flat File

You can reproduce the flat file at any time. Simply request the quote production background process and specify the run number associated with the historic run.

How To Reprint A Quote (For The Original Recipients or For Someone New)

A copy of a quote is sent to every individual / business specified in the quote's routing details. The system creates the routing details when a quote is completed. Refer to Completing A Quote Creates Quote Routings for more information about how this information is compiled during quote completion.

If you want to reprint a quote OR if you want to send a quote to someone other than the original recipients:

- Navigate to the Quote - Main page.

- Transfer to the Quote - Quote Routings tab.

- Insert a new row (click the + button). Note that you can only insert information on a quote that is Complete .

- Specify the name and address to which the quote should be sent. If you want to send the quote to someone other than the original recipient, specify the individual's name and address.

- Save the quote.

If a quote is Complete but the print process hasn't yet executed, you may change the name and address on the original routing details; you don't have to insert a new routing row.

The Documaker Records

Numerous different types of records are interfaced to the Documaker quote print software. However, they all share a common structure:

- The first 4 bytes are called the Printer Key. This field is a record type used by the Documaker quote template.

- The next X bytes are called the Sort Key. This field is used to ensure the various records used to construct a printed quote appear in the correct order in the interface file.

- The next 12 bytes are called the Mailing Key. This field is used to control the order in which the formatted quotes are printed.

- The remaining bytes contain the Quote Information that appears on the printed quote. The type of information differs for each type of record.

The topics in this section describe each component.

Contents

Printer Key (Record Types)

Sort Key

Mailing Key

Quote Information

Printer Key (Record Types)

The following table defines each printer key (i.e., record type) on the quote print flat file.

Record Type

Description

Notes

0010

Global extract information

Required. 1 per flat file

0100

Quote record

Required. 1 per Quote.

0200

Quote Detail record

1 per quote detail.

0300

Terms and Conditions record

1 per terms and conditions linked to the proposal SA.

0400

Bill segment record

1 per bill segment linked to the quote detail.

0500

Bill calculation header

1 per bill calculation header linked to the bill segment.

0600

Bill calculation line

1 per bill calculation line linked to the bill calculation header.

0700

End of record type 0500

1 for each bill calculation header

0800

Read detail

1 for each meter read detail linked to the bill segment.

0900

SQ detail

1 for each service quantity detail linked to the bill segment.

1000

End of record type 0400

1 for each bill segment.

1100

End of record type 0200

1 for each quote detail.

9999

End of record type 0100

1 for each quote.

Sort Key

The following table defines the structure of the sort key that appears on each quote print record. Please note that different components are filled in for each printer key.

Field Name

Format

Source/Value/Description

Quote ID

A12

Sequence Number

N2

The sequence number of the account / person information associated with this quote routing information.

Quote record group

A2

10 Quote

20 Quote Detail

30 Quote end

Quote Detail ID

A12

Quote Detail record group

A2

10 Quote Detail record

20 SA Terms and Conditions

30 Bill Segment

40 Quote Detail record end

SA T&C Short Description

A60

Bill Segment End Date

A10

Bill Segment Id

A12

Bill Segment Group

A2

10 Bill segment

20 Bill segment calculation group

30 Bill segment read detail

40 Bill segment SQ detail

50 Bill segment end

Bill Calc Header Sequence

N2

Bill Calc Header Group

A2

10 Bill calculation header

20 Bill calculation line

30 Bill calculation end

Line Seq

N4

Defines order of rows for similar record types

Mailing Key

The following table defines the structure of the mailing key that appears on each quote print record.

Field Name

Format

Source/Value/Description

Postal code

A12

This is the postal code on the quote routing record.

Quote Information

The topics in this section describe the information that appears on each on each bill print record.

Contents

Global Extract Information (0010) Record Definition

Quote (0100) Record Definition

Quote Detail (0200) Record Definition

SA Terms and Conditions (0300) Record Definition

Bill Segment (0400) Record Definition

Bill Calculation Header (0500) Record Definition

Bill Calculation Line (0600) Record Definition

End of Bill Calculation Header (0700) Record Definition

Bill Segment Read (0800) Record Definition

Bill Segment SQ (0900) Record Definition

End of Bill Segment (1000) Record Definition

End of Quote Detail (1100) Record Definition

End of Quote (9999) Record Definition

Address Sub-record Definition

G lobal Extract Information (0010) Record Definition

This is a "header" record that contains information about the extract run as a whole.

Note:

Please be aware that if you do not sort your extract file by CIS Sort Key after it is produced, this record will physically be the last record on the extract file.

Field Name

Format

Source/Value/Description

BATCH_CD

A8

Batch Control Code of the extract process.

BATCH_NBR

N10

Batch Number of the extract process

BATCH_RERUN_NBR

N10

Batch Rerun number of the extract process.

QTE_CNT

N10

Count of quotes on this extract.

EXTRACT_DTTM

A26

System time of extraction.

QUOTE_ID_START

A12

This is only used when a quote is produced as a result of an online request (from Quote - Main). It contains the Quote Id to extract.

QUOTE_ID_END

A12

This is only used when a quote is produced as a result of an online request (from Quote - Main). It contains the Quote Id to extract.

THREAD_NBR

N10

This field is only used if quotes are extracted in batch. It contains the thread number in which the quote was extracted.

THREAD_CNT

N10

This field is only used if quotes are extracted in batch. It contains the total number of threads that were extracted.

Q uote (0100) Record Definition

Field Name

Format

Source/Value/Description

QUOTE_ID

A12

CI_QUOTE

ACCT_ID

A10

CI_QUOTE

EXPIRE_DTTM

A26

CI_QUOTE

QUOTE_STAT_FLG

A2

CI_QUOTE

CURRENCY_CD

A3

CI_ACCT

CUR_SYMBOL

A4

CI_CURRENCY_CD

ENTITY_NAME1

A64

CI_QUOTE_RTG. Mailing Entity Name1.

ENTITY_NAME2

A64

CI_QUOTE_RTG. Mailing Entity Name2.

ENTITY_NAME3

A64

CI_QUOTE_RTG. Mailing Entity Name3.

ADDRESS_SBR

A361

CI_QUOTE_RTG. Refer to its components in a later section.

EMAILID

A70

CI_QUOTE_RTG

PHONE-FAX

A64

CI_QUOTE_RTG

Q uote Detail (0200) Record Definition

Field Name

Format

Source/Value/Description

QUOTE_DTL_ID

A12

CI_QUOTE_DTL

SA_ID

A10

CI_QUOTE_DTL

TOTAL_AMT

N13.2

CI_BSEG_CALC. Sum of all calculation amounts (quote detail's bill segments).

PREMISE_ID

A10

CI_SA (Characteristic Premise)

ADDRESS_SBR

A361

CI_PREM. Refer to its components in a later section.

SA_TYPE_DESCR

A60

CI_SA_TYPE_L

SVC_TYPE_CD

A2

CI_SVC_TYPE_L

SA_VERSION

N5

CI_QUOTE_DTL

QTE_DTL_SA_VERSION

N5

CI_QUOTE_DTL

RS_DESCR

A60

CI_RS_L. Description of Rate effective on SA start date.

S A Terms and Conditions (0300) Record Definition

Field Name

Format

Source/Value/Description

START_DT

A10

CI_SA_TC

END_DT

A10

CI_SA_TC

TC_TYPE_CD

A12

CI_TC

DESCR

A60

CI_TC_L

TC_TYPE_TXT

A2000

CI_TC_L

B ill Segment (0400) Record Definition

Field Name

Format

Source/Value/Description

START_DT

A10

CI_BSEG

END_DT

A10

CI_BSEG

BSEG_STAT_FLG

A2

CI_BSEG

BSEG_AMT

S13.2

CI_BSEG_CALC_LN

B ill Calculation Header (0500) Record Definition

Field Name

Format

Source/Value/Description

START_DT

A10

CI_BSEG_CALC

END_DT

A10

CI_BSEG_CALC

RS_CD

A8

CI_BSEG_CALC

CALC_AMT

S13.2

CI_BSEG_CALC

DESCR_ON_BILL

A80

CI_BSEG_CALC

B ill Calculation Line (0600) Record Definition

Field Name

Format

Source/Value/Description

APP_IN_SUMM_SW

A1

CI_BSEG_CALC_LN

CALC_AMT

S13.2

CI_BSEG_CALC_LN

EXEMPT_AMT

S13.2

CI_BSEG_CALC_LN

UOM_CD

A4

CI_BSEG_CALC_LN

TOU_CD

A8

CI_BSEG_CALC_LN

SQI_CD

A8

CI_BSEG_CALC_LN

BILL_SQ

S12.6

CI_BSEG_CALC_LN

DESCR_ON_BILL

A80

CI_BSEG_CALC_LN

E nd of Bill Calculation Header (0700) Record Definition

Field Name

Format

Source/Value/Description

Dummy field

B ill Segment Read (0800) Record Definition

Field Name

Format

Source/Value/Description

SP_ID

A10

CI_BSEG_READ

BADGE_NBR

A16

CI_MTR

UOM_CD

A4

CI_BSEG_READ

TOU_CD

A8

CI_BSEG_READ

SQI_CD

A8

CI_BSEG_READ

RDG_DEC_POS

N1

CI_REG. Decimal positions of the reads.

START_REG_READING

S9.6

CI_BSEG_READ

START_READ_DTTM

A26

CI_BSEG_READ

START_ESTIMATE_SW

A1

CI_REG_READ

END_REG_READING

S9.6

CI_BSEG_READ

END_READ_DTTM

A26

CI_BSEG_READ

END_ESTIMATE_SW

A1

CI_REG_READ

MSR_QTY

S12.6

CI_BSEG_READ

USAGE_FLG

A2

CI_BSEG_READ

USE_PCT

N3

CI_BSEG_READ

HOW_TO_USE_FLG

A2

CI_BSEG_READ

CONSUM_SUB_FLG

A2

CI_REG

MSR_PEAK_QTY_SW

A1

CI_BSEG_READ

REGISTER_CONST

S6.6

CI_BSEG_READ

QTY_DEC_POS

N1

CI_UOM. Decimal positions of the final quantity.

FINAL_UOM

A4

CI_BSEG_READ

FINAL_TOU

A8

CI_BSEG_READ

FINAL_SQI

A8

CI_BSEG_READ

FINAL_REG_QTY

S12.6

CI_BSEG_READ

B ill Segment SQ (0900) Record Definition

Field Name

Format

Source/Value/Description

UOM_CD

A4

CI_BSEG_SQ

TOU_CD

A8

CI_BSEG_SQ

SQI_CD

A8

CI_BSEG_SQ

SQ_DEC_POS

N1

CI_BSEG_SQ

BILL_SQ

S12.6

CI_BSEG_SQ

E nd of Bill Segment (1000) Record Definition

Field Name

Format

Source/Value/Description

Dummy field

E nd of Quote Detail (1100) Record Definition

Field Name

Format

Source/Value/Description

Dummy field

E nd of Quote (9999) Record Definition

Field Name

Format

Source/Value/Description

Dummy field

A ddress Sub-record Definition

The address that appears in both the quote record (0100) and the quote detail record (0200) is composed of the following:

Field Name

Format

Description

COUNTRY

A3

ADDRESS1

A64

Refer to Completing A Quote Creates Quote Routings for a description of conditions when this field will contain a fax number or an Email address rather than the first line of a postal address (this only occurs for a bill record (0100)).

ADDRESS2

A64

ADDRESS3

A64

ADDRESS4

A64

CITY

A30

NUM1

A6

NUM2

A4

HOUSE_TYPE

A2

COUNTY

A30

STATE

A6

POSTAL

A12

GEO_CODE

A11

IN_CITY_LIMIT

A1

Maintaining Quotes

A quote allows you to show a customer how their bill segments will look if a given set of pricing terms is applied to a given amount of consumption. If the customer accepts the quote, real service agreements are created.

Fastpath:

Refer to The Big Picture Of Quotations for background information about quotes.

The topics in this section describe how to maintain quotes.

Contents

The Lifecycle Of A Quote And Quote Detail

Quote - Main

Quote - Quote Details

Quote - Quote Routings

The Lifecycle Of A Quote And Quote Detail

The topics in this section describe the lifecycle of the various quote objects.

Contents

Quote Lifecycle

Quote Detail Lifecycle

Quote Lifecycle

The following diagram shows the possible lifecycle of a quote.

Pending A quote starts its life in the Pending state. Refer to Creating Quotes And Quote Details for more information.

A quote remains Pending until you Cancel or Complete it.

You may delete a Pending quote. Deleting a pending quote also deletes its quote details.

Canceled You cancel a quote if you want a record of a Pending quote that was never sent to a customer.

Complete A quote becomes Complete when it is ready to be sent to a customer. No changes may be made to a Complete quote. Refer to Completing A Quote for a description of what happens when a quote is completed.

A Complete quote may be reopened. You would only do this if you need to prevent blatant errors from being sent to the customer. For example, if you notice an incorrect quote detail, you could reopen the quote, regenerate or delete the erroneous quote details, and then recomplete the quote.

Closed A Complete quote becomes Closed when its terms are no longer valid. Refer to Closing Quotes for more information.

Quote Detail Lifecycle

The following diagram shows the possible lifecycle of a quote detail.

When a quote detail is generated, it is placed in the Error or Ok state depending on whether the system successfully generated simulated bill segments for each billing scenario linked to the related proposal SA. A quote detail may be deleted if its parent quote is Pending . Refer to Creating Quotes And Quote Details for more information.

Quote - Main

This page is used to maintain quotes. This page provides many diverse functions:

- You can generate, complete, close, reopen, and cancel a quote.

- You can regenerate and delete quote details.

- You can accept, decline and cancel the proposal SAs that contribute a quote detail to the quote.

You should not attempt to use this transaction until you are comfortable with the concepts described under The Big Picture of Quotations.

Open this page using Sales & Marketing, Quotes.

Description of Page

Quote Info contains a concatenation of important information about the quote (e.g., its expiration date and status). Quote ID is the system-assigned unique identifier of the quote. These values only appear after the quote is added to the database.

Account ID identifies the customer or prospect associated with the quote. The name of the account's main customer appears adjacent.

Quote Status contains the state of the quote. Refer to Quote Lifecycle for information about the valid values and the state transition rules.

If your system has been configured to display an online image of a quote, a Display Quote button appears adjacent to the quote's status. When clicked, an online image of the quote is displayed. Refer to Technical Implementation Of Online Quote Production for how to enable this feature.

Expiration Date / Time identifies when the quote's terms are no longer valid. Refer to Closing Quotes for how the system uses this information to automatically close a quote.

Refer to Quote Actions for a description of each Quote Action button.

This transaction has sophisticated logic that can be used to perform mass updates to the quote's quote details and their related proposal SAs. These mass update actions are executed by selecting quoted details (in the grid) and then clicking the desired action button at the bottom the page. The remainder of this section describes how to use this mass update functionality.

The Select All / Clear All buttons are used to select / unselect the quote details. These buttons are disabled when the quote is Closed .

Note:

100 quote details at a time. Clicking Select All selects the first 100 quote details in the grid. If more than 100 quote details exist, you must select them in batches.

The grid that follows contains the quote details linked to the quote. The following information appears in the grid:

- Select box. Before you can perform any of the mass update actions at the bottom of the page, at least one quote detail must be selected. This field is disabled when the quote is Closed . You can use the Select All and Clear All buttons to change the value of the switch for all quote details in the grid.

- Click the go to button to transfer to the Quote - Quote Detail tab with the corresponding quote detail positioned in the scroll. On this page, you can see the details of the quote detail's simulated bill segments (and, from there, drill down into the details of each bill segment).

- The Quote Detail Info column contains a concatenation of a quote detail's division, SA type, start option, status, start date, and premise information (this information comes from the quote detail's proposal SA).

- The Total Amount column contains the sum of the quote detail's simulated bill segments.

- The Remarks column highlights special circumstances associated with the quote detail.

- Proposal SA has been changed since the quote was created appears if the proposal SA was modified after the quote detail was generated. If you'd like to recalculate this quote detail, select this row and click the Regenerate button at the bottom of the page to regenerate the quote detail's simulated bill segments.

- Quote detail contains bill segments in error appears if any of the simulated bill segments linked to the quote detail are in error . Click the adjacent go to button to transfer to the Quote - Quote Detail tab where the state of each simulated bill segment is shown. You can correct simulated bill segments that are in error by Regenerating the quote detail (and you do this by selecting the quote detail and clicking the Regenerate button at the bottom of the page).

The Quote Detail Actions and Proposal SA Actions can be used to perform mass updates to the selected quote details in the grid. Refer to Quote Detail Actions and Proposal SA Actions for the details.

Action Buttons On Quote Main

The topics in this section describe the various action buttons on the Quote - Main page.

Contents

Quote Actions

Quote Detail Actions

Proposal SA Actions

Quote Actions

The topics in this section describe the various Quote Action buttons on the Quote - Main page.

Contents

Generate

Complete

Close

Reopen

Cancel (Quote)

G enerate

The Generate button causes one or more quote details to be created for the account's Quotable proposal SAs. This button is enabled when there is at least one Quotable proposal SA linked to the selected Account ID.

When clicked, the Generate Quote window opens.

You must specify the following parameters to generate quote details:

- Indicate if quote details should be created for All Proposal SA's or for a Specific Proposal SA .

- If you indicated a quote detail should be generated for a Specific Proposal SA, also specify the Proposal SA ID.

After specifying the parameters, click Generate to create the quote details for quotable proposal SAs.

Fastpath:

Refer to Creating Quotes And Quote Details for more information.

Warning:

If the quote has existing quote details for the designated proposal SAs, they are deleted when you generate quote details (i.e., the system regenerates existing quote details). You can also regenerate quote details by selecting them on the Main page and clicking the Regenerate button.

C omplete

The Complete button causes the quote to become complete . This button is enabled when the quote is pending and all quote details linked to the quote are OK .

Fastpath:

Refer to Completing A Quote Creates Quote Routings for a description of what happens during quote completion.

C lose

A quote is closed when its terms are no longer valid (i.e., when the related proposal SAs can no longer be accepted). Most quotes are closed automatically by the system (refer to Closing Quotes for how this takes place).

If you want to close a quote real time, click the Close button. When this button is clicked, the system opens the Close Quote window and asks if anything should be done with the related proposal SAs.

In the resulting window, you must specify one of the following Proposal SA Actions:

- Choose No Action if you don't want to change the status of the related proposal SAs.

- Choose Decline if you want the status of the proposal SAs that have contributed quote details to the quote to be changed to declined . You must also define a Decline Reason.

- Choose Cancel if you want the status of the proposal SAs that have contributed quote details to the quote to be changed to canceled .

R eopen

The Reopen button causes a quote to return to the pending state. You would only reopen a quote if you need to prevent blatant errors from being sent to the customer. For example, if you notice an incorrect quote detail, you could reopen the quote, regenerate or delete the erroneous quote detail, and then recomplete the quote.

This button is enabled if the quote is complete .

C ancel (Quote)

The Cancel button causes the quote to become canceled. You would cancel a quote if you want a record of a pending quote that was never sent to a customer. This button is enabled when the quote is pending .

Canceling the quote does NOT cancel the related proposal SAs. If you want to cancel the related proposal SAs, you have the following options:

- You can click the Close button rather than the Cancel button. When you close a quote, you are given the option of also canceling the proposal SAs that contributed a quote detail to the quote.

- Before canceling the quote, you can select the quote details and click the Cancel button at the bottom of the page (in the Proposal SA Actions section). When you click this button, the system cancels the proposal SAs linked to the quote details.

- You can transfer to the Quote - Quote Details tab and then drill down to the each proposal SA (using the SA context menu button). This transfers you to Service Agreement - Main where you can cancel the proposal SA.

Quote Detail Actions

The topics in this section describe the various Quote Detail Action buttons on the Quote - Main page. These buttons are used to perform a given action to the quote details that are selected in the quote details grid.

Contents

Regenerate

Delete

R egenerate

The Regenerate button is used to delete and recreate the selected quote details. This button is enabled if the quote is pending and at least one row in the quote details grid is selected.

D elete

The Delete button is used to delete the selected quote details. This button is enabled if the quote is pending and at least one row in the quote details grid is selected.

Proposal SA Actions

The topics in this section describe the various Proposal SA Action buttons on the Quote - Main page. These buttons are used to perform a given action to the proposal SAs associated with the selected quote details.

Contents

Accept

Decline

Cancel

A ccept

The Accept button is used to accept the proposal SA associated with the quote detail. This button is enabled if the quote is pending or complete and at least one row in the quote details grid is selected.

When you accept a proposal SA, you are asked to supply the Start Date of the real service agreement that will be created.

Refer to Accepting / Declining Quote Details for more information about how accepting a quote detail causes a real service agreement to be created.

D ecline

The Decline button is used to decline the proposal SA associated with the quote detail. This button is enabled if the quote is pending or complete and at least one row in the quote details grid is selected. When you decline a proposal SA, you are asked to supply a Decline Reason.

Refer to Accepting / Declining Quote Details for more information about declining a quote detail.

C ancel

The Cancel button is used to cancel the proposal SA associated with the quote detail. This button is enabled if the quote is pending or complete and at least one row in the quote details grid is selected.

Quote - Quote Details

This page is used to view a summary of the simulated bill segments linked to a quote detail.

Open this page using Sales & Marketing, Quote and navigate to the Quote Details tab to define this information. You can also display a quote detail by clicking the respective go to button in the quote details grid on the main tab.

Description of Page

Quote Info contains a concatenation of important information about the quote (e.g., its expiration date and status). Quote ID is the system-assigned unique identifier of the quote. These values only appear after the quote is added to the database.

The Quote Details scroll contains one entry for every quote detail linked to the quote (a summary of these quote details also appears on the Main tab). The remainder of this section describes the information displayed for each quote detail.

Note:

You don't have to use the scroll. If the quote has many quote details, you don't have to use the scroll to work through them. Rather, you can use the go to button in the quote details grid on the main tab to position the respective quote detail in the following scroll. Also note, you can use Alt - and Alt + to scroll to the next and previous quote details in the scroll.

You cannot maintain quote details on this page. All maintenance functions (generate, delete, accept, decline and cancel) are performed on the Main tab.

Premise Info is the address of the main premise associated with the service agreement (as defined on the service agreement's characteristic premise). It's important to note that the service agreement may cover service at multiple premises, but only one may be defined as the main premise.

Quote Detail ID is the system-assigned unique identifier of the quote detail.

SA Info is a concatenation of the proposal SA's division, SA type, start option (if any), status and start date.

SA Version is a snapshot of the proposal SA's version number at the time the quote detail was generated. This information is used by the system to detect if the proposal SA was modified after the quote detail was created.

Total Amount is the sum of the quote detail's simulated bill segments.

Create Date / Time is the date and time the quote detail was generated.

Remarks highlight special circumstances associated with the quote detail. Please see the description of this field on the main tab for more information.

The grid contains a row for each simulated bill segment linked to the quote detail. The following information appears in the grid:

- The first go to button transfers you to the bill segment page where the details of the simulated bill segment are shown.

- Bill Segment Period defines the start and end dates of the simulated bill segment.

- Amount contains the amount of the bill segment.

- Remarks highlight special circumstances associated with the bill segment.

- Billing Scenario ID allows you to go to the proposal SA's billing scenario where you can tinker with consumption and the bill segment period used to generate this bill segment. Refer to Proposal SAs Contain Billing Scenarios for more information.

Quote - Quote Routings

This page is used to view the recipients of a quote. Refer to Printing Quotes for a discussion of how this information is used to produce quote images.

This page is also used to request a new copy of a quote.

Note:

No routing information until completion. A quote has no routing information until it is complete . At completion time, the system creates a routing detail for every person linked to the account that receives a copy of its quotes. Refer to Printing Quotes for more information about how this information is constructed.

Use Sales & Marketing, Quote, Quote Routings to open this page.

Description of Page

Quote Info contains a concatenation of important information about the quote (e.g., its expiration date and status). Quote ID is the system-assigned unique identifier of the quote. These values only appear after the quote is added to the database.

The Quote Routing Information scroll contains an entry for each recipient of the quote. This information is disabled after the quote has been routed to the recipient. The remainder of this discussion describes the fields that can be defined for each recipient of the quote.

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 Quote Routing Parameters area contains information explaining how and when the quote is routed to the recipient. This information is gray when the quote routing information has been extracted or if a quote is reopened:

- Quote Route Type is the method used to transmit the quote to the customer. This information defaults from Account - Person Information.

- Batch Control is the identifier of the batch of quotes in which the recipient's copy was downloaded. Embedded in this identifier is the batch control ID and the batch number. Note, this batch process is defined on the Quote Route Type.

- Sequence is the system-assigned identifier assigned to this quote routing.

- Turn on Do Not Extract if the quote should not be routed to the individual for whatever reason.

- Reprint is checked if an operator created this routing. This switch is populated by the system and is always protected.

- Extract Date/Time is the date and time the quote was downloaded. This information only appears after the download has commenced.

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. The information that's displayed is dependent on the Quote Route Type .

- If the recipient's Quote Route Type indicates a postal routing method is used, the address constituents are populated with the address specified on the billaddress sourcethat is also specified on the account / person information. Note that 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 the recipient's Quote Route Type indicates quotes are routed via fax, the recipient's Fax ID appears. The system knows which of a person's phone numbers is a fax number by the phone type.

- If the recipient's Quote Route Type indicates quotes are routed via email, the recipient's Email Address appears.

- Please note the following in respect of the Mailing Address Information:

- 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 quote's account, the Quote Route Type defined for this person on the account is defaulted.

- If a user specifies a Person ID that is not linked to the quote's account, the Quote Route Type on the installation record is defaulted. Note, if the quote route indicates the quote 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 Quote Route Type after the initial default, the system populates the address information as described above.

Service Credits

"Service credits" is a term used to describe a special program designed to reward a customer for service along with benefits related to such a program. For each program that a customer participates in, there is a service credit membership record. Service credit events are used to record the "points" earned and redeemed for the membership. The topics in this section provide further details related to the service credit functionality.

Fastpath:

For information about designing and setting up your control tables for configuring service credit functionality, refer to Designing Your Service Credit Options.

Note:

Service credits are optional. Service credits may not be set up in your system; they are only used if your company offers rewards programs to customers.

Penalty Points. The service credits functionality is described in the documentation with the assumption that it is used for accumulating points to reward your customers. However, if your company has a business need to record penalty points for a customer, the service credits functionality may be used for that purpose as well.

Contents

The Big Picture Of Service Credit Membership

The Big Picture of SC Events

Maintaining Service Credit Memberships and Their Events

The Big Picture Of Service Credit Membership

If a customer is participating in a rewards program, the customer has a service credit membership. The topics in this section provide background information about a variety of service credit membership features and functions.

Contents

Who are the Members?

Membership Application

Creation of a Membership

Membership Fees

Stopping a Membership vs. Inactivating a Membership

Who are the Members?

Each membership has one or more "members". The members are defined by the accounts linked to the membership and by the financially responsible person(s) linked to each account.

A typical membership is linked to only one account. However, in some cases more than one account is linked to the membership. For example, a customer may have one account for residential service and one for commercial service, but both accounts are part of the same membership. In this example, one person with multiple accounts is linked to the membership, so there is only one member.

For each account linked to the membership, the service related to the account may be used to calculate the accumulated credits for the membership. Refer to How Are Service Credits Earned? for more information.

Note:

An account may not be linked to more than one membership of the SAME membership type at a given point in time. In other words, an account may not have two United Airlines frequent flier memberships (otherwise, the account would accumulate double miles). However, an account may be linked to more than one membership if they are of different membership types. For example, an account may have a capital credits membership and a United Airlines frequent flier membership.

When you find a customer's record on Control Central - Main, you are transferred to the Account Information portal. One of the zones on this page contains information about memberships for the customer.

Note:

Portal Preferences. The service credit membership zone only appears if you have modified your preferences to display this zone. Refer to Portal Preferences for more information.

Contents

Joint Membership

Changing the Membership Accounts

Joint Membership

It is possible for more than one person to belong to the same membership. These persons may be linked to the same account or to different accounts. A typical scenario would be a married couple that shares in a membership. This is considered a "joint" membership.

The number of "members" for a membership is mainly for information purposes and typically has no bearing on the service credit amounts calculated for the membership. There may be legal restrictions or business practice restrictions controlling how you may set up your members. For example:

- In an airline's frequent flier program, a separate frequent flier account would exist for each customer. It is possible for you to create a frequent flier membership with more than one "member", but for the system, the important information is the external frequent flier miles number linked to the membership. The customer linked to this number accumulates the miles. For this case, your business practice may be that the person with the frequent flier account must be the only financially responsible person.

- For a capital credits membership, you may be required to distinguish between "single" memberships and "joint" memberships. If a single person gets married and would like the spouse to be added as a member, your practice may be to expire the single membership and to create a new "joint" membership to include both spouses.

Note:

Co-op Members. Do not confuse the "members" of a co-op with the members linked to a service credit membership. At a cooperative, most customers are considered "members" of the co-op. However, in the system, separate membership records are created for each single or joint membership.

Changing the Membership Accounts

The link between the accounts and the membership is NOT effective dated. This means that if the list of accounts for a membership changes, you need to stop the membership and start a new one with the new list of accounts.

Note:

Stopping Memberships. Stopping a membership does not necessarily prevent new service credits from accumulating. Refer to Stopping a Membership vs. Inactivating a Membership for more information.

Membership Application

Your business practice may dictate that the customer complete an enrollment form. Depending on your practice, the form may need to be received prior to starting membership or it may simply be a mechanism to gather supplemental information once the membership has begun.

Either way, you may consider setting up the system to handle forms as follows:

- Design your membership type to include a creation algorithm that generates a letter when the membership is created. The letter template could include the form to be filled out.

- Create the new membership in pending status. The letter and form are sent to the customer and the pending status indicates that you are waiting for the completed form. Refer to the Lifecycle of a Membership for more information.

- When the paperwork is received, change the status of the membership to active .

Note:

Membership Events for Pending Memberships. The system allows events to be created for pending memberships assuming that paperwork is supplemental information that should not prevent service credits from accumulating. If your business practice dictates that the paperwork must be received prior to accumulating service credits, the algorithm or background process that creates events for memberships of this type should be coded to only create events for active memberships. Refer to How Events Are Created for more information.

Creation of a Membership

Memberships may be created using the membership page when a customer has signed up for a special program. In addition, it may be your business practice to automatically create a membership under certain circumstances when a customer has signed up for service.

For example, if you are a co-op, perhaps every new customer is automatically enrolled in a capital credits membership. Or perhaps signing up for cable service automatically entitles your customers to membership in the free pay-per-view movies program. For these cases, the recommendation is to use the order page to start service for your customer and to use questions and miscellaneous fields to record information needed to set up the new membership correctly. Refer to Using Campaigns & Packages to Create a Membership.

Membership Fees

Some memberships may require a fee to be paid by the customer when joining. The behavior of this fee may differ depending on whether it is refundable or not.

- If the fee is nonrefundable, you create an SA with a simple adjustment or a one time billable charge to levy the fee. Refer to Defining Control Tables for a Nonrefundable Fee.

- If the fee is refundable, in addition to defining the SA to hold the fee, you need to put code in place to initiate the refund. Refer to Setting Up a Refundable Fee for more information.

Stopping a Membership vs. Inactivating a Membership

You may stop a membership by entering an end date for the membership. However, depending on how events are created for your membership, stopping the membership may not prevent new events from being created. For example:

- If you stop a frequent flier membership on May 15 th and a bill is subsequently created for the period May 1 st through June 1 st, your business rules may dictate that frequent flier miles should be accumulated for this bill because the membership was active for part of the period covered by the bill.

- For a capital credits membership, capital credit allocations are calculated for the prior year. If a membership stopped in the middle of the previous year, the membership should still get capital credits for the part of the year that the membership was still in effect.

- Capital credit retirements are calculated based on capital credit allocations accumulated in the past. If a membership has been expired, the members are still eligible for retirement amounts for the accumulated capital credit allocations. These retirements may continue for many years after a membership is stopped.

Note:

Membership Status. For all the above scenarios, the system assumes that the status of the membership remains active .

You may have some circumstances where you do not want new events to accumulate after a membership is stopped. To prevent new events from being created, you must change the status of the membership to inactive .

If a customer moves away or otherwise stops service with your company, your business rules dictate whether or not the membership should be stopped or changed to inactive . The following issues must be considered:

- Will service credit events still get created for these memberships? If so, is that acceptable?

- For frequent flier memberships, the miles are calculated based on new bill amounts for the membership's service agreements. If the SAs that contribute to the membership are expired, no new bills are generated so no new miles are accumulated.

- For capital credits, after a customer moves away, the capital credit allocation for the final year of the customer's service may still need to be calculated. In addition, this customer is eligible for the capital credit retirement amounts, even though they are no longer a customer.

- What happens if the customer returns to your company and signs on for service again? Assuming that the same account number is used, is it ok for the membership to be automatically reinstated? Or should the customer reapply? If the customer should reapply, you may consider updating the membership with a stop date when the customer originally stopped service.

Note:

There is nothing in the system logic that automatically updates the membership stop date or the status when service agreements that contribute to the membership are stopped.

The Big Picture of SC Events

The service credit events record the accumulation and redemption of awards earned by the membership. The topics in this section provide background information about a variety of service credit event features and functions.

Note:

Events. For convenience, this document often refers to service credit events simply as "events".

Contents

Event Amounts May Contribute to a Balance

Events May Indicate a Fiscal Year

Events May Indicate a Subcategory

An Event May Cause Other Actions to Occur

Financial Transactions for an Event

How Events Are Created

Creating Pending Events

Events May Be Transferred

CPCRALOC - Allocating Capital Credits

CPCRRETR - Capital Credit Retirement

Event Amounts May Contribute to a Balance

The event amount may be positive or negative, based on whether the event is accumulating points earned for the membership or redeeming points for the membership. For some types of memberships, these credit and debit amounts should be added together to produce the overall balance for the membership.

For some types of memberships, a balance is not applicable. This is true for memberships where the redemption of the points does not occur within the system. For example, if the membership accumulates frequent flier miles on behalf of an airline, the customer redeems the earned miles with the airline, not with your company. As a result, there is no need to calculate a balance for the membership.

If you want the system to calculate a balance, you must set a switch on the membership type page. For memberships that calculate a balance, the balance may be viewed on the membership page.

Events May Indicate a Fiscal Year

For some types of memberships, the amount of each event is associated with a specific fiscal year. This is true for capital credit memberships where capital credit allocations are calculated for a fiscal year. When the capital credits are redeemed (also called retired), the retirement events must also indicate a fiscal year. Because all events for this type of membership are related to a fiscal year, the system can calculate the balance for the events by fiscal year.

If you want the system to require a fiscal year for every event in the membership, you must set a switch on the membership type page. For memberships that calculate a balance and indicate a fiscal year, the balance for each fiscal year may be viewed on the membership page.

Events May Indicate a Subcategory

For some types of memberships, the amount of each event is further grouped by a subcategory. This is common for capital credit memberships where multiple capital credit allocations are calculated. For example, each year, you may calculate allocations for generation and for transmission. Events for memberships of this type must indicate a subcategory.

Cooperatives that allocate capital credits for more than one subcategory, typically want to view the balance of the events over time broken down into these subcategories. When the capital credits are redeemed or retired, the retirement events must also indicate a subcategory. Because all events for this type of membership are related to a subcategory, the system can calculate the balance for the events by subcategory.

Note:

Partial Retirement. For some cooperatives, it is common that certain capital credit allocations are never retired. Refer to Partial Retirement for more information.

If you want the system to require a subcategory for every event in the membership, you must define the valid subcategories on the membership type page. For memberships that calculate a balance and indicate a subcategory, the balance for each subcategory may be viewed on the membership page.

Note:

Calculating Subcategory Balances. If events for your membership indicate a subcategory and fiscal year, balances for the membership are calculated for both groupings.

An Event May Cause Other Actions to Occur

When an event is generated, there are often other actions that need to take place. For example:

- If an event is created that allocates points for the customer, you may want to generate a temporary message on the customer's next bill.

- If a capital credit allocation event is created, the general ledger is affected so an adjustment must be created to post to the general ledger. Refer to Financial Transactions for an Event for more information.

- If an event is created to add frequent flier miles, the event must be marked for extraction so that the information is sent to the appropriate airline. Refer to Interface Membership Information to a Third Party for more information.

- If an event to retire capital credits is created, the customer's balance is affected so an adjustment must be created to transfer the capital credit to the members' service agreements. Refer to Financial Transactions for an Event for more information.

The system relies on algorithms linked to the event type to perform the actions described above and any other action that may be required by your business.

Fastpath:

Refer to Service Credit Event Types for more informationabout the algorithms provided with the base product.

Note:

Event Cancellation Algorithms. The event type also defines algorithms to be executed when an event is canceled.

Financial Transactions for an Event

An event may be related to financial transactions. There are two types of financial transactions that may be linked to the event:

- Financial transactions that contributed to the event. These are bills, payments or adjustments that caused the event to be created. For example, if you generate an event for frequent flier miles as a result of some amount billed for the customer, the bill segments associated with the billed amount are linked to the event. The FTs are linked to the event for audit purposes.

- Financial transactions that are created by the event. In an event may cause other actions to occur, we saw examples where an event completion algorithm may cause adjustments to be created. The FT ID for these adjustments is linked to the event as audit.

Note:

Automatically Canceling Event Financial Transaction. The created by financial transactions may get canceled if the event is canceled AND you have plugged in an appropriate Event Cancellation Algorithm.

For financial transactions that are created by the event, the system must post the financial transactions to one or more appropriate service agreements. The service agreement to use depends on your business rules. For example:

- If the event affects the balance of accounts linked to the membership, the event completion algorithm may create adjustments for service agreements that contribute to the membership.

- If the event affects the general ledger and does not affect any balance for the account, the event completion algorithm simply needs a service agreement to use for the resulting adjustment. Rather than arbitrarily picking any service agreement in this case, a special miscellaneous service agreement should be linked directly to the membership for such adjustments.

How Events Are Created

Although a user may create an event manually on the service credit event page, most events are created automatically by an algorithm or by a background process. The following topics further describe these options.

Contents

Events Created by an Algorithm

Events Created as a Result of a Background Process

Events Created by an Algorithm

You would design an algorithm to create your events if the event should be triggered by an occurrence in the system, such as starting service or generating a bill. For example, perhaps every time you are billed for electric and/or gas service, the system adds one frequent flier mile for every $10 spent on service. Refer to How Are Service Credits Earned? for more information.

The base product provides a bill completion algorithm to create an event as a result of the amount billed for service agreements linked to the membership. Refer to CBCM-SC for more information.

Events Created as a Result of a Background Process

You would use a background process to create the event if the calculation is done periodically or on an ad-hoc basis and does not get triggered by something occurring in the system. For example, the capital credit allocation and retirement processes are typically run once a year, when the business has determined that they are ready to calculate these amounts.

Fastpath:

Refer to Allocating Capital Credits and Capital Credit Retirement for more information.

Creating Pending Events

Events may be created in pending or complete status. Only complete events cause the completion event algorithms to run and cause other actions to occur. You may use the status of pending if you want to review the calculated amount prior to completing the event.

For example, when a cooperative runs the background process to allocate capital credits, it may create the new events in the pending status. This allows the co-op to review the total amount of capital credits calculated for all members. If this total is in line with the co-op's expectations, they run the background process again creating the new events in complete status. Only at this point do the completion event algorithms run.

Events May Be Transferred

In some situations, you may want to transfer service credit events from one membership to another on the service credit event page. For example, if a member dies, you may decide to transfer earned service credits to the membership for a beneficiary. When transferring a service credit:

- The target membership must be of the same membership type as the original membership.

- The original service credit event is canceled and any event cancellation algorithms linked to the SC event type are executed.

- A new service credit event is created and completed and any event completion algorithms linked to the SC event type are executed.

- The new service credit event references the original event ID in the Transferred From event field.

Note:

Contributed to FTs linked to the original event are not transferred to the new event. If you have created by FTs linked to the original event, the recommendation is to ensure that an event cancellation algorithm cancels this FT and that an event completion algorithm for the new event creates an appropriate new FT for the new membership.

CPCRALOC - Allocating Capital Credits

The base product provides a background process that allocates capital credits to members of a cooperative. The result of this process is the creation of new service credit events for capital credit memberships. This background process is typically run after the profits for the previous year are calculated. During that time, this job could be run a number of times for any of the following reasons:

- At the beginning of the allocation process, you may know the total amount to allocate to all members; however, you may estimate the allocation factor that determines the individual amounts that get distributed to the members. You may need to change your estimate and rerun the process until all the individual allocations add up to the desired total amount. To run the job with the estimated allocation factors, indicate that you want events created as pending. When you confirm the correct allocation factor, a final run should be executed with an indication that the events should be created as complete. Every time the process runs, it will first remove any pending events for the same input event type, subcategory and fiscal year. Refer to Creating Pending Events for more information.

- If the cooperative has more than one subcategory, the process must be run for each subcategory. In fact, the above trial-and-error process may need to be followed for each subcategory.

You must provide the service credit event type to use for the new events. This process determines the membership type related to the event type. The process then finds all pending and active memberships for this membership type. To calculate the capital credit allocation, the system finds all applicable bill segments for each service agreement that contributes to the membership.

Capital credit allocations are calculated for a specific fiscal year. The fiscal year is input to the background process and is stamped on any new events created by the process. The system also uses the fiscal year to determine the applicable bill segments for the membership's SAs. It uses the bill segment's accounting date and the accounting calendar to determine the fiscal year for each bill segment.

Note:

Canceled Bill Segments. Any bill segments that were canceled in the fiscal year are included as well.

Accounting Calendar. This process assumes that only one accounting calendar exists for the company. This is the case for companies that operate in a single jurisdiction, which is true for cooperatives.

Allocation Period. If the membership was only effective for part of the fiscal year, the allocations are only calculated for the period of time that the membership was in effect.

For each applicable bill segment, the system determines the SQ total and the total sales amount for each segment. To calculate the totals correctly, a characteristic type and value to identify SQ bill lines must be provided to the background process and a characteristic type and value to identify bill lines contributing to the total sales amount must be provided to the background process.

Fastpath:

Refer to Identifying SQ and Sales Information for Historical Bill Segments for more information.

If your membership type indicates subcategories to be used for the events, you must provide a subcategory as input. If you have multiple subcategories for your membership, this process must be run once for each subcategory.

The calculation of the capital credit allocation amount typically uses an allocation factor. This factor is often different for each subcategory. You will probably define a different bill factor for each subcategory and use the appropriate bill factor when submitting the process for each subcategory.

This process also assumes that the allocation factor differs by the customer's revenue class. It assumes that the bill factor's characteristic type is revenue class. Refer to Designing Bill Factors for Credit Allocation for more information. For each service agreement linked to the membership, the appropriate allocation factor is determined based on the revenue class for the SA type.

Capital credits for the input subcategory are calculated as follows:

Fiscal year sales amount - (fiscal year SQ amount * revenue class allocation factor) = Allocation Amount

The calculated amount is compared against a minimum amount, input to the background process. If the calculated amount is less than the minimum, no event is stored for this amount.

After determining the amount, a new service credit event is created for the membership. The event is stamped with the input subcategory, service credit event type and fiscal year.

The FTs for all the bill segments used to determine the allocation amount are linked to the event as contributed to FTs. Refer to Financial Transactions for an Event for more information.

Note:

Rerunnable Process. This process is restartable and rerunnable. When running the process, for each membership the system checks whether there is already a complete event for the input service credit event type, subcategory and fiscal year. If so, it does not create a new event.

Fastpath:

Refer to CPCRALOC for more information.

CPCRRETR - Capital Credit Retirement

Note:

Calculation Method. There are various calculations that different cooperatives may use when determining the amount to retire. The base product has provided one calculation method.

This background process is run when a cooperative is ready to pay out allocated capital credits to its members. This process is referred to as retirement. The result of this process is the creation of new service credit events for capital credit memberships. Capital credits are paid as the cooperative's financial position permits. During that time, this job could be run a number of times for any of the following reasons:

- You may choose to run the process and create pending events to review the results prior to finalizing the retirement. When you are happy with the results, a final run should be executed with an indication that the events should be created as complete. Every time the process runs, it will first remove any pending events for the same input event type and subcategory.

- If the cooperative has more than one subcategory, the process may be run separately for each subcategory. You may also run the process with no subcategory indicated and then all subcategories are processed.

Note:

Partial Retirement. For some cooperatives there may be capital credits for some allocated amounts that are never retired. If that is the case, simply run this process for each subcategory whose amounts do get retired.

You must provide the service credit event type to use for the new events. This process determines the membership type related to the event type. The process then finds all pending and active memberships for this membership type.

This process receives a percentage to retire as input. It determines the current balance of all completed events for the subcategory. The retirement amount for the subcategory is calculated as the current balance * input percentage to retire. The process then determines the outstanding balance for each subcategory and fiscal year combination. For every combination that still has a balance, the process creates events to relieve the outstanding balance for the oldest fiscal year first. It creates events for subsequent fiscal years until the full retirement amount is used.

In order for the process to be rerunnable and restartable, a Control ID is used to mark retirement events that are created by the process. The Control ID is input to the routine and is determined by the user. When the process runs, it determines whether an event already exists for the subcategory / Control ID combination. If so, new events are not created for that subcategory. If you run the process multiple times for the reasons described above, you should use the same Control ID each time. This way the system knows that the process is being run again for the same retirement calculation.

Fastpath:

Refer to CPCRRETR for more information.

Maintaining Service Credit Memberships and Their Events

The topics in this section describe how to maintain a service credit membership and its events.

Fastpath:

Refer to The Big Picture Of Service Credits for background information about service credits.

Contents

Service Credit Membership

Maintaining Service Credit Events

Service Credit Membership

The topics in this section describe how to maintain service credit memberships. Refer to The Big Picture Of Service Credit Membership for background information about memberships.

Contents

Lifecycle of a Membership

Service Credit Membership - Main

Service Credit Membership - Account

Service Credit Membership - Characteristics

Service Credit Membership - Membership Tree

Lifecycle of a Membership

The following diagram shows the possible lifecycle of a service credit membership.

Pending A service credit membership may start out in the Pending state. A membership is typically created in this state if the creation of the membership requires approval or any manual step (e.g. waiting for paperwork) that needs to be completed prior to activation.

Note:

Events for Pending Memberships. Service credit events may still be created for membership records in the Pending state.

Active A service credit membership is in the Active state when a customer is actively participating in a service credit membership. A membership may be created in the Active state or it may transition to the Active state from Pending when all the necessary approval or paperwork is complete.

Note:

Manual Activation Only. There is no system functionality that automatically changes the status of a membership from Pending to Active . This is a manual step.

Inactive If a customer is no longer actively participating in a service credit membership, change the status to Inactive . This will prevent any new events from being created for the membership.

Service Credit Membership - Main

This page is used to maintain and display general information about a service credit membership. Open this page using Customer Information, Service Credit Membership.

Description of Page

Membership Info and Membership ID are displayed on every page. These values only appear after the membership exists on the database. The ID is a system-assigned random number. The Membership Info is a concatenation of important details about the membership.

Membership Status defines the state of the membership.

Fastpath:

Refer to Lifecycle of a Membership for more information about membership status.

Click the Activate button to activate a Pending membership. When this button is clicked, the system executes any Membership Activation algorithms that are linked to the service credit membership type.

Click the Inactivate button to transition an Active membership to Inactive . When this button is clicked, you are prompted to provide an Inactive Reason and the system executes any Membership Inactivation algorithms that are linked to the service credit membership type.

Indicate the SC Membership Type. This field is important as it controls numerous aspects of the behavior of the membership and its events.

Fastpath:

For more information about what the membership type controls, refer to Setting Up Service Credit Membership Types.

Indicate the Start Date and End Date, which define the period for which this membership is effective. Leave the end date blank if this membership is effective indefinitely. Refer to Stopping a Membership vs. Inactivating a Membership for more information.

If this membership is related to a record in an external system, use the External ID to indicate the unique identifier of the record in the external system.

If events linked to your membership may generate miscellaneous adjustments, indicate the Service Agreement to use for these miscellaneous transactions. The account for this service agreement must be one of the accounts linked to the membership.

The Events grid displays the events linked to the membership. To view any of the events use the drill down button.

If your SCM type indicates that the membership has a balance, the tree at the bottom displays information about the balance of the membership based on the amounts for completed events. If the SCM Type indicates subcategories and/or a fiscal year is required, subtotals for completed events are also displayed for each subcategory / fiscal year and by fiscal year / subcategory, if applicable. If any pending events exist, the tree includes a node with information about these events.

Service Credit Membership - Account

This page is used to maintain the accounts linked to a service credit membership. Open this page using Customer Information, Service Credit Membership and navigate to the Account tab.

Description of Page

Indicate the Account ID for each account linked to this membership. Typically a membership will be linked to only one account. However, if a person has multiple accounts and the service credits should span the accounts, multiple accounts are linked to the same membership.

The Service Credit Membership zone on the Account Information portal contains information about memberships for the current customer. (When you find one of the customer's records on Control Central - Main, you are automatically transferred to the Account Information portal.)

Note:

Portal Preferences. The Service Credit Membership zone only appears if you have modified your preferences to display this zone.

Service Credit Membership - Characteristics

The characteristics page contains information that describes miscellaneous information about the service credit membership. Open this page using Customer Information, Service Credit Membership and navigate to the Characteristics tab.

Description of Page

Note:

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

To modify a characteristic, simply move to a field and change its value. To add a new characteristic, click + to insert a row then fill in the information for each field. 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.

Note:

Default Note. A service credit membership's characteristics default from the service credit membership type.

Service Credit Membership - Membership Tree

The membership tree page displays accounts, SAs and persons linked to the service credit membership. Open this page using Customer Information, Service Credit Membership and navigate to the Membership Tree tab.

Description of Page

The tree displays each account linked to the membership. For each account, a node exists for:

- Each service agreement whose SA type is included in the service credit membership type 's SA type collection.

- Each financially responsible person linked to the account. These persons are considered the members.

Maintaining Service Credit Events

Service credit events record credits earned or redeemed for a given membership. The topics in this section describe how to maintain service credit events. Refer to The Big Picture of Service Credit Events for background information about memberships and their events.

Contents

Lifecycle of a Service Credit Event

Service Credit Event - Main

Lifecycle of a Service Credit Event

The following diagram shows the possible lifecycle of a service credit event.

Pending A service credit event may start out in the Pending state. An event is typically created in this state when a review of the event is desired before completing it. Refer to Creating Pending Events for more information.

Complete A service credit event is typically created in the Complete state. When an event is completed, the system executes any event completion algorithms indicated on the service credit event type.

Canceled If a service credit event is no longer valid, it may be Canceled . When an event is canceled, the system executes any event cancellation algorithms indicated on the service credit event type.

Service Credit Event - Main

Open this page using Customer Information, Service Credit Event.

Description of Page

The Service Credit Event Info is a concatenation of important details about the service credit event. The Service Credit Event ID is a unique system-assigned random number. These values only appear after the service credit event exists on the database.

Service Credit Event Status defines the state of the service credit event.

Fastpath:

Refer to Lifecycle of a Service Credit Event for more information.

Click the Complete button to change a Pending event to Complete . When this button is clicked, the system executes any event completion algorithms that are linked to the service credit event type.

Click the Transfer button to transfer this event to another membership. When this button is clicked, you are prompted to provide the membership ID to transfer the event to. The new membership must have the same membership type as the original membership. Refer to Events May Be Transferred for more information.

Click the Cancel button to cancel this event. When this button is clicked, the system executes any event cancellation algorithms that are linked to the service credit event type.

The Create Date/Time captures the date and time that this event was created. This defaults to the system date/time.

Indicate the service credit Membership ID to which this event should be linked.

Indicate the Service Credit Event Type. This field may define algorithms to be executed when the event is completed or canceled. Refer to Setting Up Service Credit Event Types for more information.

If your service credit membership type indicates one or more subcategories to be associated with events for this type of membership, indicate the appropriate Subcategory Name for this event.

If your service credit membership type indicates that fiscal year is required, indicate the appropriate Fiscal Year for this event.

Enter the Service Credit Event Amount. If your service credit membership type indicates that your membership has a balance, this amount is used to calculate the overall balance for the membership as well as a balance for the subcategory and/or fiscal year, if applicable.

If this event was created as a result of a transfer from another membership, the Transferred From Event ID is displayed.

If the information about this event may be downloaded to a third party system, you should have an event completion algorithm that stamps the appropriate Batch Control and Batch Number onto the event.

The FT collection displays information about financial transactions related to this event. Two different categories of financial transactions may be linked to the event.

- FTs that contributed to this event. These financial transactions played a part in the creation of this event. For example, if frequent flier miles are earned as a result of newly created bill segments, the FTs related to these bill segments are linked to the event and marked as contributed to FTs. This information is purely for audit purposes. It is the responsibility of the algorithm or background process that creates the event to populate the collection of contributed to FTs. Refer to How Events Are Created for more information.

Note:

The amount of the contributed to FTs will not necessarily add up to the amount of the event. Refer to the algorithm or background process that calculates the amount of the event to understand how the event amount is calculated based on the amount of the contributed to FTs

- FTs that were created by this event. These financial transactions are created as a result of this event. For example, if you have generated a capital credit allocation event, perhaps you need to post information to the general ledger. An allocation event should therefore generate an adjustment to post the effect on the GL. The adjustment's FT is linked to the event as an audit. In order to create a financial transaction related to this event, you must plug in an appropriate event completion algorithm on your service credit event type.

Fastpath:

Refer to An Event May Cause Other Actions to Occur for more information.

Appointments

Note:

Separate module. Please note that the Appointments functionality is associated with a separate Appointments module. If this module is not applicable to your business, you may turn it off. Refer to Turn Off A Function Module for more information. .

An appointment is an agreement with a customer to perform one or more field activities at a given premise on a specific date / time band. The topics in this section describe how you manage appointments and schedule appointments.

Contents

The Big Picture of Appointments

Appointment Maintenance

Appointment Period Maintenance

The Big Picture of Appointments

The topics in this section provide background information about appointments.

Contents

An Appointment Is Made With A Dispatch Group

A Dispatch Group Has Appointment Periods

An Appointment Is Notional

Navigating To The Make / Break Appointment Page

Appointments Are Not Applicable To All Field Activities

Determining Available Appointments

Limiting The Number Of Appointments In An Appointment Period

Canceling An Appointment

Compensating A Customer For A Missed Appointment

Enabling Appointments

An Appointment Is Made With A Dispatch Group

A dispatch group is a logical group of work crews located at an operations area. When a field activity is created, the system assigns it a dispatch group based on the type of activity, the type of service point, and the operations area that manages the service point. Refer to Defining Field Order Options and The Big Picture Of Field Orders for more information about field activity creation and dispatch groups.

When you make an appointment, you are booking time with one of the dispatch group's crews to perform one or more field activities located at a premise.

A Dispatch Group Has Appointment Periods

An appointment period is a time-band on a given date range when an appointment can be scheduled with a dispatch group. For example, you might have an appointment period from 1 pm to 5 pm on 15-Jan-2003 for the "new service" crew.

A dispatch group can have many appointment periods on a given date. For example, if you offer appointments in two-hour time bands and your crews work 8 hours per day, then your dispatch groups will have four appointment periods (e.g., 8am to 10am, 10am to 12pm, 1pm to 3pm, and 3pm to 5pm).

The Appointment Periods transaction is used to maintain a dispatch group's appointment periods.

An Appointment Is Notional

The Appointment transaction is used to make / break an appointment for a premise. When you make an appointment, you are actually linking one or more field activities to an appointment period. There is no entity in the system called "appointment". Rather an appointment is a group of field activities located at a premise that are linked to an appointment period.

Navigating To The Make / Break Appointment Page

Any of the following methods can be used to navigate to the Appointment transaction:

- An alert in the Alert Zone highlights if an appointment exists for the current premise. The user is transferred to the appointment transaction if they drill down on the alert.

- You can setup an order's campaign to automatically transfer a user to the appointment transaction whenever an order is completed for a given campaign. This might be useful for campaigns that cause field activities to be created.

- A user can setup a favorite link associated with the appointment transaction.

- The field activity transaction allows a user to transfer to the appointment page when an appointment exists for a field activity

- Via any of the following menus:

- Premise context menu

- Field activity context menu

- Main menu

Appointments Are Not Applicable To All Field Activities

For each FA type, you mark which types of field activities are eligible for dispatch. For those FA types that may be dispatched, you can indicate that an appointment is required for dispatch , optional or not applicable . Field activities for which appointments are not applicable are not displayed on the appointment transaction.

If your field activity requires an appointment but an appointment has not yet been made, the system does not allow you to associate the field activity with a field order.

Determining Available Appointments

On the Appointment transaction, you can view available appointments for selected field activities by clicking a button. When this button is clicked, the available appointment periods are constructed by an algorithm plugged-in on the selected dispatch group. This means your implementation can construct whatever rules it needs to determine the list of available appointments that are presented to a user. Refer to AAVL-AVLAPPT for a description of a base package plug-in.

Limiting The Number Of Appointments In An Appointment Period

When you set up an appointment period for a dispatch group, you can define the maximum number of appointments that can be scheduled in the period. For example, you can indicate that the "meter installation crew for the northern region" has three appointments available between 1 pm and 5 pm on 15-Jan-2003.

Note:

An appointment is notional. As described above, an appointment is a group of field activities located at the same premise that are linked to an appointment period.

The appointment validation algorithm plugged-in on the dispatch group controls whether a new appointment can be scheduled at a premise. This means your implementation can construct whatever rules it needs to prevent overbooking an appointment period. Refer to AAVL-AVLAPPT for a description of a base package plug-in.

Canceling An Appointment

The Appointment transaction also allows a user to cancel an appointment. This simply breaks the linkage between a field activity and an appointment period.

The following points describe other mechanism that can cause appointment cancellation:

- If a user changes the start or stop date associated with a service agreement on the Start / Stop page, the system cancels all pending field activities and creates new ones. When the pending field activities are canceled, the appointments are implicitly canceled. The new field activities will NOT be linked to an appointment period when they are created (the user must make new appointments).

- If a user deletes a field activity, the appointment is implicitly canceled.

Compensating A Customer For A Missed Appointment

In some locales, if an appointment is missed, the company has to pay a fine to the customer. No specific functionality exists in the system to support this practice. However, your implementation could implement this requirement as follows:

- Field activities that can have penalties should have a step that records a customer contact (note, a field activity's field activity type controls the steps that must be entered to complete a field activity).

- When a user adds such a contact, the contact date/time should be the date/time the crew showed up for the appointment.

- The field activity types associated with such field activities should have a completion algorithm that compares the appointment period's date/time to the customer contact's date/time and levies a penalty via the creation of an adjustment. Note, this algorithm is not supplied with the base package.

- In addition, you may want to create an implementation-specific table to record the linkage between the adjustment and the field activity.

Enabling Appointments

This section describes set up tasks necessary to allow appointments to be made for a dispatch group.

Contents

Plug In The Appropriate Algorithms On Each Dispatch Group

Set Up Appointment Periods

Plug In The Appropriate Algorithms On Each Dispatch Group

Set up each dispatch group that can have appointments as follows:

- Define the appropriate "available appointments" plug-in on the dispatch group. Refer to Determining Available Appointments for more information.

- If you want to validate that an appointment period is valid for a field activity, plug-in the appropriate "appointment validation" algorithm on the dispatch group. Refer to Limiting The Number Of Appointments for more information.

Set Up Appointment Periods

Use Appointment Period Maintenance to set up appointment periods for the dispatch group. Refer to A Dispatch Group Has Appointment Periods for more information.

Appointment Maintenance

This page allows you to manage appointments for a premise's field activities. The following functions can be performed on this page:

- You can make an appointment for one or more field activities

- You can view existing appointments

- You can view historical appointments

- You can cancel an appointment

Note:

The field activity may change. When an appointment period is linked to a field activity, the field activity's scheduled date is changed to reflect the appointment date and the field activity's dispatch group is changed to reflect the appointment period's dispatch group.

Open this page using Field Order, Appointment.

Description of Page

Premise is a concatenation of summary information about the premise. Premise ID is the unique identifier of the premise.

The Existing Appointments grid contains an entry for every field activity (regardless of status) that is linked to an appointment period at this Premise.

You can cancel an appointment for a field activity by clicking Cancel. The Cancel button is only enabled if the cancellation of the field activity would cause it to appear in the Field Activities Without Appointments grid (i.e., you can only cancel appointments for pending field activities).

Note:

External System Integration. If the FA integration module is not turned off and the dispatch group for this field activity references an FA Integration external system feature configuration, clicking Cancel triggers a real-time message to be sent to the external system to cancel the appointment.

The Field Activities Without Appointments grid contains an entry for every field activity that meets the following qualifications:

- The field activity's status is Pending .

- The field activity's activity type indicates that it is eligible for dispatch and that appointment booking is required for dispatch or optional .

- The field activity isn't linked to a field order whose status is Work Done, Not Recorded .

- The field activity isn't linked to an appointment period.

The Search for an Appointment section is used to view possible appointments for the selected field activities (and make an appointment by selecting of the available appointments).

Note:

External System Integration. The remaining information for this page is applicable to organizations that are not using the FA integration module, i.e. it is turned off. If your organization uses this module, refer to Appointments And External System Integration for information about how this section may behave.

Click Show Appointments to populate the Available Appointments grid with appointment periods. You have the following options before you click this button:

- Specify a Dispatch Group. If you do this, available appointments for the specified dispatch group will be shown in the following grid.

- Leave Dispatch Group blank. If you do this, the system will look for available appointments for the "lowest common denominator" dispatch group shared by the selected field activities. Refer to Using Alternate Dispatch Groups To Find The Lowest Common Denominator for more information.

- Specify On/Around Date. If you do this, available appointments on / before this date will be shown in the following grid.

- Leave On/Around Date blank. If you do this, the system looks for available appointments on / before the earliest date from the selected field activities.

The Available Appointments grid is populated after you click Show Appointments. Note, an algorithm that's plugged-in on the dispatch group constructs the list of available appointments. Refer to Determining Available Appointments for more information.

Note:

Assumptions at open. The system selects all Field Activities Without Appointments and clicks Show Appointments when this page opens (assuming you want to schedule an appointment for these field activities). This can result in an error (e.g., if there is no common dispatch group amongst the selected field activities). When an error occurs, it is displayed adjacent to Search for an Appointment.

The Available Appointments grid contains an entry for every possible appointment period. In addition, adjacent to the grid is the From and To date range from which these appointment periods were extracted. You have the following options at this point:

- Click OK to create an appointment for the selected field activities. This simply links the selected field activities to the respective appointment period.

- Click the < or > buttons that surround the From and To dates. Clicking these buttons causes the system to look for appointment periods in the previous / next date range.

Note:

The field activity may change. When an appointment period is linked to a field activity, the field activity's scheduled date is changed to reflect the appointment date and the field activity's dispatch group is changed to reflect the appointment period's dispatch group.

The field order may change. When an appointment period is linked to a field activity that has been dispatched (i.e., linked to a field order), the field order's schedule date/time is updated with the earliest appointment date/time of all non-canceled non-completed field activities that are linked to the field order.

Appointments And External System Integration

If the FA integration module is turned off and the dispatch group references an external system feature configuration, the Search for an Appointment section of the page is built based on the configuration of the external system feature configuration options.

For a Dispatch Group referencing an external system feature configuration:

The From Date defaults to the earliest scheduled date of the selected field activities. The To Date defaults to the From Date plus the value of the Default Days of Available Appointment feature configuration option whenever a dispatch group is selected.

If your external system allows forced appointments, the Forced checkbox is displayed. The user should check this box when attempting to book an appointment that is not available in the system.

If your external system options include user defined search criteria fields, these fields are displayed below the from date and to date.

Click Show Appointments to invoke the external system to display available appointments. If the communication is successful, the Available Appointments grid displays the results.

Each available appointment includes an OK button to click to choose the desired appointment.

If your external system allows forced appointments, or allows manual appointments is set to Y, then the grid includes "+" and "-" buttons to allow you to add or remove appointments.

If your external system allows forced appointments, allows manual appointments or allows the user to narrow the appointment window, then the start date / time and end date / time may be modified by the user.

If your external system options include user defined result fields, additional columns are included after the end date / time for each user defined field.

When the user clicks OK for the desired appointment a message is sent to the external system to book the appointment.

Note:

The field activity may change. If a message appointment is successfully sent, the field activity's scheduled date is changed to reflect the appointment date and the field activity's dispatch group is changed to reflect the appointment period's dispatch group.

Fastpath:

Refer to Booking Appointments Via An External System for more information about this integration.

Appointment Period Maintenance

An appointment period is a time-band on a given date range when an appointment can be scheduled with a dispatch group. For example, you might have an appointment period from 1 pm to 5 pm on 15-Jan-2003 for the "new service" crew. This page is used to maintain a dispatch group's appointment periods. Refer to The Big Picture of Appointments for more information about appointments and appointment periods.

Note:

Mass update functionality exists. This page has mass-update functionality that can be used to add / update / delete many appointment periods at once. Refer to How to for more information

External System Integration. If your organization uses the FA integration module, you do not need to set up appointment periods for dispatch groups that reference an external system. The system automatically creates appointment period records as an audit when an appointment is booked via the external system.

Open this page using Field Order, Appointment Period.

Description of Page

The grid on this page contains one row for every appointment period linked to the Dispatch Group.

This grid is initially populated with appointment periods starting from today's date and ending 7 days in the future when you select a Dispatch Group. If you wish to see appointment periods for a different date range, enter a Start Date and/or Number of Days and then click the search button; the system will populate the grid with all appointment periods starting from Start Date and ending X days in the future (where X is Number of Days).

Each appointment period in the grid contains the following information:

- Start Date and Start Time define the start of the appointment period.

- End Date and End Time define the end of the appointment period. The end date is defaulted to the start date.

- Maximum Appointments defines the maximum number of appointments in the appointment period. Refer to Limiting The Number Of Appointments for more information about the uses of this field.

- Scheduled Appointments indicates the number of field activities that are currently linked to this appointment period. You can use the go to button to view the field activities in the appointment period.

- Appt Period ID indicates the unique identifier that has been assigned to this record.

Refer to How To Copy Appointment Periods for information about the Copy Appointment Periods button. This button is disabled if the dispatch group references a WFM system.

Refer to How To Update Maximum Number Of Appointment Periods for information about the Update Max Appointments button. This button is disabled if the dispatch group references a WFM system.

How To

The topics in this section describe how to perform common appointment period functions.

Contents

How To Copy Appointment Periods

How To Update Maximum Number Of Appointments

How To Delete Appointment Periods

How To Overwrite Appointment Periods

How To Copy Appointment Periods

You can click Copy Appointment Periods to quickly create multiple appointment periods for a dispatch group by copying appointment periods from the same or a different dispatch group. The Copy Appointment Periods window opens when this button is clicked.

Note:

Mass overwrites and deletes. See the following description for how this pop-up can be used to overwrite and/or delete existing appointment periods.

In the Copy Appointment Periods window, you can:

Use Copy From Dispatch Group to define the dispatch group from which you want to copy appointment periods.

Use Copy To Dispatch Group to define the dispatch group for which you are creating appointment periods.

Use Copy To Start Date and End Date to define the period for which you are creating appointment periods. The system will display each date's day of the week and the Total Days in the period.

Use Copy Method to define how appointment periods will be copied from the Copy From Dispatch Group to the Copy To Dispatch Group. The following options are possible:

- Use Copy from the matching day in the template week if you want to copy the appointment periods from a matching day of the week from a template week. When this option is selected, you must identify the Start Date of Template Week. Adjacent to this date, the system will display:

- The day name of the start day

- The number of appointment periods in the start day

- The last day in the 7 day period (i.e., a day 7 days in the future)

- The day name of the last day

- The number of appointment periods in the last day

- For example, if you enter a Copy To period of 1-Jan-2004 to 31-Jan-2004 , the system will create appointments for every Monday in this period by copying the appointment periods from the Monday in the Template Week (it will do the same for Tuesdays, Wednesdays, etc. in the Copy To period).

- Use Copy the same day repeatedly if you want to copy the appointment periods from a Template Day. Adjacent to this day, the system displays:

- The day name of the start day

- The number of appointment periods in the start day

- For example, if you enter a Copy To period of 1-Jan-2004 to 31-Jan-2004 , the system will create appointments for every day in this period by copying the appointment periods from the Template Day.

Before you press OK, consider if holidays during the Copy To period should be treated differently than the template days. If so:

- Use Calendar in which Holidays are Defined to define the work calendar that the system should use to identify holidays. The system will display the number of holidays it finds in the Copy To period adjacent.

- Use For Holidays, Copy the Periods from this Date to define the template day whose appointment periods should be used for holidays.

After you have carefully verified this information, press OK. Please see the following notes if you detect a mistake after you press OK.

Note:

You can also use this transaction to overwrite appointment periods. This transaction is also capable of overwriting existing appointment periods for a dispatch group. If the Copy To Dispatch Group has appointment periods in the Copy To period, the system will ask if you want to delete them and then create fresh appointment periods. Please note, if there are any appointment periods in the Copy To periods with appointments, you may not overwrite the appointment periods.

Mass Delete. If the Copy To period has existing appointment periods (and they don't already have appointments) and the Copy From Dispatch Group doesn't have corresponding appointment periods, the Copy To periods will be deleted. Refer to How To Delete Appointment Periods for more information.

How To Update Maximum Number Of Appointments

You can click Update Max Appointments to quickly update the maximum number of appointments on existing appointment periods. The window that appears is identical to that described under How To Copy Appointment Periods ; the only difference being that when this window is invoked in "update mode", only existing periods linked to the Copy To Dispatch Group will be updated; appointment periods will never be created or deleted. Follow the following instructions when you need to update the maximum number of appointment periods.

Use Copy From Dispatch Group to define the dispatch group whose appointment period(s) contain the desired maximum number of appointments.

Use Copy To Dispatch Group to define the dispatch group whose appointment periods will be updated.

Use Copy To Start Date and End Date to define the period for which you are updating appointment periods. The system will display each date's day of the week and the Total Days in the period.

Use Copy Method to define how appointment periods will be updated. The following options are possible:

- Use Copy from the matching day in the template week if you want to update the appointment periods from a matching day of the week from a template week. When this option is selected, you must identify the Start Date of Template Week. Adjacent to this date, the system will display:

- The day name of the start day

- The number of appointment periods in the start day

- The last day in the 7 day period (i.e., a day 7 days in the future)

- The day name of the last day

- The number of appointment periods in the last day

- For example, if you enter a Copy To period of 1-Jan-2004 to 31-Jan-2004 , the system will update appointment periods for every Monday in this period by copying the maximum number of appointments from the Monday in the Template Week (it will do the same for Tuesdays, Wednesdays, etc. in the Copy To period).

- Use Copy the same day repeatedly if you want to update the appointment periods from a Template Day. Adjacent to this day, the system displays:

- The day name of the start day

- The number of appointment periods in the start day

- For example, if you enter a Copy To period of 1-Jan-2004 to 31-Jan-2004 , the system will update appointments for every day in this period by copying the maximum number of appointment periods from the Template Day.

Before you press OK, consider if holidays during the Copy To period should be treated differently than the template days. If so:

- Use Calendar in which Holidays are Defined to define the work calendar that the system should use to identify holidays. The system will display the number of holidays it finds in the Copy To period adjacent.

- Use For Holidays, Copy the Periods from this Date to define the template day whose appointment periods should be used for holidays.

After you have carefully verified this information, press OK.

How To Delete Appointment Periods

You can delete a dispatch group's appointment periods one-by-one by clicking the delete button in the appointment periods grid. To quickly delete many appointment periods for a dispatch group you can click Copy Appointment Periods. We understand this is counterintuitive. The following instructions describe how to do this:

Determine the period of time during which you want to delete appointment periods (note, you cannot delete an appointment period if there are any appointments linked to the appointment period). We refer to this period as the "deletion period" below.

Use Copy From Dispatch Group to define a dispatch group that doesn't contain appointment period(s) during the deletion period.

Use Copy To Dispatch Group to define the dispatch group whose appointment periods will be deleted.

Use Copy To Start Date and End Date to define the deletion period. The system will display each date's day of the week and the Total Days in the period.

Use the Copy the same day repeatedlyCopy Method. You should identify a Template Day that has no appointment periods. Adjacent to this day, the system displays:

- The day name of the start day

- The number of appointment periods in the start day. Please confirm that this value is zero.

You don't have to specify the holiday period options.

After you have carefully verified this information, press OK.

How To Overwrite Appointment Periods

The window that appears when you click Copy Appointment Periods has the ability to delete existing appointment periods (as long as they don't have appointments) and then create new ones. It works like this - if the Copy To Dispatch Group has appointment periods in the Copy To period, the system will ask if you want to delete them and then create fresh appointment periods. Please follow the instructions described under How To Copy Appointment Periods for a description of the Copy Appointment Periods functionality.

Loans

There are many reasons why your company may loan money to customers. For example, your company may loan money to:

- Finance service upgrades (e.g., to change to dual fuel)

- Support economic development (e.g., to extend a power line)

- Promote energy conservation (e.g., customers borrow to insulate their house)

Note:

Loans are optional. You need only set up loans if your organization loans money to customers. For information on setting up the system to enable loans, refer to Defining Loan Options.

Contents

The Big Picture Of Loans

Loan Maintenance

How To

The Big Picture Of Loans

The topics in this section provide background information about loans.

Contents

Loans Are Service Agreements

Loan Interest Charges

Loan Amortization Schedules

Loan Overpayments

The Lifecycle Of A Loan

Finalizing And Closing A Loan

Navigating To The Loan Maintenance Page

Loans Are Service Agreements

Loans are initiated by creating a loan service agreement for a customer. The loan service agreement (and its SA type) contains the loan's terms, including the loan amount, periodic payment amount, the number of amortization periods, the interest rate, and the periodicity of the bills. Loan service agreements are just like other service agreements in many ways:

- The system bills the customer for the periodic payment amount using information on the service agreement.

- The customer pays the billed amount.

- If the customer doesn't pay, credit and collections may start a collection process to encourage the customer to pay (depending upon how the loan debt class has been set up on your system).

Loan service agreements differ from other service agreements in the following ways:

- Loans have interest charges.

- Loans have amortization schedules.

- Loan SAs are maintained on a separate transaction (refer to Loan - Main for more information).

Note:

Loan service agreements are created using Start / Stop. Loan service agreements are created using start / stop just like all other service agreements. The start/stop transaction has special loan functionality that allows an operator to specify the service agreement-specific loan terms described above. A start option can be specified to override the SA type's interest bill factor.

Loan Interest Charges

When a bill is generated for a loan, the interest charge is calculated using an algorithm. The base package loan interest charge algorithm type calculates simple interest based on:

- Unbilled principal (i.e., the payoff balance minus the current balance)

- The number of billing periods covered by the bill

- The interest rate

Note:

No interest on interest and no interest on past due amounts. Just like a classic home loan, the base package algorithm does not calculate interest on interest, nor does it calculate interest on past due amounts. However, your system may be set up to levy a late payment charge.

After the interest charge is calculated, the bill segment FT algorithm generates the financial transactions for the bill. The base package FT algorithm generates a financial transaction that adds the interest charge to the payoff balance. In other words, if the customer wanted to pay off the loan, they would owe the principal balance plus the interest charge.

Fastpath:

For more information, refer to Billing For Loans And Interest Calculation.

Loan Amortization Schedules

A loan's periodic payment amount is calculated such that the customer repays the loan in equal amounts over the term of the loan (with the exception of the first and last bill segments, which are typically for different amounts). The amortization schedule is a projection of the amount of principal and interest in each payment over the life of the loan. The amortization schedule may change, for example if the interest rate changes or the customer makes an overpayment (reducing the principal balance).

The amortization schedule is a theoretical projection of the future. The term theoretical is used because the customer's actual payments can cause the schedule to change. For example, if a customer overpays a bill, the loan's length decreases and the amount of principal and interest in each scheduled payment changes.

A loan's amortization schedule is calculated when you click the Calculate button on Loan - Main . When this button is clicked, an algorithm plugged in on the loan SA type actually calculates the amortization schedule.

You can view a loan's latest amortization schedule using Loan - Main . You can also change the loan's payment periods or periodic payment amount on this page and recalculate the loan's amortization schedule.

Negative Amortization

The system does not allow you to use a periodic payment amount that is less than the periodic interest amount. If it did, the customer's payoff balance would increase over time (this is referred to as "negative amortization"). There are two methods you can use to specify a payment amount in the system. Depending on which method you use, the system informs you of negative amortization differently:

- If you enter a payment amount that is too small on the Start confirmation page or in the Renegotiate Future Payments grid on Loan maintenance, you get an error message when you click the Calculate button. You must fix the payment amount before you can start the loan or save your changes.

- If you manually override the Payment Amount on Loan maintenance, you can save a payment amount that is too small to cover the interest charges. However, the system notifies you that it is not able to calculate the Forecasted Schedule because of negative amortization. Additionally, bill segments for the loan SA are produced in error until the payment amount is adjusted appropriately.

Loan Overpayments

Overpayments reduce the principal amount (the amount owed on the loan), which follows the philosophy adopted by a typical home loan. When the payment is made, any overpayments are distributed according to the overpayment distribution algorithm defined for the customer class. Typically, loan service agreements should be set up so that the overpayment is applied to the principal balance.

When the payment transaction is frozen, the system checks to see if there is a credit amount on the loan SA's current balance. If a credit exists, the customer has made an overpayment and an adjustment is created to transfer the amount of the credit from the SA's current balance to its payoff balance, thus reducing the principal by the amount of the overpayment.

Fastpath:

For more information about the adjustments created for loan overpayments, refer to Overpayments On Loans.

Note:

Overpayments and interest. The base package interest calculation algorithm (plugged in on the loan's SA type) does not take into consideration the exact date that the overpayment is made when calculating the interest for the period. It only takes into consideration the outstanding principal amount (payoff balance - current balance) at the time of the interest calculation.

The Lifecycle Of A Loan

Loans have the same lifecycle as other service agreements (e.g., pending start , active , pending stop ). You should rarely have to manually change a loan service agreement's status. Why? Just like other service agreements, the system changes the status behind-the-scenes when various events take place. For example, loans in the pending start state are automatically activated by a system background process.

If you need to manually change a loan service agreement's status (e.g., you need to cancel a loan that was inadvertently started), you can do so from Service Agreement - Main.

Finalizing And Closing A Loan

A loan SA is automatically stopped when the last bill segment is generated for the loan. If the remaining principal balance (plus accrued interest) is less than or equal to the loan payment amount, the SA status is changed to pending stop and the bill segment is marked as the closing bill segment. The SA can then be stopped by the user (manually using the SA page) or by the SA activation background process. When the customer pays the last bill, the loan SA is closed.

Fastpath:

For more information about transitioning SAs from pending stopped, refer to Finalizing Pending Stops.

Navigating To The Loan Maintenance Page

Any of the following methods can be used to navigate to the Loan Maintenance transaction:

- A user can set up a favorite link associated with the loan transaction.

- Via any of the following menus:

- Account context menu

- Service agreement context menu

- Main menu

Note:

Alerts and Loans. If the loan SA type is set up with an alert, the Alert Zone highlights if a loan exists for the current account. You are transferred to the SA maintenance transaction (not the loan maintenance transaction) if you drill down on the alert.

Loan Maintenance

You can use loan maintenance to view the loan's amortization schedule and financial history as well as to change the terms of a loan, including the loan amount (prior to SA activation only), interest rate, payment amount and number of payment periods.

Note:

Starting Loans. You cannot start a loan from Loan - Main; you must use Start / Stop. Refer to How To Start A Loan Service Agreement for information.

Open Customer Information, Loan to maintain a loan.

Description of Page

The fields at the top of the page are informational only. The Payoff Balance is the total amount owed by the customer (excluding any interest that may have accrued since the last bill). The Current Balance is the amount currently owed by the customer. The Principal Balance is the total principal amount left unbilled. Refer to Payoff Balance and Current Balance for Loans for more information.

The Loan Amount is the amount originally loaned to the customer. The Standard Interest Rate is the standard interest rate defined on the loan's SA type. If the SA type allows, the standard interest rate may be overridden by a start option and/or manually. The Next Payment Amount is the effective periodic payment amount as of the next bill.

The Payment(s) shows the number of payments that were used to calculate the original loan schedule.

The Override Interest Rate grid is used to override the standard interest rate. The interest rate can only be modified if the loan's SA type allows it. Note that changing the interest rate changes the loan amortization schedule. To override the interest rate:

- Specify an End Date for the override rate in effect if there is one.

- Click + and specify the Start Date and the new Interest Rate. You can also specify the End Date of the new override rate, but this is not required.

The Payment Amount grid is used to maintain the effective periodic payment amount. Note that changing the payment amount changes the amortization schedule. To change the payment amount:

- Click + and specify the Effective Date and the new payment Amount.

Note:

Entering a payment amount that is too small. If you save a payment amount that is too small to cover the periodic interest charges, this causes negative amortization. The system is not able to recalculate the amortization schedule and bill segments are produced in error until the problem is corrected.

The History grid shows the loan's financial history in reverse chronological order. The financial history grid displays the following information:

- The Arrears Date is used to compute how many days old the debt is. In the context of a loan, debt only refers to the billed amount (the amount the customer needs to pay to stay current).

- 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 FT on the service agreement's current balance.

- Current Balance is the amount owed by the customer at the time of the transaction.

- Payoff Amount is the effect of the FT on the service agreement's payoff balance. The value is grayed out if it is the same as the current amount.

- Payoff Balance is the total amount owed by the customer. The value is grayed out if it is the same as the current balance.

Warning:

If you do not understand the difference between payoff balance and current balance, refer to Payoff Balance And Current Balance For Loans.

The Forecasted Schedule displays the loan amortization schedule. The first row of the schedule shows the current cumulative interest, current cumulative principal and the current principal balance. All other rows show the future amortization schedule based on the loan details. The forecasted schedule includes the following information:

- The Loan Period displays the forecasted payment period dates based on the billing frequency and the payment periodicity. The Loan Period is blank for the first row, which shows current cumulative amounts.

- The Amount displays the projected amount of that payment. The Amount is zero for the first row, which shows current cumulative amounts only.

- The Interest displays the projected amount of interest in the payment amount. The Amount is zero for the first row, which shows current cumulative amounts only.

- The Principal displays the projected amount of principal in the payment amount. The Amount is zero for the first row, which shows current cumulative amounts only.

- The Cumulative Interest is the total interest amount that would theoretically be billed at that loan period.

- The Cumulative Principal is the total principal amount that would theoretically be billed at that loan period.

- The Principal Balance is the remaining principal balance that would theoretically be remaining at the loan period.

Note:

Forecasted schedule. The loan schedule algorithm calculates the values in the forecasted schedule. Depending on the algorithm set up for your installation, the values may have a different meaning.

The Renegotiate Future Payments area allows you to change the terms of the loan. You can modify the following options:

- You can modify the Loan Amount only if the SA has not been activated. After the SA is activated, this field is for information only.

- The Interest Rate allows you to change the interest rate. When changing the interest rate, specify either the number of payment amounts or the payment amount and click Calculate to recalculate the amortization schedule.

- The Number of Payment Periods allows you to change the number of periods remaining in the loan's term. The Frequency displays the periodicity of the payments. If you change the number of payment periods, use the Calculate button to recalculate the payment amount.

- The Payment Amount allows you to change the amount of individual payments. If you change the payment amount, use the Calculate button to recalculate the number of periods.

- The Calculate button recalculates the payment amount (when you specify the interest rate and the number of payment periods) or the number of payment periods (when you specify the interest rate and the payment amount) and recomputes the loan amortization schedule based on these new terms.

Note:

Implementing New Loan Terms. The changes that you make using Override Interest Rate, Payment Amount and Renegotiate Future Payments do not take effect until you save the loan. Changes made to the Renegotiate Future Payments section are only valid for save after you click Calculate, and they override any other changes.

Saving Renegotiated Future Payments. When you save a loan that has renegotiated payments, the system may add new records for the override interest rate, payment amount, or both. It uses the start date of the next loan period as the start date of the new interest rate and/or as the effective date of the new payment amount. If the loan has not yet been billed, the system updates the interest rate and/or payment amount created when the loan was started.

How To

The topics in this section describe how to perform common loan functions.

Contents

How To Start A Loan Service Agreement

How To Modify The Terms Of A Loan

How To Adjust Loans

How To Stop A Loan Service Agreement

How To Start A Loan Service Agreement

Loan service agreements are created using start / stop just like all other service agreements. The start/stop transaction has special loan functionality that allows an operator to specify the service agreement-specific loan terms described above.

Creating a loan service agreement involves the following steps:

- Select the account on Control Central then open Start/Stop.

- Enter a Start Date and a Start Method of Start a SA .

- Indicate the CIS Division / SA Type of the loan service agreement and click the Start button.

- After you click Start, the Start Confirmation page appears. When you select a loan service agreement type, the Start Confirmation page displays special fields that allow you to specify the loan's terms.

- Select a loan Start Option. The start option includes the adjustment type for booking the principal amount, and can also include defaults for the initial loan amount, periodic payment amount, payment periods, and interest rate. The system uses the information on the start option to populate the service agreement's default parameters. You can manually override these parameters:

- • Enter the Loan Amount (the amount that the customer is borrowing). Note that the label for the Total Amount To Bill (e.g., Loan Amount) may appear differently depending on how the SA type was defined.

- • The system can automatically calculate either the payment amount (based on the loan amount and the payment periods) or the payment periods (based on the loan amount and the payment amount). Enter either the Payment Amount or the Payment Periods and click Calculate. Note that the label for the Recurring Charge (e.g., Payment Amount) may appear differently depending on how the SA type was defined.

- • Once the loan parameters are populated, click Start.

The loan is created in the pending start state. The next time the SA activation process runs, it will activate the loan SA. If you want to activate the loan immediately, navigate to the service agreement page and click Activate SA.

Note:

Overriding the Interest Rate. The Interest Rate is a display only field. The interest rate is taken from the value of the interest bill factor defined on the SA type or the contract value of the interest bill factor on the start option if one is defined. After starting a loan, you can manually override the interest rate using Loan - Main if the SA type allows it.

Changing The Loan Amount. You can use loan maintenance to change the loan amount for an SA as long as the SA has not yet been activated. It may be helpful to transfer to Loan - Main , and verify the amortization schedule before activating the SA.

How To Modify The Terms Of A Loan

After a loan is active, you may want to modify its terms. You can change number of payment periods, the payment amount, and the interest rate (if allowed by the SA type). To modify the terms of a loan:

- Navigate to the Loan maintenance page.

- If you used the account context menu, the loan you want to modify may be displayed. If not, use the search dialog that appears to search for and select the loan you want to modify.

- In the Renegotiate Future Payments section, change the interest rate (if allowed), the number of payments, or the payment amount. Note that either the number of payments or payment amount must be blank.

- Click Calculate. The Forecasted Schedule is recalculated along with either the new payment amount or the new number of payments (depending on which was left blank).

- If the renegotiated payments are satisfactory to the customer, save the changes.

When you save the changes, appropriate entries are made in the Override Interest Rate and Payment Amount grids.

Note:

Saving Loan Modifications. You must save the renegotiated payments after clicking Calculate for the loan modifications to be effective.

How To Adjust Loans

You issue ad hoc adjustments if you need to change a loan's principal and/or current balance outside of the normal billing and payment functions.

An adjustment can:

- Change a loan's payoff balance.

- Change a loan's current balance (i.e., how much the customer thinks they currently owe).

- Change both the loan's payoff and current balance.

Fastpath:

For details about the adjustment types to apply, refer to Adjusting Loan Amounts. For information about creating adjustments, refer to Adjustments.

How To Stop A Loan Service Agreement

Normally, a loan SA is automatically stopped when the bill segment for the last payment in the amortization schedule is generated for the loan (refer to Finalizing And Closing A Loan).

If a customer decides to payoff a loan before the term is complete, you can:

- Transfer to the SA maintenance page for the loan service agreement, specify an End Date for the loan, and click Save. This transitions the loan SA to pending stop .

Note:

End Date. The loan SA cannot be stopped until the specified end date is reached, so do not specify an end date that is in the future unless you do not want to stop the loan until that date.

Once the loan is in pending stop and the end date has been reached, the system transitions the loan SA to stopped . On the service agreement's normal bill cycle, the system final bills the SA for any outstanding balance plus accrued interest charges.

If you want to stop the loan and create the final bill immediately, complete these additional steps:

- On the loan's SA maintenance page, click the Stop SA button to transition the loan SA to stopped .

- Manually, create a bill for the loan service agreement. Remember that if you only want to generate a bill segment for a specific service agreement (e.g., the loan service agreement), transfer to the bill segment page. From there, you can generate and freeze a bill segment for a specific service agreement. When finished, return to the bill page and complete the bill.

When the customer pays the final bill, the loan SA is closed by the system.

Fastpath:

For more information about SA states, refer to The Lifecycle Of A Service Agreement.

Non-billed Budgets

A non-billed budget (NBB) is a payment plan used to level out a customer's payments over time. Non-billed budgets are typically used when your company bills on an infrequent basis and you want to provide your customers with a mechanism to make smaller payments more frequently. For example:

- Rather than receive a bill once a quarter, a customer could set up an non-billed budget to pay fortnightly

- Rather than pay two large bills a year, the customer could set up an non-billed budget to pay 10 out of 12 months (sparing themselves during the holiday season)

Non-billed budgets can cover one or more service agreements linked to the same account. You can have multiple active non-billed budgets for an account, but any given service agreement can only be covered by a single non-billed budget at any point in time.

Note:

Non-billed budgets are optional. The business processes described in this section are only relevant if your organization offers non-billed budgets to its customers.

Fastpath:

For information about setting up non-billed budget functionality for your system, refer to Defining Non-billed Budget Options.

Contents

The Big Picture Of Non-billed Budgets

Maintaining Non-billed Budgets

How To

The Big Picture Of Non-billed Budgets

The following topics provide background information about non-billed budgets.

Contents

Non-billed Budget Service Agreements

Which SAs Are Covered By A Non-billed Budget?

Non-billed Budgets Versus Other Plans For Payment

There Are Two Types Of Non-billed Budgets

Navigating To The Non-billed Budget Maintenance Page

Recommending Scheduled Payments

Non-billed Budget Service Agreements

Non-billed budgets are initiated by creating a non-billed budget service agreement for a customer. The non-billed budget SA and its SA type maintain the details of the non-billed budget, such as recommendation rules, covered SAs, scheduled payments and credit balance. Non-billed budgets are just like other service agreements in some ways:

- Non-billed budgets have a current and a payoff balance.

- If the customer doesn't pay a monitored non-billed budget, credit & collections may start a collection process to encourage the customer to pay (depending upon how the debt class has been set up on your system).

Non-billed budgets differ from other service agreements in the following ways:

- Non-billed budgets have a special role of non-billed budget.

- Non-billed budgets have scheduled payments.

- Non-billed budgets maintain a list of covered SAs (utility and other service agreements to which the non-billed budget applies)

- Non-billed budgets are started and maintained on a separate transaction (refer to Non-billed Budget - Main for more information).

Which SAs Are Covered By A Non-billed Budget?

A non-billed budget can apply towards one or more of the account's billable SAs whose SA type is flagged as Eligible for Non-billed Budget . SAs can be added to or removed from a non-billed budget at any time. Additionally, an SA can be linked to more than one non-billed budget as long as the non-billed budgets to which it is linked do not have overlapping start and end dates.

A list of the SAs covered by a non-billed budget is maintained with the non-billed budget SA. This list is used at bill completion to determine the financial transactions that should occur.

Non-billed Budgets Versus Other Plans For Payment

Unlike a regular budget but like a payment plan, a non-billed budget has one or more scheduled payments. However, unlike payment plans, bills are not produced for the scheduled payment amounts. Instead, customers are simply notified of the payment schedule and it is their responsibility to make the scheduled payments. In general, the following statements highlight the differences between non-billed budgets and other payment plans.

- There is a payment schedule that is not dependent on billing, unlike budget plans.

- Non-billed budgets are not limited to SAs of a single debt class, unlike pay plans.

- Debt is not transferred from regular SAs to the non-billed budgets, unlike payment arrangements.

Warning:

Non-billed Budgets and Budget Plans! An SA should not be on a non-billed budget if it is on a budget plan . A non-billed budget overrides any budget functionality in most cases. However, placing an SA that is on a budget on a non-billed budget may result in indeterminate results. For example, when the non-billed budget is broken, the stop algorithm for the non-billed budget syncs current and payoff balances for those utility SAs that were covered by the non-billed budget.

There Are Two Types Of Non-billed Budgets

There are two types of non-billed budgets: monitored and unmonitored. As the terms suggest, the difference between monitored and unmonitored non-billed budgets is whether they are monitored by the account debt monitor. However, this also means that monitored and unmonitored non-billed budgets receive different financial treatment by the system.

In general, monitored non-billed budgets have their current balances monitored by the account debt monitor while the current balances of any covered SAs are zero (and therefore don't violate any debt collection criteria). With monitored non-billed budgets, customers make required prepayments that are applied towards their utility bills (until the non-billed budget is stopped). They are responsible for making sure the payments on their non-billed budget are up to date, but they do not have to payoff any balances on covered SAs.

Unmonitored non-billed budgets do not have their current balances monitored by the account debt monitor while the current balances of any covered SAs are maintained and therefore subject to the account debt monitor. When customers are set up on an unmonitored non-billed budget, the payments that they make towards the budget are optional. They are, however, financially responsible for paying the current balances of any covered SAs.

Fastpath:

Refer to Financial Transactions For Unmonitored Non-billed Budgets for detailed information about the financial differences between monitored and unmonitored non-billed budgets.

Note:

SA Type Determines Monitored Status. The SA type that you select when setting up a non-billed budget determines whether it is monitored or unmonitored (i.e., it's a setting on the SA type). Your company may choose to implement only monitored non-billed budgets, only unmonitored non-billed budgets, or both.

Navigating To The Non-billed Budget Maintenance Page

Any of the following methods can be used to navigate to the Non-billed Budget Maintenance transaction:

- An alert in the Alert Zone highlights if a non-billed budget exists for the current account. You are transferred to the non-billed budget transaction if you drill down on the alert.

- You can setup an order's campaign to automatically transfer a user to the non-billed budget transaction whenever an order is completed for a given SA. This might be useful for campaigns that are associated with services that are typically on a non-billed budget.

- A user can setup a favorite link associated with the non-billed budget transaction.

- Via any of the following menus:

- Account context menu

- Service agreement context menu

- Main menu

Recommending Scheduled Payments

When creating a non-billed budget, 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 non-billed budget 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 customer.

Fastpath:

Refer to Designing Recommendation Rules for more information.

Maintaining Non-billed Budgets

Non-billed budget service agreements are started and maintained on a different transaction than other SAs. The topics in this section explain how to start and maintain non-billed budgets.

Contents

Non-billed Budget - Main

Non-billed Budget - History

Non-billed Budget - Main

The Main page contains basic information about the non-billed budget. Open Customer Information, Non-billed Budget to maintain this information.

Description of Page

Non-billed Budget SA (service agreement) information and SA ID are displayed on each page. These values only appear after the service agreement exists on the database. The SA ID is a system assigned random number that stays with a service agreement for life. The Non-billed Budget SA information is a concatenation of important details about the service agreement and its account.

The Account ID is identification of the account that is financially responsible for the service agreement.

Indicate the CIS Division and SA Type. These fields control aspects of the service agreement's behavior, such as whether the non-billed budget is monitored or unmonitored. These fields are gray when the status is not Pending Start .

Fastpath:

For more information about non-billed budget SA types, refer to Defining Non-billed Budget Options .

If Scheduled Payment Auto Pay is Included in Auto Payand 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.

Recommendation Rule is used to create a recommended payment amount and payment schedule. The SA type controls which recommendation rules are allowed for the non-billed budget SA.

Current Balance indicates the amount the customer currently owes on the non-billed budget. If the non-billed budget is unmonitored, the current balance is always zero.

Payoff Balance displays the total amount the customer would owe if they wanted to close the service agreement. For non-billed budgets, the payoff balance typically represents an accumulated credit that has not yet been distributed to the covered SAs (at bill completion time or when the non-billed budget is stopped).

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 Expiration Date is the date on which the SA expires. The Renewal Date is the date on which the SA is scheduled to be renewed by the SA renewal background process. If the SA is not renewed by the expiration date, the stop process is initiated.

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 payment schedule algorithm type controls the number and type of parameters. The recommendation rule controls the default values and whether they can be overridden.

The Covered Service Agreements grid lists the utility and other SAs that are on the non-billed budget. You must create the list of covered SAs before the recommendation rule can recommend a payment amount and list of scheduled payments. The grid displays the SA ID, SA Information, Current Balance and Payoff Balance for covered SAs.

The scheduled payments grid displays the scheduled payments created by the recommendation rule (after you click the Recommend NBB 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.

Fastpath:

Refer to Scheduled And Actual Payments On The Non-billed Budget for more information on what occurs when the base non-billed budget scheduled payment background process processes scheduled payments that are due.

In the Action grid:

- Click Recommend to create a recommended payment schedule based on the recommendation rule.

- Click Renew to manually renew the non-billed budget. This executes the SA renewal algorithm for the SA type and returns new renewal and expiration dates for the SA.

- Click Break to manually cancel the non-billed budget. This executes the break non-billed budget algorithm defined for the SA type, and changes the status of the SA to pending stop .

Non-billed Budget - History

The Financial History page displays the non-billed budget's historical financial transactions. Open Customer Information, Non-billed Budget and navigate to the History tab to view this information.

Description of Page

Non-billed Budget SA (service agreement) information and SA ID are displayed on each page. These values only appear after the service agreement exists on the database. The SA ID is a system assigned random number that stays with a service agreement for life. The Non-billed Budget SA information is a concatenation of important details about the service agreement and its account.

The Account ID identifies who is financially responsible for the service agreement.

The grid shows the non-billed budget's financial history in reverse chronological order, including:

- The Arrears Date is used to compute how many days old the debt is. For monitored non-billed budgets, debt refers to the scheduled payment amounts (i.e., the customer only owes the scheduled payment amounts up to the most recent scheduled payment date). The arrears date for a schedule payment is the scheduled payment date.

- 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 FT on the service agreement's current balance.

- Current Balance is the amount owed by the customer at the time of the transaction.

How To

The topics in this section describe how to perform common non-billed budget functions.

Contents

How To Start A Non-billed Budget Service Agreement

How To Cancel / Stop Non-billed Budget SAs

How To Renew Non-billed Budgets

How To Set Up Automatic Payment For A Non-billed Budget

How To Start A Non-billed Budget Service Agreement

To set up a new non-billed budget:

- Navigate to the Non-billed Budget maintenance page.

- If the account is not already specified, select the Account for which you want to start the non-billed budget.

- Define the CIS Division and SA Type to use for the non-billed budget service agreement.

- 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 customer.

- Verify the list of Covered Service Agreements. All the account's SAs that are eligible for non-billed budget are listed. Click to remove unwanted SAs from the list.

- Click Recommend.

- On the pop-up dialog, specify the Schedule Start Date and click Recommend.

- Make any necessary changes to the expiration date, renewal date and scheduled payments grid and click Save.

How To Cancel / Stop Non-billed Budget SAs

To stop a non-billed budget:

- Navigate to the Non-billed Budget maintenance page.

- If the account with the non-billed budget you want to stop is not specified, select the Account of the non-billed budget you want to stop.

- If the account has more than one non-billed budget SA, select the non-billed budget you want to stop.

- Click Break.

How To Renew Non-billed Budgets

Most non-billed budgets are renewed automatically by a background process. However, you may manually renew non-billed budgets that are eligible for renewal if desired.

To renew a non-billed budget:

- Navigate to the Non-billed Budget maintenance page.

- If the account with the non-billed budget you want to renew, select the Account of the non-billed budget you want to stop.

- If the account has more than one non-billed budget SA, select the non-billed budget you want to renew.

- If desired, change the recommendation rule or any of the parameters.

- Click Renew.

The new expiration and renewal dates are calculated and the new payment schedule is appended to the list of scheduled payments.

How To Set Up Automatic Payment For A Non-billed Budget

If a customer wants to pay their non-billed budget scheduled payments automatically:

- Set up the account for automatic payment (as described under How To Set Up A Customer To Pay Automatically).

- Navigate to the Non-billed Budget Maintenance page and select the non-billed budget for the account.

- Set the Scheduled Payment Auto Pay field to indicate that the scheduled payments are Included in Auto Pay .

Asset Inventory

In addition to maintaining a simple list of your meters and items, you may want to keep track of their locations when they are not installed at a service point. The topics in this section describe how you set up stock locations and manage your asset inventory.

Note:

Asset. We use the term "asset" to refer to both meters and items in the following discussion.

Equipment is not tracked. The functionality provided for tracking items that are installed at a service point are specifically referring to items that are linked to the service point via SP / item installation. Items that are linked to service points as equipment are not included in this functionality.

Contents

The Big Picture Of Asset Inventory

Setting Up Asset Inventory Options

Maintaining Stock Locations

Maintaining Stock Location Inventory

The Big Picture Of Asset Inventory

The topics in this section provide background information about keeping track of the stock locations at which meters and items are located when they aren't installed at a service point.

Contents

The Big Picture Of Stock Locations

Stock Location History Is Created Behind The Scenes

A User May Manually Change An Asset's Stock Location

Viewing What Is At A Stock Location

Viewing Where An Asset Is / Was

How To Handle A Shipment Of New Assets

How To Transfer Assets To Another Location

The Big Picture Of Stock Locations

There are two types of stock locations:

Inventory stock location. An inventory stock location is one at which an asset can reside when it's not installed at a service point.

Parent location. Stock locations that are used to organize inventory locations are called "parent" stock locations. You would create parent locations to provide a hierarchical perspective as to the location of your assets.

For example, assume you have a large warehouse with many different logical areas in which assets can be stored. You could create an inventory stock location for each specific shelf / storage area in the warehouse and then group all of these inventory locations under a parent location (where the parent location would be the "large warehouse").

Parent locations are not necessary. Parent locations are only needed if you want to view stock locations in a hierarchy on the Stock Location Inventory page.

Stock Location History Is Created Behind The Scenes

An asset's stock location history is only maintained if the asset's respective meter type / item type indicates that stock location history is maintained. If stock location is tracked, the system will create stock location history records in the following situations:

- Whenever an asset is installed at a service point, a stock location history record is stored. The stock location is blank on such a record (because the asset is installed at a service point).

- Whenever an asset is removed from a service point, an "installation" stock location history record is stored. The default stock location into which a removed asset is placed is defined on Postal Code Default - Service Defaults .

- Whenever a meter or item is replicated, the operator must indicate the stock location at which the replicated meters / items reside. Refer to Meter Replicator and Item Replicator for more information.

Note:

If location tracking for an item type or meter type is turned off and then subsequently turned on again, any change in the location of the item / meter during the period in which location tracking is off will not be recorded. This will result in gaps in the asset's location history.

A User May Manually Change An Asset's Stock Location

Stock Location History Is Created Behind The Scenes most of the time. However, the following points describe situations that will cause an operator to manually change an asset's stock location.

- If an asset is not installed at a service point, an operator may change its current stock location using either Meter - Location History or Item - Location History . This would typically be done when an asset is transferred to a different stock location.

- Whenever a new meter / item is initially added, the operator must indicate the stock location at which the meter / item resides. This is done using either Meter - Location History or Item - Location History .

Viewing What Is At A Stock Location

You can view all assets at a stock location using Stock Location Inventory .

Viewing Where An Asset Is / Was

You can use Meter - Location History and Item - Location History to view the history of the service points and stock locations at which an asset has been located. It's important to be aware that you may only view this history if the asset's meter type / item type indicates that the inventory location is tracked.

How To Handle A Shipment Of New Assets

If you receive a shipment of new items, follow the following steps:

- Create a new item for each type of item that's received. These items serve as the "templates".

- Go to the Item Replicator to create multiple copies of the template item(s). Before you are allowed to replicate the new item, you must define the stock location at which the items will be stored.

If you receive a shipment of new meters, follow the following steps:

- Create a new meter for each type of item that's received. These meters serve as the "templates".

- Add a meter configuration for each template meter using Meter Configuration Maintenance .

- Go to the Meter Replicator to create multiple copies of the template meter(s). Before you are allowed to replicate the new meter, you must define the stock location at which the meters will be stored.

How To Transfer Assets To Another Location

To move assets from one stock location to another, perform the following steps:

- Navigate to either Stock Location Inventory - Item Inventory or the Stock Location Inventory - Meter Inventory as appropriate and select the stock location where the assets that you want to transfer are located.

- Display the items / meters that you want to transfer using the filters and pressing the search button.

- Select the items / meters that you want to transfer.

- Click on the Transfer Location button. The Transfer Stock Location window opens.

- Specify the Stock Location where you want to transfer the assets to and enter the effective date/time of the transfer in Location Date/Time. Click on the Transfer button to perform the transfer.

Setting Up Asset Inventory Options

This section describes tables that must be set up before you can associate meters / items with inventory locations.

Contents

Setting Up Postal Defaults

Turn On Stock Location Tracking On Your Meter Types / Item Types

Setting Up Postal Defaults

On Postal Code Default , define the respective stock location into which a meter / item will be placed by default when its removed from a service point. Refer to Stock Location History Is Created Behind The Scenes for more information.

Turn On Stock Location Tracking On Your Meter Types / Item Types

Enable stock location tracking for the meter types / item types whose stock location is to be tracked in the system.

Maintaining Stock Locations

Every meter / item whose meter type / item type indicates that its stock location is tracked resides at a stock location. The topics in this section describe how to maintain your stock locations.

Contents

Stock Location - Main

Stock Location - Characteristics

Stock Location - Main

Open this page using Meter, Stock Location and then navigate to the Main tab.

Description of Page

A stock location is a physical or logical location at which meters / items are stored while they are not installed at a service point. Refer to The Big Picture Of Stock Locations for more information.

Enter a unique ID and a Description for each Stock Location.

Indicate that this stock location is Allowed to Hold Inventory if it is one at which meters and items can be stored. Otherwise, indicate that it is Not Allowed .

Note:

Hold Inventory is typically Not Allowed on "notional" stock locations used to group together detailed stock locations. You can view a stock location's subsidiary locations in the tree at the bottom of this page.

If the Stock Location is subsidiary to a higher-level stock location, define its immediate Parent Stock Location. Refer to The Big Picture Of Stock Locations for more information about parent locations.

Enter any Comments about the stock location.

The tree at the bottom of the page shows the hierarchy of stock locations associated with the Stock Location selected in the search.

Where Used

Stock location history records reference a stock location. Refer to Stock Location History Is Created Behind The Scenes for more information.

Stock Location - Characteristics

The characteristics page contains information that describes miscellaneous information about the stock location. Open this page using Meter, Stock Location and then navigate to the Characteristics tab.

Description of Page

Use the Characteristics collection to define miscellaneous information to be kept for stock locations. For example, a premise ID can be specified as a characteristic to identify the address of a stock location.

Note:

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

To modify a characteristic, simply move to a field and change its value. To add a new characteristic, click + to insert a row, then fill in the information for each field. 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.

Maintaining Stock Location Inventory

The topics in this section describe how to view and maintain the contents of a given stock location.

Refer to The Big Picture Of Asset Inventory for more information.

Contents

Stock Location Inventory - Main

Stock Location Inventory - Item Inventory

Stock Location Inventory - Meter Inventory

Stock Location Inventory - Main

This page contains a tree that shows:

- A summary of the number of items and meters located at a stock location (that can hold inventory).

Refer to The Big Picture Of Asset Inventory for more information.

Open this page using Meter, Stock Location Inventory and then navigate to the Main tab.

Description of Page

This page contains a tree that shows a summary of the types of meters and items stored at the location. Refer to The Big Picture Of Stock Locations for more information.

If you click an Item Count node, you will be transferred to the Stock Location Inventory - Item Inventory page where you can see the details of the individual items of a given type located at the Stock Location.

If you click on a Meter Count node, you will be transferred to the Stock Location Inventory - Meter Inventory page where you can see the details of the individual meters of a given type located at the Stock Location.

Stock Location Inventory - Item Inventory

This page is used to display the individual items of a given type that are stored at a stock location. Refer to The Big Picture Of Asset Inventory for more information.

Open this page using Meter, Stock Location Inventory and then navigate to the Item Inventory tab.

Description of Page

This page displays the individual items that are stored at a Stock Location as at a given Date/Time.

The easiest way to display inventory for a given Item Type at a Stock Location is to navigate to the Stock Location Inventory - Main tab and find the Stock Location. Then, click on an Item Count line.

You can restrict the list using the following filter options:

- Use the Item Type filter to restrict the meters to those of the given meter type.

- Use the Badge Number filter to restrict the list to meters that have a badge number beginning with or matching this value.

Don't forget to click the search button after changing the filters.

The Select All / Clear All buttons are used to select items to be transferred to another stock location. These buttons are enabled if at least one item is displayed in the grid.

The grid contains the item inventory at the selected stock location on the given date/time that match your filter criteria. The following information is displayed in the grid:

- Select box. Use this checkbox to select items that you want to transfer to another stock location. This checkbox is enabled if the item is currently stored at this location and location is tracked for the item's item type. Refer to How to Transfer Assets To Another Location for more information.

- The description of the item's Item Type.

- The item's Badge Number.

- The item's Serial Number.

- The Manufacturer/ Model of the item.

- The Location Date/Time when the item was added to this stock location.

- If the item was subsequently removed from this stock location, the Subsequent Location column shows either the stock location it was transferred to or the service point it was installed at.

Pressing the Transfer Location button enables you to transfer the selected items to another stock location. This button is enabled if at least one meter in the grid is selected. Refer to How to Transfer Assets To Another Location .

Stock Location Inventory - Meter Inventory

This page is used to display the individual meters of a given type that are stored at a stock location. Refer to The Big Picture Of Asset Inventory for more information.

Open this page using Meter, Stock Location Inventory and then navigate to the Meter Inventory tab.

Description of Page

This page displays the individual meters that are stored at a Stock Location as at a given Date/Time.

The easiest way to display inventory for a given Meter Type at a Stock Location is to navigate to the Stock Location Inventory - Main tab and find the Stock Location. Then, click on a Meter Count line.

You can restrict the list using the following filter options:

- Use the Meter Type filter to restrict the meters to those of the given meter type.

- Use the Badge Number filter to restrict the list to meters that have a badge number beginning with or matching this value.

Don't forget to click the search button after changing the filters.

The Select All / Clear All buttons are used to select meters to be transferred to another stock location. These buttons are enabled if at least one meter is displayed in the grid.

The grid contains the meter inventory at the selected stock location on the given date/time that match your filter criteria. The following information is displayed in the grid:

- Select box. Use this checkbox to select meters that you want to transfer to another stock location. This checkbox is enabled if the meter is currently stored at this location and location is tracked for the meter's meter type. Refer to How to Transfer Assets To Another Location for more information.

- The description of the meter's Meter Type.

- The meter's Badge Number.

- The meter's Serial Number.

- The Manufacturer/ Model of the meter.

- The Location Date/Time when the meter was added to this stock location.

- If the meter was subsequently removed from this stock location, the Subsequent Location column shows either the stock location it was transferred to or the service point it was installed at.

Pressing the Transfer Location button enables you to transfer the selected meters to another stock location. This button is enabled if at least one meter in the grid is selected. Refer to How to Transfer Assets To Another Location for more information.

Case Management

Note:

Separate module. Please note that the Case Management functionality is associated with a separate Case Management module. If this module is not applicable to your business you may turn it off. Refer to Turn Off A Function Module for more information.

Your organization can use case management functionality to manage a variety of situations, such as:

- a high-bill complaint,

- a bankruptcy,

- an inspection of a premise,

- a customer's request for literature,

- a contractor's request to extend a line,

- a customer's rejection of a quote,

- a customer's request to change information on a future date,

- the processing of a market message in a deregulated environment

Note:

Your implementation controls how your cases behave. Since virtually all aspects of case management functionality are controlled by your implementation, you can use it to handle a myriad of business requirements. Refer to Defining Case Management Options for the details.

Contents

Background Topics

Maintaining Cases

Background Topics

The topics in this section provide background information about case management functionality.

Contents

Case Type

Creating Cases

Log Information

Alerts

To Do's and Cases

Reports

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 premise 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 management page in add mode, select the appropriate case type, fill in the other necessary fields, and click save. Oracle Utilities Customer Care and Billing also includes scripts that can help create cases. Refer to Scripts and Cases for more information.

You can also develop plug-ins and user exits to so that the system will create cases when specific events take place. For example, you could set the system to create a case when an umbrella agreement is ready for renewal or when a quote is created.

Please refer to Maintaining Cases for a detailed description of the case page and field descriptions.

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.

Refer to Case Statistics for a Given Status for information about a report that uses the log to provide productivity statistics.

Alerts

The alert zone will highlight if the person / account / premise 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.

Reports

Several reports summarize case information. Refer to the Reports chapter for the details.

Maintaining Cases

Your organization can use the case management functionality to manage a variety of situations, such as:

- a high-bill complaint,

- a bankruptcy,

- an inspection of a premise,

- a customer's request for literature,

- a contractor's request to extend a line,

- a customer's rejection of a quote,

- a customer's request to change information on a future date,

- the processing of a market message in a deregulated environment

Note:

Since an implementation can configure virtually every aspect of a case, the look and feel of the case management page are dynamic based on how case types have been configured.

Contents

Case - Main

Case - Case Portal

Case - Log

Case - Main

Open the case management page by selecting Customer Information, Case from the main menu.

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.

Note:

Formatting may be performed by a plug-in. Refer to Case Info May Be Formatted By An Algorithm for more information.

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 in the Auto-transition Message Area. Refer to Automatic Transition Rules for more information.

Note:

The Auto-transition Message Area 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 Comments 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.

Premise references the premise associated with this case. This field is suppressed if the Case Type indicates that a premise 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 Premise 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. Refer to Where Does The Address Come From for a description of which address the system displays.

- SMS. If this method is selected, the Contact Person's short message service (SMS) information displays.

Contact Instructionsindicates any special instructions indicated for when or how to return a call.

Callback Phone Type,Callback Phone Number, andExtensionindicate 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 by selecting Customer Information, Case from the main menu and then 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 market message), 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 Customer Information, Case from the main menu and then 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.

Premise Management

Note:

Separate module. Please note that the Premise Management functionality is associated with a separate Premise Management module. If this module is not applicable to your business you may turn it off. Refer to Turn Off A Function Module for more information.

The premise management functionality facilitates the following:

- Grouping premises together under a single parent premise

- Quick & efficient setup and maintenance of apartment complexes and high-rises

- A single view of properties for a landlord, including service status

- Ability to change the landlord or service status for a group of premises in one transaction

- And more...

The topics in this section describe premise management functionality.

Contents

Overview

Premise Management Page

Overview

The topics in this section provide background information about premise management functionality.

Contents

Define Premise Hierarchy

Manage Premises for a Landlord

Manage Groups of Premises

Define Premise Hierarchy

Premise management allows you to define premise 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 premise for each level in the hierarchy and for each "child" premise, indicate its appropriate parent premise. Once you have set up your premise hierarchies, you may view the hierarchies on trees on the premise page and on the control central premise tree.

In addition, the system provides the following alerts:

- When viewing a parent premise, an alert indicates how many child premises exist

- When viewing a child premise, an alert indicates that it is linked to a parent premise.

Manage Premises for a Landlord

The premise management page provides the ability to view all the premises for the landlord along with information about the accounts linked to each premise.

You may use this page to assign, change or remove the landlord agreement for multiple premises in a single action. For example if a landlord sells his properties to another person, this page facilitates updating all premises with one action rather than changing the landlord for each premise separately. For example, if the landlord sells only a portion of his properties.

This page may also be used to start or stop service for one or more premises for the landlord. For example, a landlord plans to sell a high-rise apartment complex with 100 apartments. Imagine that 8 of these apartments are vacant and the landlord's account is currently paying for any usage to these apartments. In addition to changing the landlord agreement for all 100 apartments to the new landlord, the service for the vacant apartments should be transferred to the new landlord. A user can go to premise management, use the search criteria to view all premises for this landlord in a given apartment complex whose service is currently being paid for by the landlord and start service for these premise for the new landlord. (Using the back-to-back start/stop functionality, service will be stopped for the old landlord.)

Manage Groups of Premises

The powerful search criteria on the premise management page allows you to view different groups of premises based on any combination of account information, landlord information, parent premise address information and general geographic type information. You may also define search criteria such as "premises not linked to account 1234567890" or "premises linked to any landlord" or "premises not linked to any parent premise". For example, you could display all premises in a given latitude / longitude that are not linked to any parent premise.

Once your search results display the desired list of premises, you could perform mass updates such as assigning a parent premise or starting service. Following are examples of situations where this page would be helpful:

- The developer of a high-rise condominium complex is ready to start service for a group of condos. A user uses the premise management search criteria to display the premises linked to a give parent premise (representing the condo complex) that are not linked to any account. The user selects the premises in this list that the developer would like to start and starts service for all premises at once.

- There is a shopping mall in your service territory and each store in an individual premise. You may decide to define a parent premise for the entire shopping mall and link each store's premise to the parent. Once the parent premise is defined, a user navigates to the premise management page and displays the individual premises based on a similar address or based on a similar geographic type. The user then assigns the parent premise for all the individual premises using a single action.

Premise Management Page

This page allows you to display a list of premises using a combination of search criteria. In addition, you can perform actions on one or more of the resulting premises, including:

- Assigning a parent premise to one or more premises

- Removing the link to a parent premise from one or more premises

- Assigning a landlord to one or more premises

- Removing the link to a landlord from one or more premises

- Start service for one or more premises

- Stop service for one or more premises

Open this page using Customer Information, Premise Management.

Description of Page

The top half of the page is where you enter the criteria used to search for premises.

Note:

Multiple search criteria may be specified. You can search for premises using a combination of search criteria. For example, if you enter both a Parent Premise Filter of Linked To Any Premise and an Account Filter of Not Linked to Any Account ; only those premises that have a parent premise but are not linked to an account will be displayed.

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

Landlord Filter

Use this filter to narrow down your search based on landlord. Enter one of the following values:

Not Applicable

Linked To This Landlord - for this option, you must enter a Landlord Agreement

Not Linked To This Landlord - for this option, you must enter a Landlord Agreement

Linked To Any Landlord

Not Linked To Any Landlord .

A filter value of Not Applicable defaults.

Parent Premise Filter

Use this filter to narrow down your search based on parent premise. Enter one of the following values:

Not Applicable

Linked To This Parent Premise - for this option, you must enter a Premise ID for the parent premise

Not Linked To This Parent Premise - for this option, you must enter a Premise ID for the parent premise

Linked To Any Parent Premise

Not Linked To Any Parent Premise .

A filter value of Not Applicable defaults.

Account Filter

Use this filter to narrow down your search based on account. Enter one of the following values:

Not Applicable

Linked To This Account - for this option, you must enter an Account ID

Not Linked To This Account - for this option, you must enter an Account ID

Linked To Any Account

Not Linked To Any Account .

A filter value of Not Applicable defaults.

Premise 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 Premise - for this option, you must enter a Premise ID

A filter value of Not Applicable defaults.

The Select All / Clear All buttons are used to select premises 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 premises at a time. Clicking Select All selects the first 50 premises in the grid. If more than 50 premises exist, you must select them in batches.

The grid that follows contains the premises that match your search criteria. The following information appears in the grid:

- Select box. Use this checkbox to select premises for mass update actions.

- The Premise Information column shows information about each premise. Click the hyperlink to transfer to the Premise page where you can update information about the premise in question.

- The Account Information column shows information about all accounts linked to the premise, if any. Only accounts with non-canceled, non-closed service agreements linked to this premise are displayed. The column displays the name of the customer's main person followed by a list of status values for any of the account's service agreements linked to this premise. For example, you may see Customer A (pending stop) , Customer B (pending start) . If multiple service agreements linked to the account & premise have the same status, the status is only displayed once.

- The Parent Premise Information column displays information about the premise's parent premise, if one exists.

- The Landlord Information column displays the landlord agreement description for the premise's landlord, if there is one.

This transaction has sophisticated logic that can be used to perform "mass updates" to the premises 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 premise grid. The following points describe these mass update actions:

Contents

Start Service

Stop Service

Assign Parent Premise

Remove Parent Premise

Assign Landlord

Remove Landlord

Start Service

The Start Service button is used to start service for one or more premises. When clicked, the Start SA Groups Confirmation window opens.

Note:

Similar to Start/Stop. This page is similar to the Start SA Confirmation page that appears on start/stop. The differences are to accommodate starting multiple premises.

In order to start service for the selected premises, select the Account ID.

The Start Date is the date on which the service is scheduled to start.

Use Start Requested By to indicate the name of the person who requested the start.

Check Include Child Premises if all the child premises in the hierarchy below the selected premises should also be started for this account.

Click Show SA Groups to populate the remainder of the page.

The Service Points section summarizes the service points that exist for all the chosen premises. A row is displayed for each different SP Type along with a Count of the number of service points of that type. By default, all rows are checked, assuming that you want to start service for all service points (and the SA Groups To Start scroll below displays proposed SAs to start for each SP type). You may uncheck any SP Type row if you do not wish to start service for that SP type. Click Show SA Groups to rebuild the SA Groups To Start information.

Warning:

This page displays summary information about the service agreements and service points that are being turned on. It is recommended that you start groups of premises that have similar service point configurations. If you attempt to start service for many premises, each with different service point configurations, the start logic may be very complicated to verify on this page.

The SA Groups To Start scroll contains an entry for every service agreement that will be created if you click the Start button. If you do not want a service agreement to be created, click the - button or uncheck Start this SA Group. If you would like to start service agreements that are not SP-based service agreements (for example a deposit or a connection charge), click the + button to add a new SA group. The system assumes that you want to create a new service agreement for each selected premise.

Turn on the Start this SA Group switch if you want service agreements of this type to be created. If this is the first customer at the selected premises, this switch is checked for all service agreements that appear in the scroll. For each premise that was linked to a previous customer, this switch is on only for those types of service agreements used by the previous customer(s). (We assume the new customers only want the services used by the previous customers). Service agreements that are possible, but were not used by the previous customers, appear in the scroll with this switch turned off.

If Start This SA Group is checked, the system displays a message indicating the number of service agreements (for the number of service points) that will be created if you choose Start.

For a description of the remaining fields, refer to Start/Stop - Start Confirmation.

Click Start. Standard start logic is followed when clicking start.

Note:

The start button is disabled if changes are made to fields on the page that may impact the SA Groups To Start collection. You must click Show SA Groups to rebuild the SA groups and enable the start button.

Stop Service

The Stop Service button is used to stop service for one or more premises.

Note:

that this functionality stops service for any account linked to the selected premises. If you want to stop service at the selected premises for only certain accounts, use the account filter criteria to narrow down the selection of premises prior to clicking Stop Service.

When clicked, the Stop SA Group Confirmation window opens.

In order to stop service for the selected premises, enter a Stop Date.

Enter a Restrict to Account if you want to stop only service agreements linked to this account. If not specified, all active services agreements for the premise are stopped regardless of the account.

Use Stop Requested By to indicate the name of the person who requested the stop.

Check Include Child Premises if the child premises in the hierarchy below the selected premises should also be stopped.

Click Show SA Groups to populate the remainder of the page.

The system builds a collection of service agreements currently linked to the service points for the selected premises. The grid contains the CIS Division and SA Type for each SA "group" and displays the number of service agreements in the SA Group Summary.

By default, the system checks each SA group assuming that you want to stop service for all SAs. You may uncheck any of the SA groups to not stop service for those SAs.

Click Stop. Standard stop logic is followed when clicking stop.

Note:

The stop button is disabled if changes are made to fields on the page that may impact the SA collection. You must click Show SA Groups to rebuild the SA collection and enable the stop button.

Assign Parent Premise

The Assign Parent Premise button is used to assign a parent premise to one or more premises. When clicked, the Assign Parent Premise window opens.

Specify the Parent Premise ID and click Assign.

Remove Parent Premise

The Remove Parent Premise button is used to remove the parent premise from one or more premises. When clicked, the parent premise ID of all selected premises is reset.

Assign Landlord

The Assign Landlord button is used to assign a landlord to one or more premises. When clicked, the Assign Landlord window opens.

Specify the Landlord agreement ID.

Check Include Child Premises if the child premises in the hierarchy below the selected premises should also be assigned this landlord.

Click Assign.

Remove Landlord

The Remove Landlord button is used to remove the landlord agreement from one or more premises. When clicked, the Remove Landlord window opens.

Check Include Child Premises if all the child premises in the hierarchy below the selected premises should also have their landlord agreement removed.

Click Remove.

Umbrella Agreement Management

Your organization may use umbrella agreement functionality to manage many situations, including (but not limited to) the following:

- Creating a "negotiated contract" with a large customer with many sites.

- Creating a "negotiated contract" with all customers in a common geographic area, for example a specific city or an apartment complex

- Grouping and managing the proposal service agreements created during the quoting process

- Managing the renewal process for special contracts

- Applying override rate terms to one or more service agreements for a given effective period

- more...

Note:

Separate module. Please note that the umbrella agreement functionality is part of the Contract Management module. If this module is not applicable to your business you may turn it off. Refer to Turn Off A Function Module for more information.

Contents

Overview Of Umbrella Agreement & Terms Of Service

Umbrella Agreements & Quotes

Additional Umbrella Agreement Topics

Umbrella Agreement Maintenance

Terms Of Service Maintenance

Overview Of Umbrella Agreement & Terms Of Service

An umbrella agreement is used to group together terms for a contract. It contains high level information about the contract such as the effective dates, the renewal date, if applicable and an account management group, if applicable. You may also define characteristics and contacts for the umbrella agreement.

The terms of the umbrella agreement are defined using one or more terms of service (TOS) records. For each TOS record, you must link one or more service agreements to indicate the services covered under the TOS.

The Terms of Service may point to a 'template service agreement' as a way to specify the rating terms and conditions to be used by all service agreements linked to the TOS. If a TOS does not define a template SA, then the TOS is used largely as a grouping mechanism rather than a billing mechanism.

Umbrella agreements and their terms of service records are used to support specific business scenarios that your organization supports.

Contents

Umbrella Agreement Contacts

TOS Covered Entities

Rate Terms Overridden By Terms Of Service

Umbrella Agreement Renewal

Umbrella Agreement - Contacts

The contacts page defines persons associated with the umbrella agreement. Open this page using Umbrella Agreement Management, Umbrella Agreement and navigate to the Contacts tab.

Description of Page

The contacts collection allows you to define persons that are associated with the umbrella agreement. For each contact, define the Person ID for the person record that contains the demographic information for the contact. For each contact, use the Comments to define information about the contact.

TOS Covered Entities

Your implementation may configure a TOS type to require that entities "covered" by the terms of service record be referenced on the TOS. For example, imagine that you define an umbrella agreement to provide special discounts to all the McDonalds franchises in your service area. When creating the terms of service record for the umbrella agreement, you may link the person record representing the McDonalds corporate entity as a covered entity for the TOS.

Note:

that there is no base product functionality that uses this collection. However, your implementation may use this information in an algorithm, for example, it could be used in a campaign / package eligibility algorithm.

Refer to Terms Of Service Covered Entities for information about defining covered entities for a terms of service type.

Rate Terms Overridden By Terms Of Service

Your organization may require rate information to be temporarily overridden for a service agreement that is linked to a TOS. In order to do this, the TOS record must reference a template SA. Refer to Overriding Rate Terms for information about defining your TOS types to support template service agreements.

The topics in this section further describe the possible rate term overrides that may occur when a service agreement is linked to a terms of service record.

Contents

Rate Schedule Override by TOS

Override Of Other Rate Terms By TOS

Rate Schedule Override by TOS

If a service agreement is linked to a terms of service, you may configure the system to use the rate schedule from the terms of service record's template SA rather than the one from the customer's service agreement. The customer's SA type controls this option.

Fastpath:

Refer to Configure SA Types for Umbrella Agreements for more information.

If a service agreement is linked to a terms of service record, the rate information tree on the service agreement's rate info tab tells the user whether the rate from the service agreement or from the template SA on the TOS is currently applicable.

If a given service agreement's rate schedule is being taken from the terms of service record's template SA, then the override rate schedule is used not just in bill calculations, but for any logic that requires the service agreement's rate schedule. For example, one of the recommended budget amount algorithms may estimate consumption and apply the service agreement's rate. In this case, the rate used by the algorithm is the one linked to the terms of service record's template SA.

Override Of Other Rate Terms By TOS

There are other terms associated with a rate that may change when linking a service agreement to a terms of service record that has a template SA. These include contract riders, contract terms and tax exemptions.

When applying the rate to create the customer's bill segment, if a bill factor on any of the rate components indicates that it is eligible for tax exemptions, contract terms or contract riders, a flag on the bill factor indicates where the system should look for the appropriate value. The Terms of Service Usage flag tells the system to find applicable information either on the TOS's template SA only, on the customer's SA only or it should first check the TOS, then check the customer's SA.

Fastpath:

Refer to Configure Bill Factors for Umbrella Agreements for more information.

Note:

Independent of rate source. Note that the flag values on the bill factors are independent of the rate source setting for the SA type. For example, your implementation may configure the SA type's rate source to indicate that rate should be taken from the TOS template SA. However, if a bill factor is eligible for tax exemptions, your implementation may configure the bill factor to indicate that the exemption information should be taken from the customer's SA, not the template SA.

Umbrella Agreement Renewal

Although umbrella agreement records require an end date, your organization probably allows for renewal of agreements. A renewal may involve full re-negotiation of all terms, or may be as simple as extending the current terms. If umbrella agreements of a given type are eligible to be renewed, you configure the UA type to indicate how to calculate the renewal date and which algorithm to execute when the renewal date is reached.

Umbrella Agreement Renewal Background Process

The UA renewal background process (known by the batch control ID of UARENEW) finds complete umbrella agreements whose renewal date has arrived and executes the renewal algorithm for the associated UA type.

Note:

It is the responsibility of the renewal algorithm to update the renewal date as per the business practice. Refer to Renewable Umbrella Agreements for more information.

Umbrella Agreements & Proposals

Umbrella agreements and their terms of service records may reference proposal service agreements. This functionality allows you to create the full contract for your customer during the quoting stage.

Additional Umbrella Agreement Topics

The following topics describe additional functionality related to umbrella agreements.

Contents

Umbrella Agreement Alerts

Orders And Umbrella Agreements

Umbrella Agreement Reports

Umbrella Agreement Alerts

The alert zone will highlight if any of the account's SAs are linked to an effective umbrella agreement (via a non-canceled terms of service record).

Orders And Umbrella Agreements

When starting new service for a given account and premise, you may know ahead of time that the new service should be linked to an existing umbrella agreement. For example, perhaps all the service in a specific low income housing area qualifies for a special negotiated contract for the next year.

The system provides algorithms to allow you to add a new service agreement to an existing terms of service record when using the Order transaction to start service.

Refer to Configure A Campaign To Link An SA To A Terms Of Service for more information.

Umbrella Agreement Reports

The system supplies a Report providing umbrella agreement information for one or more umbrella agreements.

Umbrella Agreement Maintenance

Umbrella agreements help you manage your contracts by allowing you to group together service agreements for the contract with one or more terms of service records for the umbrella agreement.

Contents

Lifecycle Of An Umbrella Agreement

Umbrella Agreement - Main

Umbrella Agreement - Contacts

Umbrella Agreement - Characteristics

Lifecycle Of An Umbrella Agreement

The following diagram illustrates the lifecycle of an umbrella agreement.

Pending The umbrella agreement is created in pending status.

You may delete a pending umbrella agreement. Deleting a UA also deletes its terms of service records.

Complete Only complete umbrella agreements are considered effective. You may transition a UA to complete if there is at least one terms of service record linked to it and if none of its TOS records are in pending status.

Under unusual circumstances, a complete umbrella agreement may be changed back to pending to correct errors.

Umbrella Agreement - Main

Open this page using Umbrella Agreement Management, Umbrella Agreement.

Description of Page

Umbrella Agreement Info contains a concatenation of important information about the umbrella agreement. Umbrella Agreement ID is the system-assigned unique identifier of the umbrella agreement. These values only appear after the UA is added to the database.

Umbrella Agreement Status shows the current state of the UA. The buttons adjacent to the status allow you to transition the UA's status.

- Click Complete to change the status of a pending umbrella agreement to complete .

- Click Reopen to change the status of a complete umbrella agreement back to pending .

Fastpath:

Refer to Lifecycle of an Umbrella Agreement for more information.

Enter a Description for the umbrella agreement.

The Umbrella Agreement Type defines the type of umbrella agreement. Refer to Setting Up Umbrella Agreement Types for more information.

The Start Date and End Date define the effective dates of the contract. If the UA type is renewable , the Renewal Date indicates the date the umbrella agreement is processed by the renewal background process.

You may assign an Account Management Group to this umbrella agreement. The AMG controls the roles assigned to To Do entries associated with the umbrella agreement. Refer to Setting Up Account Management Groups for more information.

Use the Comments area to describe anything interesting or unusual about the umbrella agreement.

This bottom of this page contains a tree that shows the various objects linked to the umbrella agreement. 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.

Umbrella Agreement - Characteristics

The characteristics page contains information that describes miscellaneous information about the umbrella agreement. Open this page using Umbrella Agreement Management, Umbrella Agreement and navigate to the Characteristics tab.

Description of Page

Note:

Characteristic Types. You can only choose characteristic types defined on umbrella agreement's umbrella agreement type .

The following fields display:

Characteristic Type Indicate the type of characteristic.

Characteristic Value Indicate the value of the characteristic.

Note:

Default Note. An umbrella agreement's characteristics default from the umbrella agreement type.

Terms Of Service Maintenance

A terms of service (TOS) record defines one or more service agreements participating in a given umbrella agreement. The TOS record may also reference a template SA that could be used to override rate terms for the participating service agreements.

Contents

Lifecycle Of Terms Of Service

Terms Of Service - Main

Terms Of Service - SAs

Lifecycle Of Terms Of Service

The following diagram illustrates the lifecycle of a terms of service record.

Pending The terms of service record is created in pending status. You may delete a pending TOS. If you want to keep a record of the TOS, you may cancel it rather than deleting it.

Active Only active terms of service records are considered effective. Change the status to active when you have entered all the desired information for this TOS. You may delete an active terms of service if the umbrella agreement is still pending . (Otherwise you must cancel the TOS.)

Canceled You may cancel a pending or active terms of service if it should no longer be used. Canceling a terms of service record unlinks all its service agreements.

Terms Of Service - Main

Open this page using Umbrella Agreement Management, Terms of Service.

Description of Page

Terms of Service Info contains a concatenation of important information about the terms of service record. Terms of Service ID is the system-assigned unique identifier of the terms of service record. These values only appear after the TOS is added to the database.

The Umbrella Agreement ID defines the umbrella agreement to which this terms of service is linked.

Status shows the current state of the terms of service record. The buttons adjacent to the status allow you to transition the TOS record's status.

- Click Activate to change the status of a pending terms of service record to active .

- Click Pend to change the status of an active terms of service record back to pending .

- Click Cancel to change the status of a pending or active terms of service record to canceled .

Fastpath:

Refer to Lifecycle Of Terms of Service for more information.

Enter a Description for the terms of service record.

The Terms of Service Type defines the type of terms of service record. Refer to Setting Up Terms of Service Types for more information.

Use the Comments area to describe anything interesting or unusual about the umbrella agreement.

The Characteristics collection contains information that describes miscellaneous information about the terms of service record.

Note:

Characteristic Types. You can only choose characteristic types defined on the terms of service record's terms of service type .

The following fields display:

Characteristic Type Indicate the type of characteristic.

Characteristic Value Indicate the value of the characteristic.

Note:

Default Note. A terms of service record's characteristics default from the terms of service type.

The Covered Entities collection allows you to define specific entities that are "covered" by this terms of service record. Refer to TOS Covered Entities for more information.

Note:

Characteristic Types. You can only choose covered entity characteristic types defined on the terms of service record's terms of service type.

The following fields display:

Covered Entity Characteristic Type Indicate the type of characteristic used to define this covered entity type.

Characteristic Value Indicate the value of the characteristic used to define the covered entity value.

Note:

Default Note. A terms of service record's covered entity types default from the terms of service type.

Terms Of Service - SAs

This page is used to maintain the service agreements linked to the terms of service record.

Open this page using Umbrella Agreement Management, Terms of Service and navigate to the SAs tab.

Description of Page

Terms of Service Info contains a concatenation of important information about the terms of service record. Terms of Service ID is the system-assigned unique identifier of the terms of service record.

The filters control the service agreements that appear in the grid. The following points describe the various options:

- Use the SA Filter to define the types of service agreements that appear in the grid. The following options are available:

- Account. Use this option to restrict service agreements to those linked to a given Account ID.

- Address. Use this option to restrict service agreements to those linked to service points associated with a given Address, City and/or Postal code. Note, you can specify any combination of these fields.

- All. Use this option if you do not wish to restrict service agreements based on service agreement attributes.

- All Proposals. Use this option to restrict service agreements to only proposal service agreements.

- All Real SAs. Use this option to restrict service agreements to only "real" service agreements (i.e., not proposal SAs).

- Geographic Type. Use this option to restrict service agreements to those linked to service points associated with a given Geographic Type and Geographic Value.

- SA Type. Use this option to restrict service agreements to those linked to a given CIS Division and SA Type.

- Specific SA. Use this option to reference a specific SA ID.

- Use Status Filter to restrict the service agreements based on their status. Status values for both proposal service agreements and regular service agreements are included in the filter. The following options are available:

- All . This option shows all service agreements, including proposal service agreements, regardless of status.

- Refer to Service Agreement Lifecycle for the various status values for real service agreements.

- Refer to Proposal SA State Transition for more information about status values for proposal service agreements.

Don't forget to click the search button after changing the filters.

The grid that follows contains the Service Agreements that match your search criteria along with its Account Info.

Use the "+" to link new service agreements to the terms of service record.

Note:

Link SA Using Order. You may also link a service agreement to a TOS through orders if you have configured an appropriate campaign and package.

Note you may remove a service agreement from the TOS using the "-" button as long as the change has not been committed to the database. As soon as the SA's link to the TOS has been committed to the database, you must use the Remove action to unlink the service agreement.

The Select All / Clear All buttons are used to select service agreements if you plan on issuing the mass update action Remove at the bottom of the page. Clicking Remove removes the service agreement from the terms of service record.

Job Streams

The term "job stream" refers to a suite of batch jobs that run periodically. Most organizations have multiple job streams. For example,

- You'll have a job stream that contains batch jobs that run nightly

- You'll have a different job stream that contains the hourly batch jobs

- You'll have a different job stream that contains the batch jobs that extract data for your data warehouse

- Etc.

The topics in this section describe how to execute and monitor your job streams.

Fastpath:

Refer to The Big Picture of Scheduling Batch Jobs for a description of how to set up the system to enable this functionality.

Note:

Only used by some organizations. Many organizations use a third party tool to manage the periodic execution of batch jobs rather than the system batch scheduler. If this is true for your organization, this section is not applicable.

Separate module. Please note that the batch scheduler functionality is associated with a separate Workflow Scheduling module. If this module is not applicable to your business, you may turn it off. Refer to Turn Off A Function Module for more information. .

Contents

Job Stream Summary

Job Stream Details

Job Stream Summary

This page presents a summary of your job streams. Open this page using Batch, Job Stream Summary.

Description of Page

This page summarizes the status of your job streams.

Note:

Only job streams defined on the Feature Configuration for the Batch Scheduler appear on this page.

The following information is displayed for each job stream:

- Job Stream. This is the description of the job stream. Click the hyperlink to transfer to the job stream's workflow process template (the workflow process template defines the number and type of batch jobs in the job stream as well as their dependencies).

- Cancel Button. If the job stream is executing, a Cancel button appears. Pushing this button will cancel the execution of any batch jobs in the job stream that have not already started. Batch jobs that are currently executing will continue to execute until they conclude or are stopped in the operating system.

- Start Button. If the job stream is not executing, a Start button appears. Pushing this button submits the request to execute the job stream's batch jobs. The job stream's batch jobs will only execute when the batch submitter next runs. The batch submitter's frequency of execution is configured by your organization.

- Last Completed Run. This is the start date / time when the job stream last executed. In addition, the job stream's total elapsed time is displayed. Click the hyperlink to transfer to the Job Stream Details page where you can see the execution status of each batch job in the job stream.

- Run In Progress. This column only contains information if a job stream is executing. The date / time that the job stream was requested is shown as well as a colorful status bar. Clicking the hyperlink under the date / time transfers you to the Job Stream Details page where you can see the execution status of the job stream's batch jobs.

- The status bar provides a visual clue as to the execution status of the job stream's batch jobs. The bar's segments and their colors are used to highlight the relative number of batch jobs in a given state. For example, it will highlight the relative number of Pending versus Complete versus Error batch jobs.

You can hover the mouse over a section of the bar to see the number of batch jobs in each state. You can click on a segment of the bar to drill down to the Job Stream Details page. When this page appears, only the batch jobs in the respective state are displayed.

The message Other(s) running appears if more than one instance of this job stream is running (this should be rare).

- Next Scheduled Run. This is the start date / time when the job stream is next scheduled to run. Click the hyperlink to transfer to the Job Stream Creation Schedule page where you can define when the job stream runs. You can also use this transaction to hold prescheduled runs.

Job Stream Details

Job streams execute many times over their lifetime. For example, the nightly job stream executes every night; the hourly job stream executes hourly; the data warehouse extract executes weekly; etc.

Every time a job stream executes, a workflow process is created. The workflow process's events cause the job stream's batch jobs to be submitted.

This page shows the status of the job stream's workflow events and the batch jobs that they submit. Open this page using Batch, Job Stream Details.

Description of Page

Job Stream is a concatenation of important information about the execution of the job stream (e.g., its description, status, start date).

Job Stream ID is the system-assigned unique identifier of an execution of the job stream.

Note:

The Job Stream ID is the unique identifier of the workflow process used to manage the execution of the job stream's batch jobs.

The colorful status bar summarizes the execution status of the job stream's batch jobs. This bar's segments and their colors are used to highlight the relative number of batch jobs in a given state. For example, it can highlight the relative number of Pending versus Complete batch jobs ( Pending jobs are one color, Complete jobs another).

You can hover the mouse over a section of the bar to see the number of batch jobs in each state. You can click on a segment of the bar to cause the grid to be refreshed with batch jobs in the respective state. For example, if you click on the color used to highlight jobs in Error , only these jobs will appear in the grid. You can achieve the same results by selecting the desired Event Status.

If the job stream is executing, a Cancel Job Stream button appears. Pushing this button will cancel the execution of any batch jobs in the stream that have not already started. Batch jobs that are currently executing will continue to execute until they conclude or are stopped in the operating system.

The grid contains a summary of the job stream's workflow events and the batch jobs that they submit. The following information is displayed for each workflow event:

- Event describes the workflow event that submits the batch job (the code following the description is the workflow event's type).

- The colorful box that prefixes the event provides a visual clue of the event's status (e.g., Pending events are one color, Waiting another, etc.). These colors correspond with the "status bar" at the top of the page.

Click on the hyperlink to transfer to the workflow event. You might need to display a workflow event if:

- You need to cancel a Pending or Waiting event. To do this, display the event and change its status to Canceled . Note, if the Waiting event is associated with a batch job that is currently executing, canceling the event will NOT abort the execution of the batch job. The only way to abort the execution of a batch job that is executing is via the operating system.

- You need to restart a batch job that's in Error . To do this, display the workflow event and change its status to Pending .

- Batch Run provides an overview of the batch job submitted by the workflow event:

- If the corresponding workflow event is Pending , the batch job has not been submitted yet. There are two reasons why an event may be Pending :

- If the event is waiting for the batch submitter to run, the message Starting soon... appears. The next time the batch submitter runs, the batch run will be executed. The batch submitter's frequency of execution is configured by your organization.

- If the event is waiting for the successful completion of other events, a message describing the events on which it is waiting is shown. You define the dependencies between events (i.e., batch jobs) when you set up the job stream's workflow process template.

- If the corresponding event is Waiting , the batch job is currently executing and a summary of the execution status is shown. You can click on the hyperlink to transfer to the Batch Run Tree where the details of the run's parallel threads and errors are shown. Note, a summary of the various threads and errors is shown in the next column.

- If the corresponding event is Complete , Failed , or Error ; the batch job has completed and a summary of its execution is shown. You can click on the hyperlink to transfer to the Batch Run Tree where the details of the run's parallel threads and errors are shown.

- Batch Run Details provides more extensive details about a batch run's execution. The following information is shown:

- You can configure the workflow event to execute multiple parallel threads of a given batch job. For example, rather than running a single instance of the BILLING batch job, you can indicate 40 parallel threads should run (thus improving throughput). This column always contains a summary of the execution status of the parallel threads.

- The number of records processed by the job. For example, if this is the BILLING job, the number of records shows the number of accounts for which bills were created.

- The number of errors detected during the batch job (this information appears in red).

- The average, minimum and maximum execution time per thread.

- You can click on the hyperlink in the adjacent column to transfer to the Batch Run Tree where the details of the run's parallel threads and errors are shown.

Workflow and Notifications

We use the term "notification" to reference the electronic transactions that you exchange with third parties when:

- They need information about a customer

- They need to change something about a customer

For example, an energy service provider sends a notification to a distribution company when a customer chooses them as their energy provider. When a notification is received by the distribution company, the system responds by creating a workflow process. The workflow process contains workflow events. These events perform the processing necessary to execute the notification.

In addition to processing incoming notifications, workflow processes can be used to automate many different types of multi-event processes. For example, you can use workflow processing to manage the events associated with the inspection of a new premise.

This section describes how to manage your workflow and notification processing.

Note:

In the section, Defining Workflow and Notification Options, we describe how to set up the control tables that automate most of your notification and workflow processing. If you set these tables up properly, little or no operator intervention should be necessary. You should only have to access the workflow and notification pages when you need to override the standard procedures embodied in your workflow processes.

Contents

The Lifecycle Of A Workflow Process And Its Events

Workflow Process Maintenance

Workflow Event Exception

Uploading Notifications

Downloading Notifications

The Lifecycle Of A Workflow Process And Its Events

The following diagram illustrates the lifecycle of a typical workflow process and its workflow events:

The above diagram is referenced in the following topics.

Contents

What Is A Workflow Process?

A Workflow Process Contains Relevant Data

How Are Workflow Processes Created?

How Are Workflow Events Completed?

How Are Workflow Processes (and their Events) Canceled?

What Is A Workflow Process?

A workflow process is difficult to define because its flexible design can be used to automate many different types of multi-event processes. For example,

- You can use a workflow process to manage the events associated with the inspection of a new premise.

- You can use a workflow process to manage the events that transpire in a deregulated market when a customer wants to switch energy service providers.

- You can use a workflow process to notify interested parties when something about a customer changes. For example, if a customer changes their phone number, a workflow process can send notifications to the customer's various service providers.

The following is an illustration of a workflow process that could be used to process a request from an energy service provider to switch a customer's electric supplier on a specified date.

Note:

Bottom line: A workflow process contains one or more workflow events. Each event is activated on its respective trigger date. When an event is activated, the system executes the activation algorithm associated with the event's event type. It's up to you to define exactly what algorithms should be associated with your workflow event types. Refer to Designing Workflow Event Types for sample events.

A Workflow Process Contains Relevant Data

Linked to a workflow process are the relevant data associated with the process. This information can be for audit purposes or it may be needed by one or more of the event algorithms linked to the process to do its work. For example,

- If a workflow process is associated with the inspection of a premise, the premise is linked to the workflow process.

- If a workflow process is associated with new service, many pieces of information are needed to be linked to the workflow including the address of the new service location, the date service should start, perhaps the desired rate and perhaps customer information, if this is for a new customer.

- If a workflow process is triggered when we receive a notification that we have a new customer, the notification is linked to the workflow process.

This data may be linked to the workflow process in one of two ways: as context or as characteristics. The following points describe each method:

- Context Collection

- Uses a context type to identify the type of data. The values of the context type are stored in a lookup field and must be customized by your implementers.

- The values are stored in the context value field. Values may be up to 50 bytes long.

- The primary key of the record includes context type and context value so multiple values may be entered for the same type.

- Note, the context value is a generic field. If the value of the field is a foreign key, there is no way for the system to enable drill down capability to this foreign key's entity.

- Characteristic Collection

- Uses the characteristic type table to identify the type of data. Characteristic types may be pre-defined, ad-hoc, foreign key or file location.

- The values are stored in different characteristic value fields depending on the type of characteristic. The ad-hoc and file location values may be up to 254 bytes long.

- The primary key of the record includes characteristic type and a sequence number so multiple values may be entered for the same type.

- If the characteristic is of type foreign key reference, a search is available for selecting an appropriate value and a drill down key is available for viewing the related record.

Note:

The original design included only the context collection. The characteristic collection was added later as a result of limitations in the context functionality that was supported in other parts of the system by characteristic functionality. It is expected that characteristics will be the preferred method to use for implementations. Context will continue to be supported for earlier releases.

Information in a workflow process' context or characteristics collection is referenced by the workflow process' event algorithms when they are activated.

If a workflow process is created to process an incoming notification from a third party, the first event algorithm for your workflow process must populate the workflow process' context or characteristics with individual fields specified on the incoming notification.

Fastpath:

Refer to Uploading Notifications Into The System for more information.

Note:

. If an account ID or premise ID in Oracle Utilities Customer Care and Billing is linked to an active workflow process either via context or via a characteristic, you may configure your system to display an alert when that account or premise is displayed in the current context. To display this alert, create one or more algorithms for the algorithm type CCAL-WF, setting the parameters as appropriate to display account or premise and indicate whether or not the account/premise will be found in the context or characteristic collection. Plug in your new algorithm(s) to the installation option - algorithm collection.

How Are Workflow Processes Created?

A workflow process may be created as follows:

- The Notification Upload background process (referred to by the batch code of WFPRINIT ) creates a workflow process when a notification is interfaced into the system. The workflow process has one or more workflow event(s). Workflow processes created as a result of a notification upload staging record will reference the NUS ID that created it. Refer to The Big Picture Of Notification Processing for more information about notifications.

- An operator may create an ad hoc workflow process at will.

- If you customize the system accordingly, the system will create a workflow process when a significant event occurs. The purpose of this type of workflow process is to send outgoing notifications to other interested parties to apprise them of the event. For example, assume you are a distribution company, you probably have to advise a customer's energy supply company whenever their meter is exchanged. In this example, when a meter exchange transpires, you'd want to create a workflow process that would, in turn, send outgoing notifications to the energy supply company. Refer to Designing Notification Downloads for more information.

Whenever a workflow process is created, the system uses a workflow process template to create the workflow process. The workflow process template defines the various events that will transpire over the course of the process. Refer to Designing Workflow Process Templates for more information.

In the above diagram, the event on 1-Dec-00 shows the creation of a workflow process with three workflow events. Notice that the events all exist in the Pending state. The events will exist in this state until their trigger date is on or before the current date.

Fastpath:

Refer to What Type Of Workflow Process Is Created? to understand how the Notification Upload Process creates workflow processes when notification requests are interfaced into the system. Refer to The Big Picture Of Workflow Events for more information about a workflow process's events.

How Are Workflow Events Completed?

Several background processes can cause a workflow event to complete as described below:

- A background process (referred to as WFET ) activates events whose trigger date is no longer in the future. (An event's trigger date can be set to a future date when its earlier, dependent events are completed if the workflow process template so indicates). After it activates an event, this process also activates later dependent events until there are no more events to activate. Refer to Workflow Event Dependencies & Trigger Date for more information.

Note:

WFET attempts to activate workflow events for a workflow process. The system orders the workflow process records by their workflow process ID, which is a system-generated random number. As a result, you should ensure that the activation algorithms do not expect WF process records to be processed in any other order, such as the order that the WF process records were created. For example, if a "drop request" and an "add request" are both received for the same customer, two workflow processes are created. The activation algorithms for the events for these two processes should work regardless of whether the "drop request" is processed first or the "add request" is processed first.

- The various waiting background processes are responsible for activating events when the thing they are waiting on is complete. For example, if an event creates a pending field activity, it goes into the Waiting state. The WAITFA background process will activate the Waiting event when the field activity becomes Complete . Refer to Waiting Events And Their Waiting Process for more information.

In addition, if the workflow event type indicates that manual completion is allowed, a user may change the status of the event to complete using the workflow process user interface. When an event is manually completed, the system also activates later dependent events until there are no more events to activate.

Fastpath:

Refer to The Big Picture Of Workflow Events for more information about the various types of workflow events and what happens when they are completed.

How Are Workflow Processes (and their Events) Canceled?

The background process that is responsible for activating events (referred to as WFET ) automatically cancels a workflow process when one of its events fails. Refer to Some Workflow Events May Fail for more information.

Refer to How Are Workflow Events Canceled for more information.

Besides these automatic cancellations, an operator may cancel a workflow process at will.

Workflow Process Maintenance

A workflow process is hard to define because its flexible design can be used to automate many different types of multi-event processes. For example,

- You can use a workflow process to manage the events associated with the inspection of a new premise.

- You can use a workflow process to manage the events that transpire in a deregulated market when a customer wants to switch energy service providers.

Fastpath:

For more information about workflow processes, refer to The Lifecycle Of A Workflow Process And Its Events.

The topics in this section describe the pages on which workflow process-related information is maintained.

Contents

Workflow Process - Main

Workflow Process - Char/Context

Workflow Process - Events

Workflow Process - Event Char/Context

Workflow Process - Main

The Main page contains core workflow process information. Open this page using Workflow and Notification, Workflow Process.

Description of Page

The top portion of every page contains the following information:

Workflow Process is a concatenation of summary information about this workflow process. It is composed of the workflow process template's name and description, the workflow process's status, and the creation date of the process.

Workflow Process ID is the unique system-generated identifier for this workflow process.

The remaining fields are maintained on the main workflow process page.

The Create Information describes how the workflow process was created. If the workflow process was created by the system, the identity of the process, and related control table references are displayed. If the workflow process was created by a user, the message indicates this.

Workflow Status defines the state of the workflow process. The following values may exist:

Active The system creates a workflow process in the Active state. A workflow process remains in this state until the last event linked to the process is complete OR an event fails OR you want to cancel the process for whatever reason.

Inactive A workflow process becomes Inactive when the last event linked to the process is completed OR an event fails OR you want to cancel the process for whatever reason. The Status Reason field tells you how a workflow process became inactive.

Fastpath:

To completely understand the significance of a workflow process's status, refer to The Lifecycle Of A Workflow Process And Its Events.

Status Reason defines how a workflow process became Inactive or why a workflow process is Active . The following values may exist:

Canceled by User This reason should be used when an operator manually inactivates a workflow process (for whatever reason).

Canceled by System This reason is populated by the system when it cancels a workflow process.

Events Pending This reason is populated by the system when a process has pending events.

Complete by System This reason is populated by the system when it completes the last event linked to the workflow process.

Complete by User This reason is populated by an operator when they manually complete a workflow process.

Workflow Process Template defines the workflow events in the process. You can override these events on the Events page.

Note:

Changing the template. If you change the template when all events are pending , the system will remove the pending events and replace them with the new template's events.

Fastpath:

For more information, refer to Setting Up Workflow Process Templates.

If your event has been canceled by the system, a Message appears indicating the reason for cancellation.

Create Date/Time defines the start date/time of the workflow process. This is important as it affects the trigger dates of the process's workflow events. If you change this date after events exist, the system will NOT update the trigger date on the events. If you need to change the trigger date on the events, you can do this manually on the Events page OR you can change the Workflow Process Template to something (anything) and then change it back to the desired template. When you change the template, the system removes the events and creates new ones using the creation date / time on the process.

The workflow process was created by a Notification Upload staging record, information about the notification upload staging record is displayed.

Enter any Comments about the workflow process.

This bottom of this page contains a tree that shows the various objects linked to the workflow process. 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.

Workflow Process - Char/Context

The Process Char/Context page lists the context collection and/or the characteristic collection associated with the workflow process. Open this page using Workflow and Notification, Workflow Process, Process Char/Context.

Fastpath:

Refer to A Workflow Process Contains Relevant Data for more information about context and characteristics.

Description of Page

Use characteristics and/or context to capture data to be used by your workflow process' event algorithms. Refer to A Workflow Process Contains Relevant Data for more information.

The Characteristics grid displays the Characteristic Type and Characteristic Value for each attribute that can be accessed by the workflow process' event algorithms.

The Context grid displays the Context Type and Context Value for each attribute that can be accessed by the workflow process's event algorithms.

Note:

The values for Context Type are customizable using the Lookup table. This field name is WF_PROC_CTXT_FLG.

Workflow Process - Events

The events page contains the activities that will be performed over the course of the workflow process. Open this page using Workflow and Notification, Workflow Process, Events.

Note:

We strongly recommend that you understand the information described in How Are Workflow Events Completed? before using this page.

The number and type of events associated with a workflow process are defined by the process's workflow process template (which is defined on the first page). Refer to Setting Up Workflow Process Templates for more information.

Description of Page

The top portion of every page in this page contains the following information:

Workflow Process is a concatenation of summary information about this workflow process. It is composed of the workflow process template's name and description, the workflow process's status, and the creation date of the process.

Workflow Process ID is the unique system-generated identifier for this workflow process.

The scroll controls the display of the individual workflow events that comprise the workflow process. The grid shows the events that must be completed before the workflow event is triggered. Only one workflow event is displayed at a time.

Event Sequence is the unique identifier of the event.

Workflow Event Status defines the state of the event.

Fastpath:

For more information, refer to Workflow Event Lifecycle.

If the workflow event status is Error , then the message related to the error is displayed adjacent.

Note:

Failed events are special. If the workflow event's status is Failed , the system displays the Failure Algorithm that was executed (the type of failure algorithm is defined on the event's event type) and, if the failure algorithm created a workflow process, the system displays information about the Created Workflow Process.

The Workflow Event Type defines the event's activity.

Fastpath:

For more information, refer to Setting Up Workflow Event Types.

If Dependent on Other Events is turned on, then the event's trigger date is only determined after the event(s) on which it depends are completed. When this switch is on, a grid appears at the bottom of the page in which you define the event(s) on which this event depends.

Fastpath:

For more information about dependent events, see Workflow Event Dependencies & Trigger Date.

The Trigger Date defines the date when the system completes (i.e., executes) the event. This field is gray when the event is dependent on the completion of other events.

Fastpath:

For more information about a workflow event's trigger date, see Workflow Event Dependencies & Trigger Date.

Days After Previous Response defines how a dependent event's trigger date is calculated. The trigger date is set equal to X days after the last dependent event is completed, where X is the number in this field. This field is gray when the event is not dependent on other events.

Fastpath:

For more information about dependent events, see Workflow Event Dependencies & Trigger Date.

The Status Change Date/Time is date and time the event's status was last changed.

If the event can go into the Waiting state, the Wait Date/Time is populated with the date / time on which the event started waiting.

Fastpath:

Refer to Waiting Events And Their Waiting Process for more information.

The grid at the bottom of the page contains the events on which this event depends. This grid is only visible when the event is dependent on other events (as defined by the Dependent on Other Events switch).

Workflow Process - Event Char/Context

The Event Context page lists the entity(ies) that were created as a result of the execution of a workflow event. For example, if an event creates a field activity, the field activity would be displayed on this page. The event algorithm may choose to record the entity using a characteristic or a context entry. Open this page using Workflow and Notification, Workflow Process, Event Char/Context.

Fastpath:

Refer to A Workflow Process Contains Relevant Data for more information about context and characteristics.

Description of Page

Your event algorithms may record information that was created by the algorithm. The information may be recorded as a characteristic or in a context entry. This information is for audit purposes only.

If Characteristics are used to record entities created by the algorithm, this grid displays the Characteristic Type and Characteristic Value for each entity that was created as a result of the execution of workflow event.

If Context entries are used to record entities created by the algorithm, this grid displays the Context Type and Context Value for each entity that was created as a result of the execution of workflow event.

Note:

The values for Context Type are customizable using the Lookup table. This field name is WF_EVT_CTXT_FLG.

Workflow Event Exception

As described in Workflow Events May Be In Error, a record is written the workflow event exception record for every workflow event record that is in error.

To view the messages associated with the exception records, schedule the TD-WEXTL background process. This process generates a To Do entry for every record in the workflow event exception table.

After correcting the cause of the error, drill into the Workflow Process - Events tab and change the status from Error to Pending . The next time the event activation process runs, it attempts to process this record again.

Uploading Notifications

This section describes how the system uploads notifications. Refer to Uploading Notifications Into The System for more information.

Contents

Notification Upload Background Process

Notification Upload Staging Maintenance

Notification Upload Staging - Sample Upload Extension Record

Notification Upload Exception

Notification Upload Background Process

The following diagram illustrates the processes involved in the uploading of notifications into the system.

The topics in this section describe how these processes work.

Contents

Process X - Populate Notification Upload Staging

Process WFPRINIT - Initiate Workflow Processes To Execute Notification Upload Staging R

Validation of Data Related to the Notification Upload Staging Records

Process X - Populate Notification 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 entity relationship diagram).

The NUS record contains only key header information, but it does not contain detailed information that would be required to process the notification. To define the other required information, like Account ID and meter number, you have three options:

- NUS Characteristics: This is a collection of characteristic values, where the characteristic type describes the data that is contained in the characteristic values. In order to set this up correctly, the appropriate characteristic types need to be defined.

- NUS Context: This is a collection of context values, where the context type describes the data that is contained in the context values. In order to set this up correctly, the appropriate context types need to be defined by your implementers.

- NUS Extension: This is a separate table, with explicit columns defining the data. In order to set this up correctly, a new table and new user interface will need to be created by your implementers, along with a new Extension type.

For any of the methods, the first Workflow Event in your workflow process will have the responsibility to retrieve the core information from the Characteristic collection, the Context collection or the Extension record and populate the workflow process context or characteristic collection accordingly.

The topics in this section describe each of these tables.

Contents

Notification Upload Staging

Notification Upload Staging Context

Notification Upload Staging Characteristics

Notification Upload Staging Extension - Base Sample

Notification Upload Staging

You must create an upload staging record for each notification being processed in the system. The name of this table is CI_NT_UP . The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

NT_UP_ID

12

Y

A/N

This is a sequential unique key. This key is referenced on the NUS extension record. (The NUS extension record contains almost all of the fields associated with the notification.)

This key is a sequential number so you can use a database function to assign the value when populating the table.

NT_XID_CD

30

Y

A/N

This identifies the external system that sent the notification (e.g., a DUNS number).

This must correspond with the prime key of one of your external systems. Refer to Designing External Systems for more information.

NT_UP_XTYPE_CD

30

Y

A/N

This identifies the transaction type of the notification.

This must correspond with the prime key of one of your notification upload types. Refer to Designing Notification Upload Types for more information.

NT_UP_STAT_FLG

2

Y

A/N

This must be set to P for Pending .

NT_UP_EXTSN_FLG

4

Y

A/N

This identifies the type of notification upload staging extension record that contains the details of this notification upload. Valid values: NONE , SPL . Use NONE if you will use the context collection for your related data.

CRE_DTTM

26

Y

DateTime

This is the date / time on which the notification upload staging record was created. This must be populated with the current date / time.

Notification Upload Staging Context

If desired, you may insert rows into the upload staging context collection. The context collection enables you to define all the core information associated with the upload staging record. Context flag values will need to be defined for every piece of data you wish to capture. This option may be used in favor of the extension record option, defined below, because you do not need to define new database tables or new user interfaces for each new notification upload type.

The name of this table is CI_NT_UP_CTXT . The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

NT_UP_ID

12

Y

A/N

This is the unique key of the NUS record to which this collection is linked.

NT_UP_CTXT_FLG

4

Y

A

This field describes the data that is stored in the Context Value. Refer to Notification Upload Staging for more information.

CTXT_VAL

50

Y

A

This is the value of the context.

Notification Upload Staging Characteristics

If desired, you may insert rows into the upload staging characteristics collection. The characteristics collection enables you to define all the core information associated with the upload staging record. Characteristic types will need to be defined for every piece of data you wish to capture. This option may be used in favor of the extension record option, defined below, because you do not need to define new database tables or new user interfaces for each new notification upload type.

The name of this table is CI_NT_UP_CHAR . The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

NT_UP_ID

12

Y

A/N

This is the unique key of the NUS record to which this collection is linked.

CHAR_TYPE_CD

8

Y

A

This field describes the data that is stored in the characteristic value field. Refer to characteristic type for more information.

SEQ_NUM

3

Y

N

This value is used to differentiate multiple characteristics of the same type. Values are typically incremented by 10.

CHAR_VAL

16

N

A

Populate this field if your characteristic type is predefined .

ADHOC_CHAR_VAL

254

N

A

Populate this field if your characteristic type is ad-hoc or file location .

CHAR_VAL_FK1 - CHAR_VAL_FK5

50 each

N

A

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.

Notification Upload Staging Extension - Base Sample

A notification upload staging EXTENSION record may be used in lieu of Context to contain the core information associated with a notification upload record. This option enables you to be explicit in your definition of the fields that must be captured for each notification upload type.

The sample extension record that is supplied with the system is just that - a sample. If you use this option, you will need one such extension record for each different type of notification upload record layout you support. It's important to understand that all of your different notification upload extension record types must reference the coreNotification Upload Staging record because the system uses the core record to drive the notification upload process.

The name of the sample notification upload extension record is CI_NT_UP_XSPL . The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

NT_UP_ID

12

Y

A/N

This is the reference to the Notification Upload Staging record that this record is an extension of.

REC_DTTM

26

Y

Date/Time

This is the date / time the record was received.

RESPONSE _CODE

1

Y

A/N

This column is used when the notification is an indication of the acceptance or a rejection of an earlier notification request.

If specified, this must be either A - accept or R - reject.

SDR_ACCT_ID

20

Y

A/N

This is the customer's account ID in the sender's system.

RCV_ACCT_ID

20

Y

A/N

This is the customer's account ID in the receiver's system.

SDR_REC_ID

16

Y

A/N

This is a transaction identifier supplied so responses to this record may be identified. The contents of this field will be returned on notification download records that respond to this notification upload record.

RCV_REC_ID

16

Y

A/N

This is the transaction identifier received in a previous request record. This field is only populated if the notification being uploaded is an acceptance / rejection of a previously sent notification download record.

BILL_OPT_FLG

4

Y

A/N

This defines the billing relationship between the service provider and your organization. This value is used in conjunction with BILL_CALC_OPT_FLG to determine the service provider associated with the NT_XID_CD on the CI_NT_UP record. Valid values are: DUAL , ESP , UDC .

BILL_CALC_OPT_FLG

4

Y

A/N

This defines the bill calculation method used when your organization provides billing services for the service provider. This value is used in conjunction with BILL_CALC_FLG to determine the service provider associated with the NT_XID_CD on the CI_NT_UP record. Valid values are: BILL (bill ready), RATE (rate ready).

MTR_NBR

16

Y

A/N

The customer's meter number. This is used to help identify the service agreement associated with the notification.

BILLING_DATE

2

Y

N

This is the day of the month used to derive the service cycle define on SA relationship records associated with service providers who provide MR services.

POSTAL_CD

12

Y

A/N

The service address's postal code. This is used as a crosscheck to ensure the notification is referencing the correct customer.

Process WFPRINIT - Initiate Workflow Processes To Execute Notification Upload Staging Records

This process creates a workflow process for all Notification Upload Staging records in the Pending state. It determines the workflow process using a combination of the External Id and the NUS Type. Refer to What Type Of Workflow Process Is Created for more information. It stamps the NUS ID onto the newly created workflow process.

If the External ID on the staging record is not a valid External ID in our system, rather than creating an error, this process will find a workflow process template with a notification condition of Unknown Notification ID and create a workflow process. If the NUS Type on the staging record is not a valid NUS Type in our system, rather than creating an error, this process will find a workflow process template with a notification condition of Unknown Notification ID and create a workflow process. Refer to Setting Up Workflow Process Templates for more information. For these cases, the status of the notification upload staging record will be set to Complete .

Any errors detected during this process will be written to the Notification Upload Exception table. You can fix errors using the Notification Upload Staging page (don't forget to change the record's status back to Pending ).

Fastpath:

Refer to Uploading Notifications Into The System for more information.

Validation of Data Related to the Notification Upload Staging Records

As mentioned above, the sole purpose of the Initiate Workflow Process (WFPRINIT) is to successfully create a workflow process. Once a workflow process is created, the NUS status is set to Complete .

At this point, neither the extension record, the context collection nor the characteristics collection have been processed. It is the responsibility of the first event in the workflow process to validate the fields in the extension record, the context collection and/or the characteristics collection. This algorithm will decide what to do when a problem is detected with the data. Some possible options are

- Set the algorithm status to Fail . Use this option when a critical error is detected, which probably cannot be fixed by a user. This will cause the remaining events to be canceled.

- Set the algorithm status to Error . Use this option when an error is detected, which can be corrected by a user. This will cause an exception record to be created. The user should be able to correct the source data in the extension record, the context collection or the characteristics collection, change the status back to Pending and rerun the Workflow Event Activation process. Note that if the validation algorithm uses this option, the ability to rerun this event should be handled by the coding of this algorithm. It should prevent duplicate logic from being performed.

- Send a To Do list entry and continue the workflow process by setting the algorithm status to Complete . Use this option when someone should be alerted of an unusual condition, but the process should not be halted. For this option, the To Do Type and User to use for posting the To Do entry should be parameters to the algorithm.

Note:

We said that a possible correction for the validation workflow event in the Error is to modify data in the extension record, the context collection or the characteristics collection. You may find this a bit unusual because the parent NUS record is in the status of Complete . Remember that this NUS status indicates whether or not the system was able to successfully create a workflow process. There is no status for the data related to the NUS - only the status of the event, which validates it.

Notification Upload Staging Maintenance

The Notification Upload Staging page is used to view notification upload records.

Fastpath:

Refer to Process X - Populate Notification Upload Staging for more information about these records.

Contents

Notification Upload Staging - Main

Notification Upload Staging - Characteristics/Context

Notification Upload Staging - Main

Use this page to define common attributes of notification upload staging records. Open this page using Workflow and Notification, Notification Upload Staging, Main.

Description of Page

The Upload Staging ID is the unique identifier of the notification upload staging (NUS) record.

Status shows the state of the NUS record. Potential values are: Pending , Complete , Error . To have the system reprocess a record that's in Error , change the status back to Pending . The system will revalidate the record the next time the notification upload process executes.

Create Date and Time are just that.

External System identifies the sender of the notification.

Notification Upload Type identifies the transaction type of the notification.

Extension identifies the type of notification upload staging extension record that contains the details of this notification upload. Valid values: No Extension , Sample Extension Record . You would use No Extension when you plan to define the data related to the NUS record in the characteristic collection or in the context collection rather than in an extension table. If your notification upload type indicates a navigation option associated with your extension record, a drill down button is enabled adjacent to this field.

Note:

Default Note. The extension value defaults from the value specified on the notification upload type.

The values for this field are customizable using the Lookup table. This field name is NT_UP_EXTSN_FLG.

If a Workflow Process has been created for this NUS record, information about the workflow process will be displayed.

This bottom of this page contains a tree that shows the various objects linked to the notification upload staging record along with information about the workflow process, if one has been created for the NUS. 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.

Notification Upload Staging - Characteristics/Context

Use this page to either characteristic records or context records to define data related to the NUS record. Either collection may be used as an alternative to defining an extension record. Refer to Process X - Populate Notification Upload Staging for more information.

Open this page using Workflow and Notification, Notification Upload Staging, Characteristics/Context.

Description of Page

The Upload Staging ID is the unique identifier of the notification upload staging (NUS) record.

The Characteristics collection enables you to define a collection of Characteristic Types and Characteristic Values defining data related to the NUS record.

The Context collection enables you to define a collection of Context Types and Context Values defining data related to the NUS record.

Note:

The values for this field are customizable using the Lookup table. This field name is NT_UP_CTXT_FLG.

. You will notice that both the characteristic collection data and the context collection data may be modified even when the parent NUS record is Complete . This is to enable a user to correct problems with this data as detected by the validation event. Refer to Validation of Data Related to the Notification Upload Staging Records for more information.

Notification Upload Staging - Sample Upload Extension Record

The Notification Upload Staging page is used to maintain notification upload records.

Fastpath:

Refer to Process X - Populate Notification Upload Staging for more information about these records.

Open this page using Workflow and Notification, Sample Upload Extension.

Description of Page

Receive Date and Time are just that.

Response Code is used when the notification is an indication of the acceptance or a rejection of an earlier notification request. If specified, this must be either Accept or Reject .

Sender's Customer's Account ID is the customer's account ID in the sender's system.

Receiver's Customer's Acct ID is the customer's account ID in your system.

Sender Record ID is a transaction identifier supplied so responses to this record may be identified. The contents of this field will be returned on notification download records that respond to this notification upload record.

Receiver Record ID is the transaction identifier received in a previous request record. This field is only populated if the notification being uploaded is an acceptance / rejection of a previously sent notification download record.

Billing Option defines the billing relationship between the service provider and your organization. This value is used in conjunction with Billing Calculation Option to determine the service provider associated with the sender's external system (stored on the related notification upload staging record). Valid values are: Dual Billing , ESP Consolidated , UDC Consolidated .

Billing Calculation Option defines the bill calculation method used when your organization provides billing services for the service provider. This value is used in conjunction with Billing Option to determine the service provider associated with the sender's external system (stored on the related notification upload staging record). Valid values are: Bill Ready , Rate Ready .

Meter Number is the customer's meter number. This is used to help identify the service agreement associated with the notification.

Billing Date is the day of the month used to derive the service cycle define on SA relationship records associated with service providers who provide meter reading services.

Postal Code is the service address's postal code. This is used as a cross check to ensure the notification is referencing the correct customer.

Note:

. You will notice that the extension data may be modified even when the parent NUS record is Complete. This is to enable a user to correct problems with this data as detected by the validation event. Refer to Validation of Data Related to the Notification Upload Staging Records for more information.

Notification Upload Exception

A record is written the notification upload exception record for every notification upload staging record that is in error.

To view the messages associated with the exception records, schedule the TD-NTUPL background process. This process generates a To Do entry for every record in the notification upload exception table.

After correcting the cause of the error, drill into the Notification Upload Staging page and change the status from Error to Pending . The next time the notification upload process runs, it attempts to process this record again.

Downloading Notifications

This section describes how the system downloads notifications. Refer to How Are Notifications Sent Out Of The System? for more information. Information may be extracted from the system using a batch process, which runs in the background or using the XAI tool, which continuously searches for new NDS records and builds XML documents to send to an external recipient.

Contents

Notification Download Background Processes

Notification and XAI

NDS Contains Interesting Data

Notification Download Staging

Notification Download Exception

Notification Download Background Processes

The following diagram illustrates how a batch process, which runs in the background may be used to route notifications out of the system.

The topics in this section describe how this process works.

Process NDSXTR - Interface Notification Download Records (out of the system)

This process reads all notification download staging records marked with a given batch control ID & run number and creates the flat file that's passed to the outgoing notification software. Every NDS record references the recipient service provider and a notification download type. This process uses the service provider's notification download profile to determine the format of records interfaced out of the system. Refer to Designing Notification Downloads for more information.

Note:

This process is rerunnable. You can reproduce the flat file at any time. Simply request this job and specify the run number associated with the historic run.

If you require different routing methods, you will need to create additional versions of this program.

Notification and XAI

NDS records may also be processed using the XAI tool.

Fastpath:

Refer to Notification and XAI for more information.

NDS Contains Interesting Data

The NDS record also contains interesting data

- The main use for this is to indicate the workflow process and event that created the NDS

- The process that extracts the data may then find the other data related to this NDS by looking at the workflow process context or characteristics

This interesting data may be stored in one of two ways

- Through NDS context collection. Use this method if your NDS is interfaced to the outside world using XAI. Refer to Designing Notification Download Types for more information.

- Through NDS characteristics collection. For NDS records that are interfaced through a batch process, it is expected that using characteristics is the preferred method because if your characteristic references a foreign key, your user can easily drill down to the related record.

Note:

. The algorithms provided with the base product use the context collection to populate the interesting data for an NDS.

Notification Download Staging

The Notification Download Staging page is used to view notification download records. This is especially useful if you send out a notification and request a response.

Fastpath:

Refer to Notification Download Background Processes for more information about these records.

Contents

Notification Download Staging - Main

Notification Download Staging - Characteristics/Context

Notification Download Staging - XAI Download Staging

Notification Download Staging - Main

Open this page using Workflow and Notification, Notification Download Staging.

Description of Page

The Download Staging ID is the unique identifier of the notification download staging (NDS) record.

Service Provider is the service provider to whom this download staging record will be sent. The description of the service provider is displayed adjacent.

Notification Download Type indicates the reason for this notification. The description is displayed adjacent.

Fastpath:

Refer to Designing Notification Download Types for more informationabout notification download types.

The Processing Method indicates whether this record will be processed by a Batch extract process or through the XAI tool. The processing method defined on the Notification Download Profile will be used to populate this value.

If the processing method is Batch , then NDS Extract Process indicates the process that will extract this record. This value is populated based on the service provider's notification download profile. NDS Extract Run indicates in which batch run this record was extracted or will be extracted.

Fastpath:

Refer to Designing Notification Download Profiles for more informationabout the NDS Extract Process.

The Retry Count is used by the XAI tool to keep track of how many times the tool tried to process this record and could not process the record, resulting in an error.

The Create Date/Time indicates the date and time that this record was created.

Status defines the state of the NDS record. This is only used when the processing method is XAI and will be protected when the processing method is Batch . Refer to Lifecycle of Notification Download Staging for more information.

This bottom of this page contains a tree that shows the various objects linked to the notification download staging record. 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.

Notification Download Staging - Characteristics/Context

This page displays the characteristics and/or context associated with the download staging record. Refer to NDS contains interesting data for more information.

Open this page using Workflow and Notification, Notification Download Staging, Characteristics/Context.

Description of Page

The Download Staging ID is the unique identifier of the notification download staging (NDS) record.

If Characteristics are used by the algorithm that created this record, to record information related to the record, this grid displays the Characteristic Type and Characteristic Value for each entity associated with the download staging record.

If Context entries are used by the algorithm that created this record, to record information related to the record, this grid displays the Context Type and Context Value for each entity associated with the download staging record.

Note:

The values for Context Type are customizable using the Lookup table. This field name is NT_DWN_CTXT_FLG.

Notification Download Staging - XAI Download Staging

Open this page using Workflow and Notification, Notification Download Staging, XAI Download Staging.

Description of Page

For XAI messages, an NDS Type may point to multiple XAI Route Types. Each route type is linked to an XAI sender. The system keeps track of each routing and each response. This collection of XAI Route Type includes the XAI Download Status and Message. To look at more detail, drill down into a specific XAI Routing and you are transferred to the XAI Download Staging page, where you may view the XML Request and XML Response.

Notification Download Exception

A record is written the notification download exception record for every notification download staging record that is in error. This is only applicable to records with a processing method of XAI .

To view the messages associated with the exception records, schedule the TD-NTDWN background process. This process generates a To Do entry for every record in the notification download exception table.

Fastpath:

Refer to Lifecycle of Notification Download Staging for more information.

Overdue Financial Obligations

The system periodically monitors how much your customers 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 customer to pay (e.g., letters, disconnect field activities, To Do entries, write-off outstanding debt, etc.). This section describes how to manage your overdue (i.e., collections) processing.

Note:

The overdue processing module has been designed to collect on virtually anything from an unpaid bill to an unmatched financial transaction. You tell the system what you collect on by configuring the various overdue processing control tables. In this release, the base-package is delivered with the algorithms that support collecting on overdue bills. If your organization practices balance-forward accounting (i.e., collection is based on overdue service agreement balances), you will not use this functionality. Rather, you will use the functionality described under Credit and Collections.

Contents

Overdue Processing Background Information

Overdue Process Maintenance

Cut Process Maintenance

Payment Arrangement for Bills

Overdue Processing Background Information

In the section, The Big Picture Of Overdue Processing, 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 and cut processes are created and canceled are described in this section.

Overdue Process Maintenance

An overdue process is a series of events (e.g., letters, To Do 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.

Contents

Overdue Process - Main

Overdue Process - Events

Overdue Process - Log

How To Perform Common Overdue Process Functions

Overdue Process - Main

The Main page contains core overdue process information. Open this page using Credit & Collections, Overdue Process from the main menu.

Description of Page

Note:

Refer to How To Perform Common Overdue Process Functions for more instructions describing how to use this page.

Overdue Process contains 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.

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 / Cut Event Manager to run. The Overdue / Cut 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 Templatedefines 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.

Base Date is reserved for future releases. This field is protected when the overdue process is Inactive .

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 bills, the grid contains a list of the bills 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 to the process.

- The next column contains the unique identifier of the overdue object. For example, if this process manages overdue bills, this column will contain the bill 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 shows a variety of information about the overdue process including its events and cut processes. 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 customer to pay the outstanding debt. Open this page using Credit & Collections, Overdue Process and then 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 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 / Cut Event Manager to run. The Overdue / Cut 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 Credit & Collections, Overdue Process and then navigate to the Events 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.

- Relate 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, a cut process or a cut event. It references the unique identifier of the process / 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.

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 Processing for high-level information about overdue processing.

Contents

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%.

- Use Control Central to choose the account that requires a new overdue process.

- After the account is populated on Control Central, 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 customer 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.

- Use Control Central to choose the account with the overdue process whose events need to be changed.

- After the account is populated on Control Central, choose the Overdue Process option on the account context menu to transfer to the overdue process transaction in update mode for the account. Note, an account's Active overdue processes can be selected from the Alerts zone.

- 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.

- Use Control Central to choose the account with the overdue process to be cancelled.

- After the account is populated on Control Central, 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 Alerts zone.

- On the Main tab, click Cancel and answer any prompts.

Cut Process Maintenance

A cut process contains the activities to stop a service agreement (in the hopes that lack of service will inspire the customer to pay). It should be noted that a separate cut process is created for each service agreement. The topics in this section describe the pages on which cut processes are maintained.

Fastpath:

Refer to The Big Picture Of Cut Processes for background information.

Contents

Cut Process - Main

Cut Process - Events

How To Perform Common Cut Process Functions

Cut Process - Main

The Main page contains core cut process information. Open this page using Credit & Collections, Cut Process from the main menu.

Description of Page

Note:

Refer to How To Perform Common Cut Process Functions for more instructions describing how to use this page.

Cut Process contains a concatenation of important information about the process. Cut Process ID is the system-assigned unique identifier of the process. These values only appear after the cut process is added to the database.

Note:

Summary information may be overridden. Refer to Cut Process Information Is Overridable for how your implementation can override the summary information that appears throughout the system.

Overdue Process and Overdue Event define overdue event that created the process. Refer to Cut Processes Exist Under An Overdue Process for more information.

Service Agreement identifies the service agreement being cut.

Premise identifies the service agreement's characteristic premise (if any).

Note:

Multiple cut processes may be linked to an overdue process / event. It's important to be aware that it's possible for multiple, active cut processes to be linked to the overdue event. You can see all cut processes associated with an overdue process on the tree of Overdue Process - Main. The Alert zone will contain a summary of the account's cut processes.

Status defines the state of the cut process. The following values may exist:

- Active, Events Pending. Cut processes are initially created in this state. A cut process remains in this state until there are no Pending or Waiting events.

- Inactive, Canceled by User. A cut process will exist in this state when it's been manually canceled by a user. Navigate to the overdue process's Log tab to see when this happened and who did it.

- Inactive, Canceled by System. A cut process will exist in this state when it's been canceled by the system (typically because the overdue obligations on the overdue process were satisfied). Navigate to the Log tab to see when this happened.

- Inactive, Completed. A cut process will exist in this state when the system completes its last event. Navigate to the overdue process's Log tab to see when this happened.

The Cancel button appears if the cut process is Active, Events Pending and the process's Cut Process Template has a Cancel Logic plug-in. Click this button to cancel the process.

The Trigger Events button appears if the cut 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 / Cut Event Manager to run. The Overdue / Cut 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).

Cut Process Templatedefines the template that was used to create the cut 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 cut process. This field is protected after the cut process is saved on the database. This field is used to derive the trigger date of some cut events when the process is first created. If you need to subsequently change the trigger date on the events, navigate to the Events tab and change the dates manually. Alternatively, you can perform the following "trick":

- Change the Cut Process Template to something (anything). Doing this causes the Start Date/Time to become unprotected.

- Specify the base date of the cut events in the newly unprotected Start Date/Time.

- Change the Cut Process Template back to the desired value. When you change the template, the system removes the events and creates new ones using the Start Date/Time.

Inactive Date/Time is the date and time that the cut 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 overdue process's Log tab.

Enter any Comments about the cut process. This field is protected when the cut process is Inactive .

The tree at the bottom of the page shows a variety of information about the cut process including its events. You can click on hyperlinked tree nodes to navigate to the page on which the related object is maintained.

Cut Process - Events

This page contains the activities that are performed to cut the service agreement. Open this page using Credit & Collections, Cut Process and then navigate to the Events tab.

Description of Page

Note:

Refer to How To Perform Common Cut Process Functions for more instructions describing how to use this page.

Refer to the first tab for a description of Cut Process and Cut Process ID.

The Cut Events scroll contains the process's cut events. Refer to Cut 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 Cut Event Type has a Cancel Logic plug-in. Click this button to cancel the event.

- The Cut 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 (zero), 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 / Cut Event Manager to run. The Overdue / Cut 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).

How To Perform Common Cut Process Functions

The topics in this section describe how to perform common cut process maintenance functions. Refer to The Big Picture Of Cut Processing for high-level information about cut processing.

Contents

How To Create A Cut Process

How To Change Cut Events

How To Cancel A Cut Process

How To Create A Cut Process

Cut processes are created when an overdue event is activated. You cannot create an ad hoc cut process.

How To Change Cut Events

When a cut process is first created, it has one or more cut events. The events are the activities that will be performed to persuade the customer to pay the outstanding debt.

The number and type of events that are created when a cut process is initiated are defined on the cut process's cut process template. The following points describe how to add / change / delete events on a cut process if the defaulted events are not satisfactory.

- Use Control Central to choose the account with the cut process whose events need to be changed.

- After the account is populated on Control Central, choose the Cut Process option on the account or service agreement context menus to transfer to the cut process transaction in update mode. Note, an account's Active cut processes can be selected from the Credit and Collections zone.

- To add a new event, transfer to the Cut Process - Events tab and press the + button in the Cut 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 Cut 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 Cut 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 Cut 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 cut process.

How To Cancel A Cut Process

The system will cancel a cut process when the cancel criteria defined on the overdue process are satisfied. The following points describe how to manually cancel a cut process.

- Use Control Central to choose the account with the cut process to be cancelled.

- After the account is populated on Control Central, choose the Cut Process option on the account or service agreement context menu to transfer to the cut process transaction in update mode for the account. A list of all cut processes associated with the account appears. If only one cut process exists, it is automatically selected for you. Note, an account's Active cut processes can be selected from the Credit and Collections zone.

- On the Main tab, click Cancel and answer any prompts.

Payment Arrangement for Bills

A payment arrangement is an agreement with a customer to payoff severely overdue debt in installments. Bills sent to customers with payment arrangements contain charges for both their current services and their payment arrangement installment amount.

Organizations that practice open-item accounting who collect on overdue bills may allow customers to pay off their overdue bills in installments by setting up a payment arrangement for one or more bills. This transaction is used to maintain bill-oriented payment arrangements.

Fastpath:

Refer to Bill-Oriented Payment Arrangements for background information.

Open this page using Credit & Collections, Payment Arrangement for Bill from the main menu.

Description of Page

The SA (service agreement) Info is a concatenation of important details about the payment arrangement service agreement (PA SA). The SA ID is the unique identifier of the PA SA. These values only appear after the PA SA exists on the database.

The Current Balance that appears beneath SA Info contains the PA SA's current balance. When you initially set up a PA SA this balance will be zero. It is only non-zero if the customer has not paid a billed installment.

Payoff Balance beneath SA Info contains the PA SA's payoff balance. The payoff balance is the total amount to be paid off over the PA SA's life. It is only non-zero after delinquent funds have been transferred to the PA SA. This balance is only displayed when it differs from the Current Balance.

Fastpath:

Refer to Current Amount versus Payoff Amount for more information.

Account ID is the account associated with the PA SA.

The occurrences of Current and Payoff Balance beneath Account are the account's respective balances. These values are displayed to help you confirm exactly how much the customer currently owes versus how much they will have to payoff over time (remember, after you transfer funds to a payment arrangement, the amount transferred is reduced from the account's current balance).

The Unpaid Bills grid contains a row for each of the account's unpaid bills.

Adjacent to each Unpaid Bill is its Unpaid Amount and a check box used to select the bill. Every selected bill's unpaid amount will be transferred to the PA SA when you click the Create button.

Warning:

The system automatically indicates that all unpaid debt should be transferred to the payment arrangement. It does this by checking each bill by default.

Total Candidates is the sum of ALL unpaid bills (not just the selected bills).

New Payoff Balance contains the PA SA's payoff balance. This is the total amount of debt that will be paid off over the lifetime of the PA SA. This value equals the current payoff balance on the PA SA plus all selected debt from the Candidate SAs scroll.

The next fields work in unison.

- If you want to define the number of future bills that the customer has to payoff the selected unpaid amount, enter the number of Installments. When you tab out of the field, the system sets the Arrange Amount equal to New Payoff Balance / Installments.

Note:

Arrange Amount may not add up. You will note that the Arrange Amount is rounded up so that if you multiply the number of installments by the calculated installment amount, the result will be greater than the PA SA's payoff amount. Don't worry - only the actual dollar amount of the PA SA's total debt will be billed by the system. The last installment will be slightly lower than the other installments.

- If you want to define the amount charged on future bills to payoff the unpaid amount, enter the Arrange Amount. For example, if the customer agrees to pay off their delinquent debt by paying an additional $50 on each bill, you'd enter "50" in this field. Note - If you enter a dollar amount in this field and tab out, the system will calculate the number of installments and display the number in the Installments field.

Define the CIS Division and SA Type of the payment arrangement service agreement.

Note:

Payment arrangement SA types. There is a field on SA type called Special Role Flag. Only those SA types with a role of Payment Arrangement may be selected.

Clicking the Create (or Change)button causes the system to perform the following:

- It creates / updates a payment arrangement service agreement (PA SA). It sets the installment amount on this service agreement equal to the installment amount specified on the page.

- It transfers unpaid debt from the selected bills to the PA SA. The adjustment type used to transfer these funds is defined on the PA SA's SA type.

- It links the "transfer from" adjustments to the unpaid financial transactions on the bills. This will cause the unpaid FT's to be linked to Balanced match events. This means that any Active Overdue Processes for the bills should Inactivate (i.e., cancel) because the bills will no longer be consider unpaid. Refer to How Are Overdue Processes Cancelled for more information..

- It reduces the current balance on the PA SA by the amount of debt transferred to the PA SA. Why? Because when delinquent debt is transferred to the PA SA, its current balance increases. Because current balance contains the amount the customer currently owes, this balance must be reduced because the customer is going to pay off the debt in installments (and therefore they don't currently owe anything). The adjustment type used to transfer these funds is defined on the PA SA's SA type.

Clicking Break causes the PA SA to become broken. Please refer to the note below for what transpires when a PA is broken.

Note:

Break logic is in a plug-in. Please be aware that the logic that is executed when a payment arrangement is broken exists in a plug-in algorithm (plugged-in on the account's Collection Class Overdue Rules). The base package algorithm performs many functions (refer to Breaking A Bill Oriented Payment Arrangement for the details). The bottom line is that when a PA SA is broken, the originating bills will have their debt reinstated and this will again be subject to the Overdue Monitor. Because this logic is in a plug-in, you can develop alternative logic and plug it in if the base package logic is not satisfactory.

Clicking Cancel causes the PA SA to become canceled. Cancellation should be used when you want to "logically delete" a PA SA because it shouldn't have been created.

The logic described above for breaking a payment arrangement is executed when a user cancels a payment arrangement; the only difference is that the PA SA is marked with a different characteristic type / value than when it is broken.

Contents

How To Set Up A Payment Arrangement

How To Add Additional Debt To A Payment Arrangement

How To Break A Payment Arrangement

How To Cancel A Payment Arrangement

How To Set Up A Payment Arrangement

To set up a new payment arrangement:

- Open Payment Arrangement for Bills in add mode.

- Select the Account in question.

- Select the debt to be transferred to the payment arrangement (by turning on/off the checkboxes adjacent to the Unpaid Bills).

- Enter the number of Installments or the Arrange Amount.

- Define the CIS Division and SA Type of the new payment arrangement service agreement.

- Click the Create button.

How To Add Additional Debt To A Payment Arrangement

To transfer additional debt to an existing payment arrangement:

- Open Payment Arrangement for Bills in update mode.

- Select the existing payment arrangement in the search.

- Select the debt to be transferred to the payment arrangement (by turning on/off the checkboxes adjacent to the Unpaid Bills amounts).

- Enter the number of Installments or the Arrange Amount.

- Click the Change button.

Note:

After transfer. After transferring the funds to the payment arrangement service agreement, confirm the account's payoff and current balances make sense (the payoff balance is the total amount of debt that the account will eventually have to payoff, the current balance is how much they currently owe. The account's payoff and current balances are displayed in the page's second section. If you do not understand the difference between payoff balance and current balance, refer to Current Amount versus Payoff Amount.

How To Break A Payment Arrangement

You would break a payment arrangement when a customer doesn't make the agreed payments. Typically, your overdue processes will break a payment arrangement behind-the-scenes if a customer doesn't pay. Refer to Breaking A Bill Oriented Payment Arrangement for information about how the system monitors payment arrangements.

If you want to manually break a payment arrangement,

- Open Payment Arrangement for Bills in update mode.

- Select the existing payment arrangement in the search.

- Click the Break button.

How To Cancel A Payment Arrangement

You would cancel a payment arrangement if you made a mistake and never intended to set up the payment arrangement in the first place. To cancel a payment arrangement

- Open Payment Arrangement for Bills in update mode.

- Select the existing payment arrangement in the search.

- Click the Cancel button.

Rebate Claims

The Rebate Claims feature allows you to search, view, and maintain rebate claims submitted as part of a conservation program.

Fastpath:

For more information about conservation programs, see Conservation Programs.

Contents

Rebate Claim Query Portal

Rebate Claim Portal

Rebate Claim Query Portal

You use the Rebate Claim Query Portal to search for rebate claims. Use the following procedure to search for rebate claims:

- Select Main Menu, Customer Information, Rebate Claim to open the Rebate Claim Query portal.

- Enter search criteria in the Rebate Claim Search zone and click Refresh. You can search by:

- Customer Name

- Account ID

- Conservation Program

- Start and End Dates

- A list of rebate claims matching the search criteria appears, displaying the following for each:

- Claim Date

- Rebate Claim (Status, Claim Date, Conservation Program, and Total Amount)

- Account (Name, Customer Class, Current Balance, and Account ID)

- Total Rebate Amount

- To view a rebate claim, click the Rebate Claim link. The selected rebate claim opens in the Rebate Claim portal.

Rebate Claim Portal

You use the Rebate Claim portal to view, edit, and maintain rebate claims. To add a rebate claim, open Main Menu, Customer Information, Rebate Claim.

The topics in this section describe the base-package zones that appear on the Rebate Claim portal.

Contents

Rebate Claim Zone

Adding Rebate Claims

Rebate Claim Line Zone

Rebate Claim Log Zone

Rebate Claim Zone

You use the Rebate Claim zone to view the details of rebate claims. The Rebate Claim zone opens when you first create a new rebate claim, or when you select a rebate claim on the Rebate Claim Search zone. The Rebate Claim zone displays the following information about the selected rebate claim:

- Basic Information: information about the claim, including:

- Conservation Program

- Status (Pending, Issue Detected, Approval in Progress, Receipt Verification, Complete, or Canceled)

- Rebate Claim number

- Claim Date

- Total Rebate Amount

- Customer Details: details about the customer who submitted the claim, including:

- Person

- Account

- Premise

- Mailing Address

- Contact Details: contact information for customer who submitted the claim, including:

- Name

- Phone Number

- Fax Number

- Email Address

- Premise Information: information about the physical premise of the customer who submitted the claim, including:

- Premise Property Type

- Residential Property Type

- Building Vintage

- Payment Release Authorization Details: details about the person to whom the rebate payment should be made, including:

- Authorized By

- Authorization Date

- Payee Name

- Phone Number

- Mailing Address

- Issue Details: issues related to the rebate claim, including manually submitted issues as well as those detected through the Verify action.

- Approval Details: details related to users assigned to approve the rebate claim, including:

- Current Approver

- Reject Details: details related to why a claim was rejected, including:

- Reject Reason

- Date Rejected

- Rejected By

To view a different rebate claim, select the rebate claim from the Select a Rebate Claim drop- down list and click Go.

Contents

Rebate Claim Status

Rebate Claim Actions

Editing Rebate Claims

Verifying Rebate Claims

Approving Rebate Claims

Rejecting Rebate Claims

Noting Issues Related to a Rebate Claim

Canceling Rebate Claims

Rebate Claim Status

Rebate claims are assigned a status to indicate the current state of the claim within the system. Valid statuses include:

- Pending indicates the claim is pending. This is the initial state of a rebate claim when first created.

- Issue Detected indicates that one or more issues have been detected with the claim. Issues can include those manually created as well as issues detected through the Verify action.

- Approval in Progress indicates the claim is awaiting approval.

- Receipt Verification indicates that receipts associated with the rebate claim's claim lines need verification.

- Complete indicates the claim was approved and is complete.

- Rejected indicates the claim was rejected.

- Canceled indicates the claim has been canceled.

Rebate Claim Actions

You can perform a number of actions on a rebate claim, including:

- Edit: Used to edit the details of the rebate claim.

- Verify: Used to verify the supplied details of the rebate claim, and change its status to either Approval in Progress (if the claim passes the verification) or Issue Detected (if any issues are detected). This helps ensure the rebate claim has been properly set up.

- Approve: Used to approve a submitted rebate claim, and change its status to Complete or Receipt Verification (if receipts had not been previously verified).

- Reject: Used to reject a submitted rebate claim, and change its status to Complete.

- Issue Detected: Used to note an issue related to the rebate claim, and change its status to Issue Detected.

- Cancel: Cancels a rebate claim, changing its status to Canceled.

The actions available are based on the current status of the rebate claim. The table below summarizes the actions available at each status.

Status

Valid Action

Pending

Edit, Verify, Issue Detected, Cancel

Issue Detected

Edit, Verify, Cancel

Approval in Progress

Approve, Reject, Issue Detected

Receipt Verification

Issue Detected

Completed

None

Rejected

Issue Detected

Canceled

None

Editing Rebate Claims

Use the following procedure to edit a rebate claim:

- Click Edit.

- Edit the details of the rebate claim as needed.

- Click Save.

Verifying Rebate Claims

To verify a rebate claim, click Verify.

Approving Rebate Claims

To approve a rebate claim, click Approve.

Rejecting Rebate Claims

Use the following procedure to reject a rebate claim:

- • Click Reject.

- Select the Reject Reason on the Reject Rebate Claim dialog.

- Click OK. To close the dialog without rejecting the claim, click Cancel.

Noting Issues Related to a Rebate Claim

Use the following procedure to note an issue related to a rebate claim:

- Click Issue Detected.

- Enter details about the issue in the Comments field of the Issue Comments dialog.

- Click OK. To close the dialog without saving the comment, click Cancel.

Canceling Rebate Claims

Use the following procedure to cancel a rebate claim:

- Click Cancel.

- Select the Cancel Reason on the Cancel Rebate Claim dialog.

- Click OK. To close the dialog without cancelling the rebate claim, click Cancel.

Adding Rebate Claims

You can also add rebate claims from the Rebate Claim Query portal. Use the following procedure to add a rebate claim:

- Select Main Menu, Customer Information, Rebate Claim + or click Add on the title bar of the Rebate Claim Search zone. The user is navigated to Control Central to select the customer filling the rebate claim. Click Continue once the correct account is in context.

- Select the Conservation Program associated with the rebate claim and click OK.

- Complete the Rebate Claim details, including:

- Claim Date for the rebate claim

- Customer Details

- Contact Details

- Premise Information

- Payment Release Authorization Details

- Click Save. The rebate claim is displayed on the Rebate Claim portal.

- Edit the claim as needed in the Rebate Claim zone.

- Add claim lines to the claim using the Rebate Claim Line zone.

Rebate Claim Line Zone

You use the Rebate Claim Line zone to add, view, and edit rebate claim lines associated with a rebate claim. A rebate claim can have one or more claim lines, one for each item for which a rebate is requested. For example, if a customer purchases new energy efficient appliances (such as a washing machine and dryer), the rebate claim they submit would have a rebate claim line for each appliance. The Rebate Claim Line zone displays the following details for each claim line:

- Rebate Definition

- Manufacturer/Model

- Rebate Amount

- Icons to Edit, Delete, and Verify claim lines

Contents

Adding Rebate Claim Lines

Editing Rebate Claim Lines

Deleting Rebate Claim Lines

Verifying Rebate Claim Lines

Adding Rebate Claim Lines

Use the following procedure to add a rebate claim line to a rebate claim:

- Click Add Rebate Claim Line in the title bar of the Rebate Claim Line zone.

- Select the Service Agreement associated with the claim line from the drop-down list.

- Select the Rebate Definition for the claim line from the drop-down list. This list is filtered based on the Conservation Program associated with the rebate claim.

- Select the Manufacturer/Model for the claim line from the drop-down list. This list is filtered by the Rebate Definition selected.

- Enter the Install Date for the claim line.

- Enter the Number of Units being claimed.

- Click Save. To return to the Rebate Claim Line zone without adding the claim line, click Cancel.

Deleting Rebate Claim Lines

Use the following procedure to delete a rebate claim line from a rebate claim:

- Click the delete icon for the claim line you wish to delete.

- Click OK on the Confirm Delete dialog. To close the dialog without deleting the claim line, click Cancel.

Note:

You can delete a rebate claim line only when the rebate claim is in Pending status.

Editing Rebate Claim Lines

Use the following procedure to edit an existing rebate claim line on a rebate claim:

- Click the edit icon for the claim line you wish to edit.

- Edit the details of the claim line as appropriate.

- If you are revising the data based on updated information, check the Data Revised checkbox and select the reason for the revision from the Data Revised Reason drop-down list. The Original Data Details section displays the data originally entered for the claim line.

- If the claim line contained bad data, check the Bad Line checkbox and select the reason for the revision from the Bad Line Reason drop-down list. The Original Data Details section displays the data originally entered for the claim line.

- Click Save. To return to the Rebate Claim Line zone without changing the claim line, click Cancel.

Note:

You can edit a rebate claim line only when the rebate claim is in Pending status. In addition, you cannot edit a rebate claim line after it has been verified.

Verifying Rebate Claim Lines

Use the following procedure to verify a rebate claim line on a rebate claim:

- Click the Verify button for the claim line you wish to verify.

- Verify that the details of the claim line match the submitted receipts.

- Click Verify. To return to the Rebate Claim Line zone without adding the claim line, click Cancel.

Note:

You cannot edit a rebate claim line after it has been verified.

Rebate Claim Log Zone

This is a standard log zone. You use the Rebate Claim Log zone to view logging details associated with a rebate claim.

Adding Rebate Claim Log Entries

Use the following procedure to add a rebate claim log entry:

- Click Add Log Entry in the title bar of the Rebate Claim Log zone.

- Enter the log entry details in the Add Rebate Claim User Log dialog.

- Click OK. To close the dialog without saving the log entry, click Cancel.

New Rate Engine

This chapter describes a new rate engine. Version 2.4 of CCB introduces a new rate engine that has many features designed to simplify the definition and maintenance of your rates. Probably the most significant feature is the ability to group common calculation rules into reusable calculation groups that can be executed by any rate. For example, if several rates have the same taxation calculations, you can create a single calculation group that contains the common taxation calculations and then simply reference this group in all rates that share the same taxation calculations. This functionality results in less initial set up because common pricing rules are not repeated in your rates. In addition, this lack of redundancy simplifies future changes as any changes need to be made only once (to the calculation group that encapsulates the rules).

Note: This chapter describes the new rate engine and assumes you are familiar with the concepts of rate schedules and related components used with the original rate engine described in the Rates chapter.

Note: In this chapter, rate schedules created using the original rate engine are referred to as Classic rate schedules and those created using the new rate engine are referred to as New Style rate schedules.

Contents:

Understanding New Style Rate Schedules

Understanding Calculation Groups and Rules

Designing Calculation Groups and Rules

Working with Calculation Groups and Rules

Creating New Style Rate Schedules

Base Package Calculation Rule Descriptions

Calculation Rules

Rate Check - New Style

Understanding New Style Rate Schedules

This section provides an overview of New Style rate schedules and how they are defined in the system. Later sections of this document provide details concerning how to create and maintain rate schedules used with the new rate engine.

Overview

New Style rate schedules function in largely the same manner as Classic rate schedules, and include the same types of elements as Classic rate schedules. One of the primary differences between Classic and New Style rate schedules is in the relationships between those elements.

The basic components used to calculate charges in Classic rate schedules are Rate Components. In the new rate engine, rate components have been replaced by Calculation Rules. Each calculation rule is configured to perform a specific type of calculation, such as calculating the number of days in a billing period, the amount of consumption used by a customer in a billing period, tax charges, etc.

Calculation rules are grouped together into Calculation Groups. These are logical groupings of calculation rules that can be referenced by rate schedules. Whereas rate components are specific to a particular rate version in Classic rate schedules, calculation rules and groups are more "generic" and can be applied to multiple rates.

Calculation groups can be also be "nested" within other calculation rules. When the "parent" rule is executed, it in turn executes all the rules nested in its referenced group. This allows a single rule to execute any number of nested rules.

This allows calculations common to multiple rates to be encapsulated into a set of calculation rules that can be included in each of the rates to which they apply.

Calculation groups are defined for a New Style rate schedule in one of three ways:

- Pre-processing calculations, similar to the types of calculations performed by SQ Rules or Register Rules in classic rate schedules are performed via Pre-Processing Calculation Groups in new style rate schedules.

- Rate versions are now a component of rate schedules. The individual calculations performed by rate components in classic rate schedules are performed by Rate Version Calculation Groups in new style rate schedules.

- Any calculations to be performed after the rate version calculations are performed by Post-Processing Calculation Groups in new style rate schedules.

Rate Schedule Data Model: Old vs. New

New Style rate schedules utilize the same basic data model as Classic rate schedules, with only a few changes.

- There is a Rate Engine Version flag (RS_VERSION_FLG) on the Rate Schedule table to designate if a rate schedule is "V1 Rate Engine" (C1V1) or "V2 Rate Engine" (C1V2).
Note: All New Style rate schedules are "Primary" rate schedules. New Style rate schedules cannot be "Secondary" rate schedules.

- There are new tables used to store Calculation Groups and Calculation Rules (Calculation Groups are the parents of Calculation Rules).

- There are three new tables used to store the specific calculation groups referenced by new style rate schedules: Rate Versions, Pre-Processing, and Post-Processing (Both the Rate Schedule and Calculation Group tables are parents of these tables).

- The original Rate Version and Rate Component tables are not used by new style rate schedules.

Refer to the Data Dictionary in the Application Viewer for more details about the database tables and columns used by the new rate engine.

Rate Schedules: Classic vs. New Style

The elements and data used with New Style rate schedules correspond to data and objects used by Classic rate schedules. The table below outlines how each element used with Classic rate schedules maps to concepts used with New Style rate schedules.

Classic Rates Schedules

New Style Rates Schedules

Rate Schedule

Rate Schedule

Rate Version

Rate Versions Calculation Groups

Rate Components

Calculation Rules

SQ Rules

Pre-Processing Calculation Groups

Register Rules

Pre-Processing Calculation Groups

Meter Configuration Types

Meter Configuration Types

Bill Messages

Bill Messages

Note that Bill Factors, Bill Factor Values, and BF Interval Values can be referenced by calculation rules, in a manner similar to how they are referenced by rate components in Classic style rate schedules. See the Rates chapter for more information about Bill Factors, Bill Factor Values, and BF Interval Values.

See Base Package Calculation Rule Descriptions for more information about referencing Bill Factors, Bill Factor Values, and BF Interval Values in Calculation Rules.

Rates Schedule Execution: Old vs. New

This section outlines how New Style rate schedules are executed when creating bill segments for a customer's service agreements.

Classic and New Style Rate Schedules for a Single Customer

A customer's service agreements can reference both Classic and New Style rate schedules. For example, a customer could have an existing service agreement for their gas service which references a Classic rate schedule, and add a new service agreement for electric service that references a New Style rate schedule. When the system calculates the customer's bill, it processes the rate based on the type of rate associated with each of the customer's service agreements. In the example above, when creating the bill segment for the customer's gas service, the system would use the original rate engine, but when creating the bill segment for the customer's electric service, it would use the new rate engine.

New Style Rate Schedule Execution

When a New Style rate schedule is executed, the system executes the calculation rules contained in the calculation groups defined for the rate schedule as follows:

1. First, the system executes the calculation rules defined within Pre-Processing Calculation Groups.

- The rate engine creates a bill segment calculation header for pre-processing calculations.

- Calculation groups are executed in order according to the Sequence defined on the rate schedule.

- Calculation rules within each group are executed according to the Sequence configured within the group.

2. Next, the system executes the calculation rules within the Rate Version Calculation Groups. The system uses the Effective Date on each calculation group to determine which group(s) to execute. If more than one version of a calculation group is in effect during the billing period, the system may prorate the calculations, based on the configuration of the rate schedule.

- The rate engine creates a separate bill segment calculation header for rate version calculations.

- Calculation rules within each group are executed according to the Sequence configured within the group.

3. Finally, the system executes the calculation rules defined within Post-Processing Calculation Groups.

- The rate engine creates a separate bill segment calculation header for post-processing calculations.

- Calculation groups are executed in order according to the Sequence defined on the rate schedule.

- Calculation rules within each group are executed according to the Sequence configured within the group.

Understanding Calculation Groups and Rules

This section provides descriptions of calculation groups and calculation rules, and describes how to identify components of rates that can be defined using calculation rules and groups.

About Calculation Groups and Rules

This section includes descriptions of calculation groups and calculation rules.

About Calculation Groups

Calculation groups are collections of calculation rules that are applied to calculate billing charges for service agreements.

As noted previously, calculation groups are associated with specific rate schedules in one of three ways:

- Pre-Processing Calculation Groups: These are generally used to derive service quantities or massage measured quantities. These perform a role similar to SQ Rules and Register rules in Classic rate schedules. Some use cases of when a pre-processing calc group might be needed:

- When a rate contains prices for things that aren't measured directly by the customers' meters. For example, if the rate calculates a charge based on a service agreement's contracted quantity.

- When a meter measures something in a unit of measure that has to be converted into a different unit of measure before it can be rated. For example, a meter measures gas in cubic feet, but the rate contains prices in therms.
During billing, a separate bill segment calculation header is produced for each Rate Version Calculation Group used to calculate charges. An additional calc header is added if Pre-Processing Calculation Groups create bill calc lines and by default, all these calc lines are linked to a single calc header. Before invoking the rate's Pre-Processing Calculation Groups, the rate engine processor builds the initial service quantity (SQ) collection based on the item collection and final values in the read collection.

- Rate Version Calculation Groups: These are the calculation groups used create a bill segment for the service agreement. When the system creates a bill segment for a service agreement, it checks if multiple Rate Version Calculation Groups are in effect during the bill period. If so, it uses the rate's Allow RV Proration and RV Selection Date values to determine if it should prorate the various Rate Version Calculation Groups, or if it should pick one of the Rate Version Calculation Groups effective during the bill period. Rate Version Calculation Groups are executed after the rate's pre-processing calc groups.

- Effective Date: defines the date on which each rate version calc group becomes effective.

- Description on Bill: Specifies the description of the rate version on the bill. This description is saved on bill calculation details created using this rate version. Substitution characters may be used to substitute variables into the description during billing. Refer to How To Use Description on Bill in the Rates chapter for a discussion of the various substitution variables.

- Post-Processing Calculation Groups: These are similar to Pre-Processing Calculation Groups, except that these are executed after the Rate Version Calculation Groups. The intended types of functionality include applying taxes on calculated charges, or deriving more complex GL distribution.
During billing, a separate bill segment calculation header is produced for each Rate Version Calculation Group used to calculate charges. An additional calc header is added if Post-Processing Calculation Groups create bill calc lines and by default, all these calc lines are linked to a single calc header.

Calculation groups can also be referenced by "Execute Calculation Group" calculation rules. See "Execute Calculation Group Rules - Nesting Calculation Rules" in About Calculation Rules for more information.

About Calculation Rules

Calculation rules are standard and custom rules that perform calculations used when calculating billing charges for a customer's service agreements.

Calculation rules are created for a specific calculation group. For example, if you were configuring two calculation groups and both included a specific calculation rule, you would need to create two instances of the calculation rule, one for each group.

Attributes used to define calculation rules typically include the following:

- Basic Information: Basic information about the calculation rule, including its name and description, the calculation group to which the rule belongs, the sequence of the rule within the group, the description that appears on the bill, and other information. This information is standard for most calculation rules.

- Parameters: The parameters used by the rule. Parameters are specific to each rule. See Base Package Calculation Rule Descriptions for details about the calculation rules included with the base package.

Execute Calculation Group Rules - Nesting Calculation Rules

Execute Calculation Group rules are used to define business logic to allow reference to a separated specified calculation group. This allows rules that are used frequently to be bunched under a single calculation group, which can be referenced / called by other rules as needed. For example, if a set of standard rules should be applied to all rate schedules, this set of rules can be configured as part of a calculation group, which is referenced by a single calculation rule of this type. Execute Calculation Group rules use the following options:

- Referred Calculation Group: defines the calculation group referenced by the rule.

- Characteristics: defines additional calculation rule attributes that may be used in rate processing or for reporting purposes. A calculation rule's characteristics are copied onto the resultant bill lines for those characteristic types that are allowed on bill segment calculation lines.

Eligibility Criteria

Calculation rule eligibility criteria are user-definable conditions that could cause a given calculation rule to be applied or skipped. This can involve the evaluation of some attribute of the service agreement, or service point, or something else entirely.

A calculation rule can have multiple eligibility criteria for determining if the rule should be applied or skipped, based on a user-defined sequence. Each eligibility criteria uses the following settings:

- Criteria Comparison: defines the specific comparison for the criteria, based on the following:

- Criteria Field Type: the means used to retrieve the value of the criteria field (algorithm, bill factor, calculation line, characteristic, contract quantity, service quantity, or historic service quantity)

- Comparison Operator: the operator used in the comparison

- Comparison Value: a user-specified value to which the retrieved value is compared (using the comparison operator)

- Comparison Results: defines how the rule should behave, based on the results of the comparison defined under Criteria Comparison:

- If True: the action to take if the comparison is true

- If False: the action to take if the comparison is false

- If Insufficient Data: the action to take if there is insufficient data to perform the comparison

Calculation Line Category Types

Calculation line category types are used to establish connections between calculation rules. Calculation rules can specify a member category and value to which they belong. When this same category and value are referenced as a "Target Category" by other rules (the rule is applied to the results of rate version calculation rules (defined in the same rate schedule) that belong to the category and value.

For example, calculation rules whose results are subject to taxes might belong to the "Subject to Tax" (TAXABLE) category and "County Tax" value. "Apply To" calculation rules defined for the same rate schedule with a target category of "Subject to Tax" and "County Tax" values are applied to "Subject to Tax" member rules.

Calculation Line Category Types are defined by the following:

- Calculation Line Category Type: The unique identifier of a calculation line category type definition

- Description: The description of the calculation line category type.

- Category Values: The valid category values for the calculation line category type.

Base Package Calculation Rules

Oracle Utilities Customer Care and Billing includes the following base package calculation rule types that can be used when creating calculation rules:

- Apply To : Used to create bill lines that levy charges based on amounts calculated on other bill lines.

- Calculate Final Reading Values : Used to determine the final values for readings based on user-defined UOM/TOU/SQI.

- Calculate Service Quantity : Used to derive or calculate a service quantity that is eventually inserted into the bill segment SQ collection.

- Flat Charge : Used to create bill lines that levy service charges and fees that aren't based on how much the customer uses.

- Item Type : Used to create bill lines that levy charges based on the number and type of items used by a customer. The system keeps track of items on the service point(s) linked to the customer's service agreement.

- Math : Used to derive interval data based on a formula, and apply TOU mappings and/or other operations to the derived data to calculate service quantities

- Maximum Charge : Used to create bill lines that levy charges only when the sum of previously calculated lines is more than the maximum charge amount.

- Minimum Charge : Used to create bill lines that levy charges only when the sum of previously calculated lines is less than the minimum charge amount.

- Service Quantity : Used to create bill lines that levy charges based on some type of consumption.

- Simple Summary : Used to create a "subtotal" on the bil, by summarizing bill lines produced by other calculation rules in the same calculation group.

- Stepped Service Quantity : Used to create bill lines that levy charges based on some type of consumption when different prices are applied to different ranges of consumption (for example, the first 50 kWh are $0.43 per kWh, anything in excess of 50 kWh is charged at $0.71 per kWh)

- Summary : Used to create a "subtotal" on the bill. It exists purely for reporting and informational purposes.

See Base Package Calculation Rule Descriptions for details about each of these calculation rules.

Designing Calculation Groups and Rules

Before starting to design calculation groups and rules for your rates, please review the concepts outlines in the Designing Rate Components section in the Rates chapter. That section provides a good background for understanding how to break down rates into component pieces that can be modeled by calculation groups and rules.

This section provides guidelines for how to design and plan the calculation groups and rules you will need for your rates, and provides a simple case study of how to define the calculation rules and groups you might use for a set of rates for a small municipal electric company.

Analyzing Your Rates and Identifying Calculation Rules and Groups

As outlined in the Rate Component Design Methodology section of the Rates chapter, one of the steps you will go through when implementing your rates is to look at the bill lines for your rates and ask yourself what are the variables that cause each line's charges to be calculated the way they are. After you've determined all of the potential bill lines you can start designing your calculation groups and rules. Typically you create one calculation rule for every line that can appear on the customer's bill. These rules can be grouped in different configurations based on how you want your bills to appear and the needs of your implementation. Recall that bill segment calc headers are created for Pre-Processing, Rate Version, and Post-Processing calculation groups. In addition, most rules can be configured generate a bill line.

General Guidelines

When designing calculation groups and rules, the following general guidelines apply:

- Any processing that would be performed by SQ Rules and Meter Register Rules should be performed by Pre-Processing Calculation Groups. This can include:

- Calculating the number of days in a billing period (Calculate Service Quantity)

- Calculating service quantities that are not measured (demand, kVa, etc.) (Calculate Final Reading Values, Calculate Service Quantity, Math)

- Validating that consumption is within tolerances set by the rate (residential limits, etc.) (Calculate Service Quantity, with eligibility criteria)

- Calculations processed by rate components configured for a rate version should be performed by Rate Version Calculation Groups. This includes most charge calculations, including:

- Charges based on service quantities (Service Quantity, Stepped Service Quantity)

- Customer charges (Flat Charge)

- Minimum/maximum charges (Minimum Charge, Maximum Charge)

- Discounts (Apply To)

- Taxes (Apply To)

- Summaries (Summary, Simple Summary)

- Additional processing should be performed by Post-Processing Calculation Groups. This can include:

- Allocating consumption/revenue (energy revenue vs. demand revenue) (Service Quantity)

Example Configurations

Let's look at a couple of different possible configurations for a simple electric rate that includes the following:

- Customer Charge

- Service Charge (price per kWh)

- Minimum Charge

- Discount

This rate could be set up in the following ways:

- A single Rate Version calculation group that contains a calculation rule for each of the above

- A set of Rate Version calculation groups as follows:

- A calculation group for "flat" charges, such as the Customer Charge

- A calculation group for consumption-based charges (including the Service Charge and Minimum Charge).

- A calculation group for discounts or other charges applied to the total of other charges (which would include the Discount)

There are no hard and fast rules concerning how calculation rules should be grouped. How this is done should be based on the specific needs of the implementation but it's a good idea to look for ways to keep your configuration simple for maintenance and upkeep purposes. This includes changes to existing rates as well as adding/removing rates over time.

Re-Using Calculation Rules

One of the most important differences between the original and new rating engines is that the new rating engine allows you to re-use calculation groups and rules across multiple rate schedules.

With Classic rate schedules, if multiple rates shared a type of charge or adjustment, such as a charges based on taxes or a discount, you would have to configure a rate component on each rate separately. For example, if you have ten rates, all of which have the same City, County, and State taxes applied to then, you would have to configure the same three rate components (one for each of State, County, and City taxes) on all ten rates. This is not only time-consuming when initial configuring your rates, but can make maintenance and update more complicated. If any of those tax calculations were to change at some point, you would have to update the applicable rate component in all ten rates.

With New Style rate schedules, you can reference the same calculation rules and groups in multiple different rates. For example, in the example above, the tax charges could be implemented as three calculation rules (one for each of State, County, and City taxes), and grouped in a single calculation group, which in turn could be referenced on all ten rates.

Identifying Rate Components that can be Shared/Re-Used

As you analyze the bill lines used by your rates, you should look for bill lines that utilize similar or identical variables or calculations. These calculations are candidates for re-use. For example, if all of your residential rates offer a discount for early payment, you would want to create a single rule to calculate that discount, and then use it each of the rates to which it applies.

How to Re-Use Calculation Rules

There are two approaches that can be used to re-use calculation rules.

- Encapsulating Rules in a Calculation Group
This approach involves grouping rules that can be applied to more than one rate into a single calculation group. You would use this approach when you identify charges and other components in your rates that apply to multiple rates, but that can be grouped together. Taxes for multiple types of jurisdictions (State, County, and City, for example) would be suitable for this approach.

To use this approach, you simply create a calculation group that contains the rules to be applied to more than one rate. For the tax example, you might create the following group and rules:

Calculation Group: Taxes, which includes:

Calculation Rule: State Tax (Apply To)

Calculation Rule: County Tax (Apply To)

Calculation Rule: City Tax (Apply To)

This "Taxes" calculation group can be included as a Rate Version Calculation Group in each of the rates to which the taxes apply. This calculation group could also be referenced by an "Execute Calculation Group" rule, as outlined below.

- Using "Execute Calculation Group" Rules
This approach involves creating a calculation group that contains one or more rules, which is then referenced by another "Execute Calculation Group" rule. This approach can be used when you identify a charge or calculation that could be applicable within one or more calculation groups. For example, if multiple rates involve calculating peak demand (or some other quantity that is not measured by your customers' meters), you could create a "Calculate Demand" rule and include it in a group that is then referenced by an "Execute Calculation Group" rule.

To use this approach, you create a calculation group that contains the calculation rules to be used within multiple calculation groups. You then create an "Execute Calculation Group" rule that references the group. Last, you include this "Execute Calculation Group" rule in the calculation groups to which it applies. For the calculate demand example, you might create the following:

Calculation Rule: Calculate Demand (Execute Calculation Group), which references:

Calculation Group: Calculate Demand, which includes:

Calculation Rule: Calculate Demand (Calculate Service Quantity)

The "Calculate Demand" Execute Calculation Group rule can be included in any calculation group used to calculate service quantities that includes calculating peak demand.

"Execute Calculation Group" rules can be used with any calculation group. To return the taxes example from above, if you wanted to include your "Taxes" calculation group within other groups, you could use the following:

Calculation Rule: Taxes (Execute Calculation Group), which references:

"> Calculation Group: Taxes, which includes:

Calculation Rule: State Tax (Apply To)

Calculation Rule: County Tax (Apply To)

Calculation Rule: City Tax (Apply To)

See "Execute Calculation Group Rules - Nesting Calculation Rules" in About Calculation Rules for more information about Execute Calculation Group rules.

Leveraging Eligibility Criteria to Dynamically Apply Calculation Rules

Another tool to consider when creating your calculation groups and rules is Eligibility Criteria. Eligibility criteria allow you to define rules that determine the conditions under which a calculation rule is applied or not.

For example, if you need to calculate demand for one or more of your rates, you might create separate calculation rules to calculate demand based on interval values of different units of measure (kWh vs kVarh for instance). You could create rules for each and include them in a single "Calculate Demand" calculation group, but assign eligibility criteria to each such that they are only executed when processing for the specified unit of measure.

See "Eligibility Criteria" in About Calculation Rules for more information about eligibility criteria and how they can be used with calculation rules. In addition, refer to The Big Picture of Rate Component Eligibility Rules in the Rates chapter for additional background on eligibility criteria.

Case Study: Three Sample Rates

Let's look at a sample set of rates, and how they might be implemented using a New Style rate schedule and calculation groups and rules. We'll also look at which components of these rates can be shared.

Rates

The following rates are electric rates offered by a small municipal electric company.

Rate

Domestic Rate A

Commercial Rate B

Power Rate C

Cost of Service

Stepped charges, as follows: $3.08 for the first 10 kWh or less, plus 19.23 cents per kWh for the next 40 kWh, plus 15.44 cents per kWh for the next 150 kWh, plus 14.93 cents per kWh for the next 300 kWh, plus 14.71 cents per kWh for all kWh in excess of 500 kWh

Stepped charges, as follows: $2.95 for the first 10 kWh or less, plus 19.23 cents per kWh for the next 40 kWh, plus 18.85 cents per kWh for the next 50 kWh, plus 16.86 cents per kWh for the next 400 kWh, plus 15,45 cents per kWh for the next 3,000 kWh, plus 14.87 cents per kWh for all kWh in excess of 3,500 kWh.

1. Customer Charge:$52.00 2. Demand: $11.44 per KW 3. Energy: $11.28 cents per KWH
Billing Demand
The Billing Demand for any month shall be the greater of the following: 1. The maximum 15 minute measured demand during the month as measured in kilowatts, or 2. 70% of the maximum 15 minute measured demand as so determined during the preceding 11 months.

Discount

Discount of ½ cent per kilowatt hour after the first 10 kilowatt hours, if paid on or before the discount expiration date. For qualifying elderly residents, an additional 10% discount is allowed on the basic rate if paid on or before the discount expiration date and no arrears exist on their accounts.

Discount of ½ cent per kilowatt hour after the first 10 kilowatt hours, if paid on or before the discount expiration date.

Discount of 10% exclusive of purchased power and fuel adjustment charge paid on or before the discount expiration date.

Purchased Power and Fuel Adjustment

An upward or downward adjustment applied to all kWh sold, based on the total cost of purchased power and fuel compared to the portion of that cost contained in the base rate (11.615 cents/kWh). The purchase power and fuel adjustment shall be rounded to the sixth decimal place and shall be applied to all kilowatt hours sold in the following month.

See Domestic Rate A

See Domestic Rate A

Misc.

N/A

N/A

Minimum Bill The Customer Charge

Taxes

State, County, and City Taxes

State, County, and City Taxes

State, County, and City Taxes

Calculation Rules

Now let's look at these same rates in terms of how we might implement them using calculation rules. The table below lists the type of calculation rule used for each item on the rate.

Rate

Domestic Rate A

Commercial Rate B

Power Rate C

Cost of Service

Stepped Charges:

- Stepped Service Quantity rule

- Minimum Charge rule (note that the first tier is a fixed price for the first 10 kWh or less)

Stepped Charges:

- Stepped Service Quantity rule

- Minimum Charge rule (note that the first tier is a fixed price for the first 10 kWh or less)

Customer Charge:

- Flat Charge rule

Demand:

- Service Quantity rule

- Math rule (to calculate demand from interval values)*

Energy:

- Service Quantity rule

*Could be included in either a Pre-Processing or Rate Version group

Discount

Discount:

- Apply To rule

Elderly Discount:

- Apply To rule

Discount:

- Apply To rule

Discount:

- Apply To rule

Purchased Power and Fuel Adjustment

PPF Adjustment:

- Service Quantity rule

Note:
The PPF adjustment rate would be defined as a Bill Factor, updated monthly based on the prior month's total cost.

PPF Adjustment:

- Service Quantity rule

PPF Adjustment:

- Service Quantity rule

Misc.

N/A

N/A

Minimum Bill:

- Minimum Charge rule

Taxes

State, County, and City Taxes:

- Apply To rule (one for each type of tax)

State, County, and City Taxes:

- Apply To rule (one for each type of tax)

State, County, and City Taxes:

- Apply To rule (one for each type of tax)

Shared Components:

Now, let's look at the components of these rates that can be shared.

Discounts: Rates A &B both use the same discount, so we could create a single "AB Discount" calculation rule that could be used with both rates. Note that this could be either in its own calculation group that is listed among the Rate Version groups for each rate, or the group could be referenced by an "Execute Calculation Group" rule which in turn would be included in one of the other Rate Version groups used in each rate.

Purchased Power & Fuel Adjustment: Rates A, B, and C all use the same adjustment for purchased power and fuel, so we could create a single "PPF Adjustment" calculation rule that could be used with all three rates. Again, this rule could be in its own calculation group listed on the rate, or in a group referenced by an "Execute Calculation Group" rule included in another group.

Taxes: Rates A, B, and C are all subject to the same taxes, so we could create calculation rules for each type of tax (State, County, and City) in a single group that could be used with all three rates. Again, these rules could be in their own calculation group listed on the rate, or in a group referenced by an "Execute Calculation Group" rule included in another group.

Working with Calculation Groups and Rules

This section outlines how users work with calculation groups and calculation rules.

Defining Calculation Groups

Use this procedure to define calculation groups.

- Select Main Menu, Rates, Calculation Group+.

- Enter a Name for the calculation group.

- Enter a short Description and Detailed Description for the group.

- Click Save.

To add a calculation rule to the calculation group, click the Add Rule link in the Calculation Rules List zone title bar. See Defining Calculation Rules for more information about creating calculation rules.

You can now create calculation rules for this group.

See About Calculation Groups for more information about calculation groups.

Searching and Maintaining Calculation Groups

Use this procedure to search for and maintain calculation groups.

- Select Main Menu, Rates, Calculation Group.

- Enter your search criteria.
You can search by Calculation Group name or Description.

- Click Refresh.

- In the search results list, click the Description link for the calculation group you want to view or edit.
The selected calculation group is displayed in the Calculation Group portal. You use this portal to maintain calculation groups. This portal includes the following zones:

- Calculation Group: Defines basic information about calculation group

- Calculation Rules List: lists the calculation rules belonging to the group. Eligibility criteria referenced by a calculation rule are listed indented beneath each rule. If a calculation rule in turn references a calculation group, the calculation group executed by the rule is displayed.

- Referencing Rates Schedules List: lists the rates schedules that reference the group

- Referencing Calculation Rules List: lists the calculation rules that reference the group

Use this procedure to maintain a calculation group:

- Select Main Menu, Rates, Calculation Group to navigate to the Calculation Group Query portal.

- Search for and select the appropriate calculation group.

- Click Edit, Delete, or Duplicate as appropriate.

- To add a calculation rule to the calculation group, click the Add Rule link in the Calculation Rules List zone title bar. See Defining Calculation Rules for more information about creating calculation rules.

- To update the sequence values for all calculation rules in the group, click the Resequence All Rules link in the Calculation Rules List zone title bar.

- Edit the sequence values for all rules by specifying new Start Sequence and Increment By values.

- Click OK to update the calculation rules with new sequence numbers.

- To Edit or Delete a specific calculation rule in the group, select the Edit or Delete icon in the Calculation Rules List zone as appropriate.

- To Delete one or more of the calculation rules in the group:

- Select one or more of the calculation rules you want to delete.

- Click Delete Calc Rules.

- Click OK to delete the selected calculation rules

- To update the bill print details for one or more of the calculation rules in the group:

- Select one or more of the calculation rules for which you want to change the bill print details.

- Click Update Bill Print.

- Edit the bill print details for the selected calculation rules.

- Click Save to update the selected calculation rules with the new bill print details.

- To change the sequence values for one or more of the calculation rules in the group:

- Select one or more of the calculation rules for which you want to change the sequence values.

- Click Resequence Rules.

- Edit the sequence values for all the selected calculation rules.

- Click Save to update the selected calculation rules with the new sequence values.

See About Calculation Groups for more information about calculation groups.

Defining Calculation Line Category Types

Use this procedure to define calculation line category types.

- Select Main Menu, Rates, Calculation Line Category Type+.

- Enter a Category Type name for the category type.

- Enter a short Description and Detailed Description for the category type.

- Define the Category Value and Description for each value for the category type.

- Click Save.

You can now reference this category and its values as either the Member Category or Target Category on calculation rules.

See "Calculation Line Category Types" in About Calculation Rules for more information about calculation line category types.

Maintaining Calculation Line Category Types

Use this procedure to search for and maintain calculation line category types.

- Select Main Menu, Rates, Calculation Line Category Type.
The Calculation Line Category Type List zone displays the calculation line category types defined in the system.

- Click the broadcast icon for the calculation line category type you wish to view and/or edit.
The selected calculation line category type is displayed in the Calculation Line Category Type zone.

- Click Edit, Delete, or Duplicate as appropriate.

See "Calculation Line Category Types" in About Calculation Rules for more information about calculation line category types.

Defining Calculation Rules

Use this procedure to define calculation rules.

- Select Main Menu, Rates, Calculation Rule+.

- Select the Calculation Group to which the rule will belong.

- Select the Calculation Rule BO for the calculation rule.
Refer to Base Package Calculation Rule Descriptions for detailed descriptions of the available calculation rules and their associated business objects.

- Enter name for the Calculation Rule.

- Enter the Sequence for the rule. This designates the order in which the rule will be executed within its parent calculation group.

- Enter a short Description and Detailed Description for the rule.

- Enter or select other parameters for the rule as appropriate.
Refer to Base Package Calculation Rule Descriptions for detailed descriptions of the available calculation rules and the parameters used by each.

- Click Save.

See About Calculation Rules for more information about calculation rules.

Searching and Maintaining Calculation Rules

Use this procedure to search for and maintain calculation rules.

- Select Main Menu, Rates, Calculation Rule.

- Enter your search criteria.
Available query options include Calculation Rule and Calculation Rule BO.

- When searching by Calculation Rule, you can search by Calculation Group, Calculation Rule name, or Description.

- When searching by Calculation Rule BO, you can search by Business Object, or Description.

- Click Refresh.

- In the search results list, click the Description link for the calculation rule you want to view or edit. To navigate to the rule's calculation group, click the Calculation Group link.
The selected calculation rule is displayed in the Calculation Rule portal. You use this portal to maintain calculation rules. This portal includes the following zones:

- Calculation Rule: Defines basic information about calculation rule

- Eligibility Criteria List: Lists optional eligibility criteria for the current calculation rule. Eligibility criteria are used to determine whether a calculation rule should be applied (or skipped) during rate processing.

Use this procedure to maintain a calculation rule:

- Select Main Menu, Rates, Calculation Rule to navigate to the Calculation Rule Query portal.

- Search for and select the appropriate calculation rule.

- Click Edit, Delete, or Duplicate as appropriate.

- To define eligibility criteria for the rule, click the Add link in the Eligibility Criteria List zone title bar. See "Eligibility Criteria" in About Calculation Rules for more information.

See About Calculation Rules for more information about calculation rules.

Defining Calculation Rule Eligibility Criteria

Use this procedure to define eligibility criteria for a calculation rule.

Prerequisites: You must create a calculation rule before you can define eligibility criteria.

- Click the Add link in the Eligibility Criteria List zone title bar.

- Enter a Sequence number, Description, and Detailed Description for the criteria.

- Complete the Criteria Comparison section as follows:

- Criteria Field: the means used to retrieve the value of the criteria field (algorithm, bill factor, calculation line, characteristic, contract quantity, service quantity, or historic service quantity)

- Comparison Operator: the operator used in the comparison

- Value: a user-specified value to which the retrieved value is compared (using the comparison operator)

- Complete the Comparison Results section as follows:

- If True: the action to take if the comparison is true

- If False: the action to take if the comparison is false

- If Insufficient Data: the action to take if there is insufficient data to perform the comparison

- Click Save.

See "Eligibility Criteria" in About Calculation Rules for more information about calculation rule eligibility criteria.

Creating New Style Rate Schedules

This section outlines how users work with New Style rate schedules.

Administration - Master Configuration

The Rate Engine Configuration master configuration can be used to define the behavior of the Rate Schedule portals used when creating Classic and New Style rate schedules.

To edit this master configuration, select Admin Menu, M, Master Configuration, and click the edit icon for the Rate Engine Configuration.

The Rate Engine Implementation drop-down list defines which rate engine(s) will be used by your organization. Note that if your implementation uses only the classic rate engine, then an instance of this master configuration is not required.

- Classic indicates that your implementation uses the original rating engine that requires the configuration of rate versions with rate components, and Classic rate schedules with SQ and register rules.

- New indicates that your implementation uses the new rating engine that requires the configuration of New Style rate schedules with calculation groups and calculation rules.

- Both indicates that your implementation has a combination of both rate schedule types configured. If this applies to you then the system will use this option to ease navigation as follows:

- Selecting Rate Schedule + from the Main Menu launches the maintenance map for the rate schedule business object displayed on the master configuration (which is defined an option on the Rate Schedule MO). A hyperlink is included to take the user to the classic rate engine rate schedule maintenance page if necessary.

- Selecting Rate Schedule from the Main Menu navigates the user to the Rate Schedule Query portal.

- The query results attempt to highlight old/classic rate schedules by appending additional text to each rate schedule's description.

- Once a rate schedule is selected from the result set, the system navigates the user to either the classic Rate Schedule page or the new Rate Schedule portal depending on the type of rate schedule selected

The External Communication section is used when the rating engine needs to communicate with some external system. For example, service quantities are needed to test a rate on the Rate Check portal. These service quantities may either be entered on the portal, or retrieved from an existing bill segment, or in the case of a service agreement that requires bill determinants, these service quantities can be requested from Oracle Utilities Meter Data Management.

- The Request Type identifies the various data requests that can be made to an external system. Request types are defined in the RATE_EXT_REQ_TYPE_FLG lookup field. To introduce additional request types, add appropriate lookup values to this lookup field for each request type you wish to support.
The base package includes the following business objects to be defined on the outbound message types created for such requests:

- Rate Check Usage: C1-UsageRequestOutMsg (used to request bill determinants from MDM on the rate check portal)

- The External System and Outbound Message Type are used when creating the outbound message for the data request.

Defining New Style Rate Schedules

Use this procedure to define New Style rate schedules.

Prerequisites: You must configure an instance of the Rate Engine Configuration master configuration in order to create and/or maintain New Style rate schedules.

- Select Main Menu, Rates, Rate Schedule+.
The Rate Schedule maintenance screen opens. To navigate to the Classic Rate Schedule page, click Switch to Classic.

- Enter a code for the Rate Schedule.

- Enter a short Description for the rate schedule.

- Select the Service Type (Electric Service, Gas Service, etc.) for the rate schedule.

- Select the Frequency (monthly, quarterly, etc.) for the rate schedule

- Select the Currency Code used with the rate schedule.

- Select whether or not the rate schedule will Allow Estimates when performing calculations.

- Select whether or not the rate schedule will Allow RV Proration when performing calculations.

- Select the RV Proration Date, used if the rate schedule does NOT allow RV proration. Valid options include Accounting Date, Bill End Date, and Bill Start Date.

- Define the Pre-Processing Calculation Groups used by the rate schedule. For each pre-processing calculation group, specify:

- Sequence: The sequence in which the group is executed when the pre-processing groups are processed.

- Description: A description of the calculation group

- Calculation Group: The calculation group.
Refer to About Calculation Groups for more information about Pre-Processing Calculation Groups.

- Define the Rate Version Calculation Groups used by the rate schedule. For each rate version calculation group, specify:

- Effective Date: The date on which each rate version calculation group becomes effective

- Description on Bill: Specifies the description of the rate version on the bill. This description is saved on bill calculation details created using this rate version. Substitution characters may be used to substitute variables into the description during billing. Refer to How To Use Description on Bill in the Rates chapter for a discussion of the various substitution variables.

- Calculation Group: The calculation group.
Refer to About Calculation Groups for more information about Rate Version Calculation Groups.

- Define the Post-Processing Calculation Groups used by the rate schedule. For each post-processing calculation group, specify:

- Sequence: The sequence in which the group is executed when the post-processing groups are processed.

- Description: A description of the calculation group

- Calculation Group: The calculation group.
Refer to About Calculation Groups for more information about Post-Processing Calculation Groups.

- Define one more recommended Meter Configuration Types for meters linked to service agreements (by way of their service points) for the rate schedule.

- Define one or more Bill Messages that should appear on bills that use the rate schedule. For each message, specify

- Bill Message: The message that should appear on the bill.

- The Start Date and End Date when the bill message should appear on the bill. Leave End Date blank if the message should appear indefinitely,

- Click Save.

This rate schedule can now be referenced on service agreements.

See Understanding New Style Rate Schedules for more information about rate schedules used with the new rate engine.

Searching and Maintaining Rate Schedules

Use this procedure to search for and maintain rate schedules.

Prerequisites: You must configure an instance of the Rate Engine Configuration master configuration in order to create and/or maintain New Style rate schedules.

- Select Main Menu, Rates, Rate Schedule.

- Enter your search criteria.
You can search by Rate Schedule, Description, or Rate Engine (Classic or New).

- Click Refresh.

- In the search results list, click the Description link for the rate schedule you want to view or edit.

- If you select a Classic rate schedule, the selected rate schedule is displayed in the (classic) Rate Schedule page. See Setting Up a Rate Schedule in the Rates chapter for more information about using this page.

- If you select a New Style rate schedule, the selected rate schedule is displayed in the (new) Rate Schedule portal. You use this portal to maintain rate schedule. This portal includes the following zones:

- Rate Schedule: Defines basic information about the rate schedule.

- Rate Schedule Tree: Displays the hierarchy of Calculation Groups and Calculation Rules for the Rate Schedule. Only the most recent rate version is initially displayed. In this zone you can:

- Click a calculation group or calculation rule link to go to the Calculation Group or Calculation Rule portal for the associated calculation group or calculation rule.

- Click the Broadcast icon for a calculation rule to open the Cross Reference Rule zone. This zone displays the rate schedule’s calculation rules that are members of the broadcast calculation rule’s target category.

- Click the Show All Rate Versions button to display all rate versions for the rate schedule. This will also display the Show Effective Rate Version button, which you can use to display the information for the most recent rate version.

Use this procedure to maintain a calculation rule:

- Select Main Menu, Rates, Rate Schedule to navigate to the Rate Schedule Query portal.

- Search for and select the appropriate rate schedule.

- If you select a Classic rate schedule, the selected rate schedule is displayed in the (classic) Rate Schedule page. See Setting Up a Rate Schedule in the Rates chapter for more information about using this page.

- If you select a New Style rate schedule, the selected rate schedule is displayed in the (new) Rate Schedule portal.

- Click Edit, Delete, or Duplicate as appropriate.

See Understanding New Style Rate Schedules for more information about rate schedules used with the new rate engine.

Base Package Calculation Rule Descriptions

This section provides detailed descriptions of each of the base package calculation rules provided with Oracle Utilities Customer Care and Billing. The descriptions of the calculation rules below contain the following information

- Rule Name: The name of the rule

- Base Package Calculation Rule Business Object: The base package business object used by the rule

- Apply Calculation Rule Algorithm Type / Algorithm: The base package algorithm type and algorithm specified in the "Apply Calc Rule" system event for the rule

- Rule Parameters: Parameters used to define the rule (if applicable). Does not include common parameters used by all rules (see Common Parameters).

- Example: One or more example configurations of the rule. Note that all examples use default values for all "Apply Calculation Rule Algorithm Parameters".

Common Parameters

All calculation rules use the following common parameters:

- Calculation Group: The calculation group to which the rule belongs

- Calculation Rule: The user-defined name given to the calculation rule

- Sequence: The relative position of the calculation rule in respect of the other rules in the calculation group. This controls the order in which the system performs the calculation.

- Description: A short description of the rule. This is used as the Information String for the rule in the user interface.

- Detailed Description: A detailed description of the rule.

In addition, several of the base package calculation rules also use the following parameters:

- Description On Bill: The text that appears on the bill line generated for this calculation rule. Variables can be used to dynamically generate text (e.g., price and quantity) when billing calculates the charges. Refer to How To Use Description on Bill in the Rates chapter for more information about available substitution variables.

- Print: A flag that specifies (Yes or No) if the bill line created by this calculation rule should appear on the customer's bill. All bill lines are shown on Bill Segment - Calculation Details. However, only those lines marked as Print are presented to the customer.

- Print If Zero: A flag that specifies (Yes or No) if a bill line should be printed if the bill line's value is zero.

- Rounding Type: This flag specifies if the calculated value should be rounded Down, Up, or Nearest. Used with Precision to control how the system rounds the rule's calculated value.

- Precision: This field defaults to a value consistent with the decimal positions defined on the rate schedule's currency code. Used with Rounding Type to control how the system rounds the rule's calculated value.

- FCPO (For Calculation Purposes Only): A flag that indicates if this calculation rule exists purely to calculate a value used by another calculation rule. When set to Yes, the system does not include the calculated amount in the bill total. The following are required when FCPO is set to Yes:

- Create Bill Line: Determines if a bill line should be created for the rule (if there is no need to show the results to the customer or a user, there is no need to create a bill line).

- FCPO Retention Rule: If a bill line created, this defines 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.

- Override Proration: A flag that specifies if an override proration algorithm should be used. This is used in situations when the standard proration logic does not satisfy your requirements. In this case, you may plug in an override proration algorithm to calculate the proration factors required by your implementation. This algorithm can be specified on the calculation rule business object or on the parent calculation rule business object if the override proration applies to all rates.

- Seasonal: A flag that specifies (Yes or No) if charges associated with the calculation rule are only levied during a specific season. If set to "Yes", the following must be specified:

- Season Start: Defines the start of the season for the calculation rule.

- Season End: Defines the end of the season for the calculation rule.

- Seasonal Prorate Method: Defines how the system should prorate a seasonal charge when a bill segment's period is not entirely within the seasonal period. The following options are available:

- Accounting Date, Consumption End Date and Consumption Start Date options will not prorate the charge calculated by the calculation rule. Rather, it will only calculate the charge if the accounting date associated with the bill segment is within the seasonal period, or if the consumption period's end date is within the seasonal period, or if the consumption period's start date is within the seasonal period respectively.

- Prorate will prorate the calculation rule charge based on number of days in the season that is included in the bill period.

- The Prorate Seasonal SQ option is only pertinent if you have:

- Seasonal service quantity (SQ) charges, AND

- Meters that measure seasonal consumption on separate registers, AND

- You have a bill that crosses seasonal boundaries, AND

- You have multiple rate versions effective across the bill period.
If the Prorate Seasonal SQ option is used, the system will prorate the charge calculated by a SQ calculation rule based on the number of days in the season that is included in the rate version's period.

- GL Distribution: If the charge calculated by the calculation rule impacts the general ledger, you must define the distribution code used to construct the GL account.

- Distribution Code Source: Specifies the type of GL distribution to use for this calculation rule.
If the calculation rule's charges should be booked to a single GL account regardless of the service agreement's SA Type's revenue class, select the Specific Distribution Code source and enter a Distribution Code.

If the calculation rule's charges are booked to a different GL account depending on the service agreement's revenue class, select the Revenue Class source and insert the appropriate Revenue Class and Distribution Code for each that uses the rate.

- Cross Reference: Defines the calculation line categories that the resultant calculation details belong to. For example, for a rate that calculates city and state taxes on consumption and demand based charges, the following categories could be used to calculate these taxes:

- A calculation line category type called "Taxable" with a category value for City Tax and another for State Tax.

- Each of the rate's calculation rules used for consumption and demand based charges should define the Member Category(s) that it belongs to ("Taxable - City Tax" and "Taxable - State Tax"). In other words, these rules would be defined as a member of the city tax and state tax categories.

- The "Apply To" rules used to calculate city tax and state tax should define the respective Target Category(s) ("Taxable - City Tax" and "Taxable - State Tax") that they are applied to.
There are two types of cross reference categories:

- Target Category: Specifies the category that the calculation rule targets. Used with "Apply To", "Maximum Charge", and "Minimum Charge" calculation rules.

- Member Category: Specifies the category to which the calculation rule belongs.

- Characteristics: Defines additional calculation rule attributes that may be used in rate processing or for reporting purposes. A calculation rule's characteristics are copied onto the resultant bill lines for those characteristic types that are allowed on bill segment calc lines. You can indicate that “C1-ADDSC” characteristic ad hoc value of a bill line should be substituted into the bill line's description by using the %V substitution variable in the calculation rule's Description On Bill field.

Calculation Rule Validation

All calculation rules are validated when created to ensure they contain proper data needed to perform their calculations. The algorithms used to perform these validations are performed by the algorithms specified in the “Validation” system event on the calculation rule’s business object. Details concerning the validation algorithms and the parameters they used can be viewed using the Application Viewer.

Calculation Rules

This section provides descriptions for the base package calculation rules.

Apply To

Apply To rules create bill lines that levy charges based on amounts calculated on other bill lines. Apply To calculation rules must define the respective target category that they are applied to. The calculation rule(s) that compute charges to which "Apply To" rules will be applied must be defined as members of the target category. See Cross-Reference under Common Parameters for more information about Member and Target categories.

- Rule Name: Apply To

- Base Package Calculation Rule Business Object: C1-ApplyTo

- Apply Calculation Rule Algorithm Type / Algorithm: C1-APPLYTO

- Rule Parameters:

- Calculation Details: Details regarding how the calculation rule performs its calculations:

- Error If No Value: Indicates what should happen if the system cannot find any calculation rules that are members of the target category at billing time.

- Seasonal: See Common Parameters.

- Value Type: Defines if the price is a Charge, Percentage or Unit Rate.

- Value Source: specifies the source of the price. Depending on the value source selected, either a Bill Factor, Value, or Value Algorithm is required.

- Example: The following calculation rule applies a county tax other calculation rules that belong the "Taxable - County Tax" category.
Calculation Group: Taxes

Calculation Rule: CNTYTAX

Sequence: 530

Description: County Tax

Description On Bill: County sales tax %R %T

Print: Yes

Print if Zero: No

Rounding Type: Nearest

Precision: 0.01

FCPO: No

Override Proration: No

Calculation Details:

- Error If No Value: No

- Seasonal: No

- Value Type: Percentage

- Value Source: Bill Factor

- Bill Factor: County Tax
GL Distribution:

- Distribution Source Code: Specific Distribution Code

- Distribution Code: Payable - County Tax
Cross Reference:

- Target Category (Category Type / Value): Taxable / County Tax

- Member Category (Category Type/Value): Summary Item / Summary Line

Calculate Final Reading Values

Calculate Final Reading Values rules determine the final values for readings based on user-defined UOM/TOU/SQI.

- Rule Name: Calculate Final Reading Values

- Base Package Calculation Rule Business Object: C1-CalculateFinalValue

- Apply Calculation Rule Algorithm Type / Algorithm: C1-CALCFNVL

- Rule Parameters:

- Calculation Details: Details regarding how the calculation rule performs its calculations:

- Unit of Measure: The unit of measure for the measured quantity.

- Time of Use: The time of use for the measured quantity.

- Service Quantity Identifier: The service quantity identifier for the measured quantity.

- Retain Measured SQ: indicates whether to save the accumulated measured quantity entry in the SQ collection. If this value is set to No, it means the value will be removed from the SQ collection. Before any pre-processing rule is executed, the rate engine will place the sum / max value of the read details into the SQ collection. For example, if the read details contain entries for measured CCF, there will be an entry in the SQ collection for the total CCF from all read details. This might be what is needed, but it may be extraneous if a rule converts the measured quantity into therms. In this situation, the SQ collection only needs therms and the CCF entry can be removed.

- Formula: Defines the formula used to calculate the final read quantity. Bill Factors (or scalar variables) to be used in the calculation are designated as Vn, where n matches the number assigned to the variable (i.e. V1 = Bill Factor 1, V2 = Bill Factor 2, etc.). Measured Quantity is referenced as MQ in the formula Mathematical operations supported include addition, subtraction, multiplication and division. For example: (MQ * V1) would be the formula to convert CCF to THERM.

- Scalar Variables: Defines the scalar variables or Bill Factors to be used in the calculation. When referenced in the formula, scalar variables are designated as Vn, where n matches the number assigned to the variable (i.e. V1 = Bill Factor 1, V2 = Bill Factor 2, etc.). Note that only regular bill factors may be used in the formula. Interval and Time of Use bill factors are not supported.

- Sequence: Designates the number of the variable (V1, V2, etc.)

- Bill Factor: The Bill Factor used for the variable.

- Result: Defines the type of data (Unit of Measure, Time of Use, and/or Service Quantity Identifier) to be used for the final quantity calculated by the rule.

- Processing: The following processing takes place:

- The rule will process each read detail whose initial UOM matches the measured quantity UOM.

- It substitutes the reference to MQ in the formula with each read's measured quantity and then calls the formula service passing the defined bill factors as variables 1 to n. The read's end date is passed as the effective date.

- It then populates each read's final value with the results of the formula and it populates the final UOM / TOU / SQI with the values defined on the rule.

- It populates the SQ collection with the results (this will either add a new value if the Final UOM / TOU / SQI is not present in the SQ collection, OR it will update the existing SQ quantity with the sum or max of the calculated value depending on the Final UOM's measure's peak value). Note, the initial and final values of such an SQ will be the calculated value.

- It then removes the measured UOM / TOU / SQI from the SQ collection if the rule has been configured as such.

- Example: This calculation rule converts CCF (as recorded on the meter) to therms for billing purposes.
Calculation Group: CCF to Therm Conversion (Calculate SQ - SQ and BF)

Calculation Rule: CCF2TH

Sequence: 10

Description: Convert CCF to TH

Calculation Details:

- Unit of Measure: 100 cubic feet of gas

- Retain Measured SQ: Yes

- Formula: MQ*V1*V2
Scalar Variables (Sequence / Bill Factor):

- 1 / Pressure adjustment zone

- 2 /Take point for therm conv.fac
Result:

- Unit of Measure: Thermal units

Calculate Service Quantity

Calculate Service Quantity rules derive or calculate a service quantity that is eventually inserted into the bill segment SQ collection. Calculate Service Quantity calc rules are generally used to either manipulate measured consumption, or to derive quantities that are not measured by a meter.

- Rule Name: Calculate Service Quantity

- Base Package Calculation Rule Business Object: C1-CalculateServiceQuantity

- Apply Calculation Rule Algorithm Type / Algorithm: C1-CALC-SQ

- Rule Parameters:

- Scalar Variable 1 (Scalar Variable 2, Scalar Variable 3, ... Scalar Variable 5): Defines one of the scalar variables to be used in the calculation. When used in formulas, scalar variables are designated as Vn, where n matches the number assigned to the variable (i.e. V1 = Scalar Variable 1, V2 = Scalar Variable 2, etc.).

- Type: Defines the type of variable and can be one of the following:

- Algorithm: an algorithm is responsible for retrieving the scalar variable value, e.g. calculate number of days in the bill period.

- Bill Factor: the value for a specified bill factor that is in effect for the period.

- Calculated Line: the value is derived by summing previously calculated lines defined as members of a target category.

- Characteristic Value: the value is derived by summing characteristic values of a given characteristic type.

- Contract Quantity: the value for a given contract quantity type specified on a service agreement.

- Historical Service Quantity: the value is derived based on the SA's historical bill segment service quantities for the specified UOM / TOU / SQI. The Aggregate Function defines the calculation to perform on the set of historical service quantities retrieved to derive a single value. Average, Maximum, Minimum and Sum are supported.

- Service Quantity: service quantities from the bill period's SQ collection, based on a specified UOM / TOU / SQI. This type of variable allows this rule to make use of values calculated by other rules.

- Missing Value Action: Defines what should take place if the system is unable to retrieve or derive a value for a particular scalar variable. Valid options are as follows:

- Select Error to create an exception

- Select Skip to exit the rule and process the next rule

- Select Use Default Value if the scalar variable should be set to the default value specified

- Calculation Details: Details regarding how the calculation rule performs its calculations:

- Calculation Rule Processing: Indicates if the rule is Always executed by rate application, even if the consumption details on the original bill segment are to be used when the system recalculates a bill segment. If the rule should not be executed when the consumption details on the original bill segment are used, indicate that the SQ rule should only be executed on the Initial SQ Calculation.

- Fail Action: Indicates the action to take if an error is encountered when applying the rule's formula. Available options are to either create a bill segment Error, or to Skip the calculation rule.

- Calculation Rule Output: Specifies whether calculation rule should add or update a Service Quantity entry in the bill period's SQ collection, or create a bill Calculation Line, or Both.

- Retain SQ: Indicates whether to save the calculated value on the bill segment. If this value is set to No, it means the value will only exist in the SQ collection while the rate engine is calculating. A value of No should be used for SQ entries that do not have to be retained for audit or analytic purposes.

- Formula Source: Specifies the type of formula to use for the rule. Valid options include "Simple Formula" and "Conditional Formula".

- Formula: Specify the Simple Formula to apply. Scalar variables to be used in the calculation are designated as Vn, where n matches the number assigned to the variable (i.e. V1 = Scalar Variable 1, V2 = Scalar Variable 2, etc.). Mathematical operations supported include addition, subtraction, multiplication and division. For example: (V1*V2)/2.

- Conditional Formula: this allows comparison between one or more pairs of operands to determine the specific formula to execute. A conditional formula can utilize one or more conditions. Each condition comprises the following:

- Operand 1: the first operand in the condition. Can reference an expression with one or more scalar variables (designated as Vn), e.g. [V1+V2] or [(V1/V2)*V3].

- Operator: the operator used to compare Operand 1 with Operand 2.

- Operand 2: the second operand in the condition. Can reference an expression with one or more scalar variables, or a constant (similar to Operand 1).

- True Action: indicates how to proceed if the comparison between the operands is true. Can be one of the following:
Apply True Formula: indicates that the True Formula be executed.

Check Next Condition: indicates that the next condition should be checked.

- True Formula: the formula to apply if True Action is set to Apply True Formula. Can reference an expression with one or more scalar variables (designated as Vn), or a constant.

- False Action: indicates how to proceed if the comparison between the operands is false. Can be one of the following:
Apply False Formula: indicates that the False Formula be executed.

- Check Next Condition: indicates that the next condition should be checked.

- False Formula: the formula to apply if the False Action is set to Apply False Formula. Can reference a vector (designated as IVn, where n is the number of the vector) or an expression referencing one or more vectors or a scalar variable (designated as Vn).

- Result: Define the Unit of Measure, Time of Use and/or Service Quantity Identifier to be used if this calculation rule inserts or updates a service quantity in the bill period's SQ collection.

- Example: This calculation rule calculates total kWh from On Peak and Off Peak service quantities.
Calculation Group: Calculate KWH

Calculation Rule: TOTKWH

Sequence: 10

Description: Total amount of KWH (On Peak + Off Peak)

Scalar Variable 1:

- Type: Service Quantity

- Missing Value Action: Error

- Unit of Measure: Kilowatt Hours

- Time of Use: On Peak

- SQ To Use: Billable
Scalar Variable 2:

- Type: Service Quantity

- Missing Value Action: Error

- Unit of Measure: Kilowatt Hours

- Time of Use: Off Peak

- SQ To Use: Billable
Calculation Details:

- Calculation Rule Processing: Always

- Fail Action: Error

- Calculation Rule Output: Service Quantity

- Retain SQ: No

- Formula Source: Simple Formula

- Formula: V1 + V2
Result:

- Unit of Measure: Kilowatt Hours

Flat Charge

Flat Charge rules create bill lines that levy service charges and fees that aren't based on how much the customer uses. For example a flat charge calculation rule may be used to apply a monthly service charge of $10 to a customer's bill.

- Rule Name: Flat Charge

- Base Package Calculation Rule Business Object: C1-FlatCharge

- Apply Calculation Rule Algorithm Type / Algorithm: C1-FLAT-CHRG

- Rule Parameters:

- Calculation Details: Details regarding how the calculation rule performs its calculations:

- Seasonal: See Common Parameters.

- Value Type: Defines the type of value to use for the rule. For Flat Charge rules, this should be set to Charge.

- Value Source: Specifies the source of the price used to calculate the charge. Depending on the source selected, this will be a Bill Factor, Value, or Algorithm.

- Example: This calculation rule levies a customer charge.
Calculation Group: Customer Charge

Calculation Rule: CSTCHG

Sequence: 20

Description: Customer Charge

Description On Bill: Customer Charge

Print: Yes

Print if Zero: No

Rounding Type: Nearest

Precision: 0.01

FCPO: No

Override Proration: No

Calculation Details:

- Seasonal: No

- Value Type: Charge

- Value Source: Valie

- Value: 5
GL Distribution:

- Distribution Source Code: Specific Distribution Code

- Distribution Code: Revenue - Energy
Cross Reference:

- Member Category (Category Type / Value): Subject to tax / City taxable

Item Type

Item Type rules create bill lines that levy charges based on the number and type of items used by a customer. The system keeps track of items on the service point(s) linked to the customer's service agreement.

- Rule Name: Item Type

- Base Package Calculation Rule Business Object: C1-ItemType

- Apply Calculation Rule Algorithm Type / Algorithm: C1-ITEMTYPE

- Rule Parameters:

- Calculation Details: Details regarding how the calculation rule performs its calculations:

- Seasonal: See Common Parameters.

- Item Type: Defines the types of items to which charges are applied. When defining more than one item type on a single calculation rule, you can indicate that the item type of a bill line should be substituted into the bill line's description by using the %M substitution variable in the calculation rule's Description On Bill field.

- Error If No Value: A flag that indicates (Yes or No) if a bill error should be generated if the item type specified on the calculation rule was not supplied at billing time.

- Value Type: Defines the type of charge. Valid options include Charge, Percentage, or Unit Rate.

- Value Source: Defines the source of the price used to calculate the charge. Depending on the source selected, this will be a Bill Factor, Value, or Algorithm.

- Value/Bill Factor/Algorithm: The specific Value, Bill Factor, or Algorithm that serves as the source of the price used to calculate the charge.

- Example: This calculation rule calculates charges for light poles.
Calculation Group: Lamp Charges

Calculation Rule: POLE CHARGE

Sequence: 10

Description: Pole Charge

Description On Bill: %C lamp poles at %R per pole %D %I

Print: Yes

Print if Zero: No

Rounding Type: Nearest

Precision: 0.01

FCPO: No

Override Proration: No

Calculation Details:

- Seasonal: No

- Items:

- Item Type: Pole(s)

- Error If No Value: No

- Value Type: Unit Rate

- Value Source: Value

- Value / Bill Factor /Algorithm: 3
GL Distribution:

- Distribution Source Code: Specific Distribution Code

- Distribution Code: Revenue - Area Lighting
Cross Reference:

- Member Category (Category Type / Value): Charges / Total Charges

- Member Category (Category Type / Value): Charges / Lamp Charges

Math

Math rules derive interval data based on a formula, and apply TOU mappings and/or other operations to the derived data to calculate service quantities.

- Rule Name: Math

- Base Package Calculation Rule Business Object: C1-Math

- Apply Calculation Rule Algorithm Type / Algorithm: C1-MATH

- Rule Parameters:

- Vector 1 (Vector 2, Vector 3, ... Vector 5): Defines one of the vectors (Vector 1, 2, 3, ...5) to be used in the calculation. When used in formulas, interval values for vectors are designated as IV1, IV2, IV3,... IV5.

- Vector Type: Defines the type of vector. Valid options include Interval Bill Factor and Interval Service Quantity.

- Bill Factor: Defines the Interval Bill Factor from which interval values are derived for the vector.

- Unit of Measure / Time of Use / Service Quantity Identifier: The UOM/TOU/SQI used to retrieve interval values from either the usage request service quantity entries given a usage request ID and usage period, or from the rate engine buffer populated prior to calling rate application.

- Missing Interval Data Action: Defines the action to take (Error or Skip) if interval data is missing for the expected period

- Scalars: Defines scalar variables to be used in the calculation. When used in formulas, scalar variables are designated as Vn, where n is the number of the variable (based on the sequence in which they are defined in the list).

- Scalar Type: Defines the type of variable. Can be one of the following:

- Bill Factor: The value for a specified bill factor that is in effect for the billing period.

- Set Function: The result of applying a function to a set of interval measurement values (defined as a vector).

- Service Quantity: Service quantities from the current SQ list, based on a specified UOM, TOU, or SQI. This type of variable allows this rule to make use of values calculated by other rules.

- Bill Factor: Defines the bill factor used to retrieve the variable value (applicable only if Scalar Type is Bill Factor)

- Unit of Measure: Defines the UOM for service quantities to retrieve from the SQ list (applicable only if Scalar Type is Service Quantity).

- Time of Use: Defines the TOU for service quantities to retrieve from the SQ list (applicable only if Scalar Type is Service Quantity).

- Service Quantity Identifier: Defines the SQI for service quantities to retrieve from the SQ list (applicable only if Scalar Type is Service Quantity).

- SQ to Use: Every service quantity supplied to a rate has two quantities; the quantity initially measured, and the quantity that should be priced by the rate. Most of the time these two amounts will be the same, unless another rule has executed and caused the billable quantity to change. Each rule needs to know if it should use the Initial or Billable quantity.

- Set Function: Defines the function used to calculate a scalar value from a set of interval values (defined as a vector). This is applicable only if Scalar Type is Set Function). Can be one of the following:

- Average: calculates the average of the vector's interval measurement values.

- Count: returns the number of interval measurements.

- Max: returns the maximum value from the vector's interval measurement values.

- Min: returns the minimum value from the vector's interval measurement values.

- Total: calculates the total of the vector's interval measurement values.

- Vector: the vector to be used for this variable (applicable only if Scalar Type is Set Function). Can be one of the following:

- FV (Final Vector Interval Value): the vector containing the results of the formula defined in the Calculation Details section.

- IV1 (Vector 1 Interval Value): the vector defined as Vector 1.

- IV2 (Vector 2 Interval Value): the vector defined as Vector 2.

- IV3 (Vector 3 Interval Value): the vector defined as Vector 3.

- IV4 (Vector 4 Interval Value): the vector defined as Vector 4.

- IV5 (Vector 5 Interval Value): the vector defined as Vector 5.

- Missing Value Action: Defines the action to take (Error, Skip, or Use Default Value) if data is missing for the scalar variable for the expected period

- Default Value: The default value to use if data is missing for the scalar variable. Applicable only if Missing Value Action is Use Default Value.

- Calculation Details: Details regarding how the calculation rule performs its calculations:

- Calculation Rule Processing: Indicates if the rule is Always executed by rate application, even if the consumption details on the original bill segment are to be used when the system recalculates a bill segment. If the rule should not be executed when the consumption details on the original bill segment are used, indicate that the SQ rule should only be executed on the Initial SQ Calculation.

- Fail Action: Indicates the action to take if an error is encountered when applying the rule's formula. Available options are to either create a bill segment Error, or to Skip the calculation rule.

- Calculation Rule Output: Specifies whether calculation rule should add or update a Service Quantity entry in the bill period's SQ collection, or create a bill Calculation Line, or Both.

- Retain SQ: Indicates whether to save the calculated value on the bill segment. If this value is set to No, it means the value will only exist in the SQ collection while the rate engine is calculating. A value of No should be used for SQ entries that do not have to be retained for audit or analytic purposes.

- Formula Source: Specifies the type of formula to use for the rule. Valid options include "Simple Formula" and "Conditional Formula".

- Formula: Specify the Simple Formula to apply. Scalar variables to be used in the calculation are designated as Vn, where n matches the number assigned to the variable (i.e. V1 = Scalar Variable 1, V2 = Scalar Variable 2, etc.). Mathematical operations supported include addition, subtraction, multiplication and division. For example: (V1*V2)/2.

- Conditional Formula: this allows comparison between one or more pairs of operands to determine the specific formula to execute. A conditional formula can utilize one or more conditions. Each condition comprises the following:

- Operand 1: the first operand in the condition. Can reference an expression with one or more scalar variables (designated as Vn), e.g. [V1+V2] or [(V1/V2)*V3].

- Operator: the operator used to compare Operand 1 with Operand 2.

- Operand 2: the second operand in the condition. Can reference an expression with one or more scalar variables, or a constant (similar to Operand 1).

- True Action: indicates how to proceed if the comparison between the operands is true. Can be one of the following:
Apply True Formula: indicates that the True Formula be executed.

Check Next Condition: indicates that the next condition should be checked.

- True Formula: the formula to apply if True Action is set to Apply True Formula. Can reference an expression with one or more scalar variables (designated as Vn), or a constant.

- False Action: indicates how to proceed if the comparison between the operands is false. Can be one of the following:
Apply False Formula: indicates that the False Formula be executed.

- Check Next Condition: indicates that the next condition should be checked.

- False Formula: the formula to apply if the False Action is set to Apply False Formula. Can reference a vector (designated as IVn, where n is the number of the vector) or an expression referencing one or more vectors or a scalar variable (designated as Vn).

- Result: Defines how service quantities are inserted into the SQ list. Math calculation rules can insert one or more entries into the SQ list.

- Result Source: Defines the method to use to calculate for the service quantity. Can be one of the following:

- Set Function Against Derived Vector: Applies a function to the derived interval values. The function to be applied is specified in the Set Function field.

- Scalar Formula Result: Applies a user-defined formula. The formula is specified in the Scalar Formula field.

- Set Function: the function to apply to the derived interval values (applicable only if Result Source is set to Set Function Against Derived Vector). Can be one of the following:

- Average: Calculates the average of the derived interval measurement values.

- Count: Returns the number of derived interval measurements.

- Max: Returns the maximum value from the derived interval measurement values.

- Min: Returns the minimum value from the derived interval measurement values.

- Total: Calculates the total of the derived interval measurement values.

- Scalar Formula: the formula to apply (applicable only if Result Source is set to Scalar Formula). Variables used in this formula must be defined in the Scalars section. When referenced in formulas, scalar variables are designated as Vn (where n is the number of the variable).

- Unit of Measure: the UOM to be used when inserting service quantity entries

- Time of Use: the TOU to be used when inserting service quantity entries

- Service Quantity Identifier: the SQI to be used when inserting service quantity entries

- Apply TOU Map: Indicates if a TOU map should be applied to the derived interval values. If TOU periods and values are returned as a result of TOU mapping, then service quantity entries are inserted.

- TOU Map: Defines the TOU Map to apply to the derived interval values (applicable only if Apply TOU Map is set to Yes).

- TOU Mapping Function: Defines the function to apply to the derived interval values when calculating for the time of use values (applicable only of Apply TOU Map is set to Yes). Can be one of the following:

- Max: Returns the maximum value from the derived interval values for each TOU period.

- Sum: Returns the sum of the derived interval values for each TOU period.

- Processing:
Math rules derive interval values based on a formula, and apply TOU mappings and/or other operations to the derived data to calculate billing quantities. Examples include the following:

- Derive an interval data curve (vector) given a formula. For example, derive a power factor curve given a formula using kWh and kvarh curves.

- Apply TOU mapping to a derived interval data curve. For example, after deriving the power factor curve, perform TOU mapping on the result.

- Perform mathematical operations on SQ entries. For example, get total kWh consumption by adding "kWh On Peak", "kWh Off Peak", and "kWh Shoulder Peak" where "kWh On Peak", "kWh Off Peak", and "kWh Shoulder Peak" were calculated by a previous calculation rule.
Each interval data curve is defined as a vector parameter (the rule can define up to 5 vectors). Mathematical operations defined by the "Vector Processing" parameters can be performed between vectors (e.g. IV1 * IV2) and between vectors and scalar variables (e.g. IV1 * V1).

- Example: This calculation rule calculates prices for interval usage by multiplying an interval service quantity times an interval price bill factor.
Calculation Group: Electric Commercial - Interval Pricing

Calculation Rule: INTDPRICING

Sequence: 10

Description: KWH Interval Prices

Description On Bill: kWh Interval Prices

Print: Yes

Print if Zero: No

Rounding Type: Nearest

Precision: 0.01

FCPO: No

Vector 1:

- Vector Type: Interval Service Quantity

- Unit of Measure: Kilowatt Hours

- Missing Interval Data Action: Error
Vector 2:

- Vector Type: Interval Bill Factor

- Bill Factor: Interval Prices

- Missing Interval Data Action: Error
Calculation Details:

- Calculation Rule Processing: Always

- Fail Action: Error

- Calculation Rule Output: Calculation Line

- Formula Source: Simple Formula

- Simple Formula: IV1 * IV2
Result:

- Result Source: Set Function Against Derived Vector

- Set Function: Total
GL Distribution:

- Distribution Source Code: Specific Distribution Code

- Distribution Code: Revenue - Energy

Maximum Charge

Maximum Charge calculation rules are used to create bill lines that levy charges only when the sum of previously calculated lines is more than the maximum charge amount. Maximum charge calculation rules must define the respective target category that they are applied to. The calculation rule(s) that compute charges that the maximum is levied on must be defined as members of the target category. See Cross-Reference under Common Parameters for more information about Member and Target categories.

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 calculation rule.

Note: Maximum Charge calculation rules are rare. You tend to only see them in deregulated markets where customers have agreed to pay the market rate but want a cap on the maximum they'll pay each bill period.

- Rule Name: Maximum Charge

- Base Package Calculation Rule Business Object: C1-Maximum

- Apply Calculation Rule Algorithm Type / Algorithm: C1-MAXIMUM

- Rule Parameters:

- Calculation Details: Details regarding how the calculation rule performs its calculations:

- Error If No Value: Indicates what should happen if the system cannot find any calculation rules that are members of the target category at billing time.

- Seasonal: See Common Parameters.

- Value Type: Defines the type of value to use for the maximum value for the rule. For Maximum Charge rules, this should be set to Charge.

- Value Source: Specifies the source of the price used to calculate the charge. Depending on the source selected, this will be a Bill Factor, Value, or Algorithm.

- Example: This calculation rule sets a maximum charge for area lighting.
Calculation Group: Customer-Owned Street & Highway Lighting

Calculation Rule: MAXCHRGE

Sequence: 20

Description: Maximum Charge - Area Lighting

Description On Bill: Maximum Charge

Print: Yes

Print if Zero: No

Rounding Type: Nearest

Precision: 0.01

FCPO: No

Override Proration: No

Calculation Details:

- Error If No Value: No

- Seasonal: No

- Value Type: Charge

- Value Source: Value

- Value: 100
GL Distribution:

- Distribution Source Code: Specific Distribution Code

- Distribution Code: Revenue - Area Lighting
Cross Reference:

- Target Category (Category Type / Value): Revenue / Maximum Consumption Charge

Minimum Charge

Minimum Charge rules create bill lines that levy charges only when the sum of previously calculated lines is less than the minimum charge amount. Minimum charge calculation rules must define the respective target category that they are applied to. The calculation rule(s) that compute charges that the minimum is levied on must be defined as members of the target category. See Cross-Reference under Common Parameters for more information about Member and Target categories.

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.

- Rule Name: Minimum Charge

- Base Package Calculation Rule Business Object: C1-Minimum

- Apply Calculation Rule Algorithm Type / Algorithm: C1-MINIMUM

- Rule Parameters:

- Calculation Details: Details regarding how the calculation rule performs its calculations:

- Error If No Value: Indicates what should happen if the system cannot find any calculation rules that are members of the target category at billing time.

- Seasonal: See Common Parameters.

- Value Type: Defines the type of value to use for the minimum value for the rule. For Minimum Charge rules, this should be set to Charge.

- Value Source: Specifies the source of the price used to calculate the charge. Depending on the source selected, this will be a Bill Factor, Value, or Algorithm.

- Example: This calculation rule defines a minimum charge for use with residential electric rates.
Calculation Group: Electric Residential

Calculation Rule: MINCHRG

Sequence: 50

Description: Minimum Charge

Description On Bill: Minimum Charge

Print: Yes

Print if Zero: No

Rounding Type: Nearest

Precision: 0.01

FCPO: No

Override Proration: No

Calculation Details:

- Error If No Value: No

- Seasonal: No

- Value Type: Charge

- Value Source: Value

- Value: 75
GL Distribution:

- Distribution Source Code: Specific Distribution Code

- Distribution Code: Revenue - Miscellaneous
Cross Reference:

- Target Category (Category Type / Value): Charges / Energy Charges

- Member Category (Category Type / Value): Summary Item / Summary Line

- Member Category (Category Type / Value): Taxable - State Tax

- Member Category (Category Type / Value): Taxable - City Tab

Service Quantity

Service Quantity rules create bill lines that levy charges based on some type of consumption.

Frequently the amount consumed is measured by a meter's registers and sometimes it's calculated using Pre-Processing calculation and sometimes it's derived based on the type of item (e.g., for lamps). Regardless of how the amount consumed is calculated, the charge for the consumption amount is levied using this type of rate component.

- Rule Name: Service Quantity

- Base Package Calculation Rule Business Object: C1-ServiceQuantity

- Apply Calculation Rule Algorithm Type / Algorithm: C1-SQ

- Rule Parameters:

- Calculation Details: Details regarding how the calculation rule performs its calculations:

- Unit of Measure: The UOM used as the service quantity that the price is applied to.

- Time of Use: The TOU used as the service quantity that the price is applied to.

- Service Quantity Identifier: The SQI used as the service quantity that the price is applied to.

- Error If No Value: A flag that indicates (Yes or No) if a bill error should be generated if the UOM/TOU/SQI specified on the rule was not supplied at billing time.

- Measures Peak: Indicates (Yes or No) if the UOM/TOU/SQI specified for the rule is used to measure peak (demand) values.

- GL Statistical Qty: A flag that specifies (Yes or No) if GL journal lines generated for this calculation rule should also contain the service 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.

- Seasonal: See Common Parameters.

- Value Type: Defines the type of price to be used in the rule's calculations. Valid options include Charge, Percentage, or Unit Rate.

- Value Source: Defines the source of the price used in the rule's calculations. Depending on the source selected, this will be a Bill Factor, Value, or Algorithm.

- Example: This calculation rule calculates charges based a customer's KWH consumption.
Calculation Group: Electric Residential Charges

Calculation Rule: KWHCHRG

Sequence: 10

Description: kWh Unit Rate

Description On Bill: Usage %Q at %R per kWh

Print: Yes

Print if Zero: No

Rounding Type: Nearest

Precision: 0.01000

FCPO: No

Override Proration: No

Calculation Details:

- Unit of Measure: Kilowatt Hours

- Error If No Value: Yes

- Measures Peak: No

- GL Statistical Qty: Yes

- Seasonal: No

- Value Type: Unit Rate

- Value Source: Value

- Value: 0.0482000
GL Distribution:

- Distribution Source Code: Specific Distribution Code

- Distribution Code: Revenue - Electric - Residential
Cross Reference:

- Target Category:

- Category Type:

- Category Value:

- Member Category (Category Type / Value): Revenue / Consumption Charge

Simple Summary

Simple Summary rules create a "subtotal" on the bill by summarizing bill lines produced by other calculation rules in the same calculation group.

- Rule Name: Simple Summary

- Base Package Calculation Rule Business Object: C1-SimpleSummary

- Apply Calculation Rule Algorithm Type / Algorithm: C1-SIMP-SUMM

- Rule Parameters:

- Referenced Calculation Rules: Defines the calculation rules that should be included in the summary. Note that any calculation rules listed here must belong to the same calculation group as the Summary rule.

- Example: This calculation rule creates a summary of TOU-based charges (based on rules within the same calculation group as this rule).
Calculation Group: Commercial TOU Electric Charges

Calculation Rule: KWHTOT

Sequence: 40

Description: Consumption Subtotal

Description On Bill: Consumption Subtotal

Print: Yes

Print if Zero: No

Rounding Type: Nearest

Precision: 0.01

FCPO: No

Referenced Calculation Rules:

- Off Peak - kWh

- On Peak - kWh

- Shoulder Peak - kWh
Cross Reference:

- Member Category (Category Type / Value): Taxable / State Tax

Stepped Service Quantity

Stepped Service Quantity rules create bill lines that levy charges based on some type of consumption when different prices are applied to different ranges of consumption (for example, the first 50 kWh are $0.43 per kWh, anything in excess of 50 kWh is charged at $0.71 per kWh)

- Rule Name: Stepped Service Quantity

- Base Package Calculation Rule Business Object: C1-SteppedSQ

- Apply Calculation Rule Algorithm Type / Algorithm: C1-STPD-SQ

- Rule Parameters:

- Calculation Details: Details regarding how the calculation rule performs its calculations:

- Unit of Measure: The UOM used as the service quantity that the price is applied to.

- Time of Use: The TOU used as the service quantity that the price is applied to.

- Service Quantity Identifier: The SQI used as the service quantity that the price is applied to.

- Error If No Value: A flag that indicates (Yes or No) if a bill error should be generated if the UOM/TOU/SQI specified on the rule was not supplied at billing time.

- Measures Peak: Indicates (Yes or No) if the UOM/TOU/SQI specified for the rule is used to measure peak (demand) values.

- GL Statistical Qty: A flag that specifies (Yes or No) if GL journal lines generated for this calculation rule should also contain the service 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.

- Create Step Summary: Stepped service quantity calculation rules may be configured with either a single step or multiple steps. The Create Step Summary flag is used to produce a summary bill segment calculation line if the calculation rule has multiple steps. Valid options include:

- Summarize Step Lines, Print: Creates a stepped charge summary bill line that will appear on the customer's bill.

- Summarize Step Lines, Do Not Print: Creates a stepped charge summary bill line that will be shown on Bill Segment - Calculation Details, but not appear on the customer's bill.

- Step Calculation Details:

- Seasonal: See Common Parameters.

- Step Multiplier Algorithm: Specifies the algorithm that will be used calculate the step boundaries. Used only if step boundaries are dynamic and are calculated based on something that's only known at billing time.

- Values: Defines the values associated with each of the ranges (steps) of consumption used by the rule. For example, if the charge is applicable to the first 300 kilowatt hours, you would enter Low Value 0 and High Value 300. When multiple tiers exist, the high value of the first tier is the low value of the second tier (and so on). To extend our example, the second tier would have a low value of 300; the high value may be left blank (the system assumes a blank high value means "to infinity").

- Low Value: Defines the low value for the consumption range. This field supports values of up to 14 digits and 4 decimal places (e.g. a maximum value of 99,999,999,999,999.9999).
You can indicate that the low value of a bill line should be substituted into the bill line's description by using the %L substitution variable in the calculation rule's Description On Bill field.

- High Value: Defines the high value for the consumption range. This field supports values of up to 14 digits and 4 decimal places (e.g. a maximum value of 99,999,999,999,999.9999).
You can indicate that the high value of a bill line should be substituted into the bill line's description by using the %H substitution variable in the calculation rule's Description On Bill field.

- Value Type: Defines the type of price to be applied to the consumption range in the rule's calculations. Valid options include Charge, Percentage, or Unit Rate.

- Value Source: Defines the source of the price to be applied to the consumption range in the rule's calculations. Depending on the source selected, this will be a Bill Factor, Value, or Algorithm.

- Value/Bill Factor/Algorithm: Specifies the Bill Factor, Value, or Algorithm used when calculating charges for the consumption range.

- Example: This calculation rule calculates charges for electric service based on stepped charges for kWh consumption during the Fall
Calculation Group: Electric Residential - Stepped

Calculation Rule: KWHSTFL

Sequence: 10

Description: Fall kWh Stepped Charges

Description On Bill: Usage %Q kWh at %I per kWh %F

Print: Yes

Print if Zero: No

Rounding Type: Nearest

Precision: 0.01000

FCPO: No

Override Proration: No

Calculation Details:

- Unit of Measure: Kilowatt Hours

- Error If No Value: No

- Measures Peak: No

- GL Statistical Qty: Yes

- Create Step Summary: Create Summary, Do Not Print
Step Calculation Details:

- Seasonal: Yes

- Seasonal Prorate Method: Accounting Date

- Season Start: 09-01

- Season End: 11-30

- Value 1:

- Low Value: 0

- High Value: 300

- Value Type: Unit Rate

- Value Source: Value

- Value / Bill Factor / Algorithm: 0.0485

- Value 2:

- Low Value: 300

- High Value: [blank]

- Value Type: Unit Rate

- Value Source: Value

- Value / Bill Factor / Algorithm: 0.0564
GL Distribution:

- Distribution Source Code: Specific Distribution Code

- Distribution Code: Revenue - Electric - Residential
Cross Reference:

- Member Category (Category Type / Value): Revenue / Consumption Charge

Summary

Summary rules create a "subtotal" on the bill. It exists purely for reporting and informational purposes. Summary calculation rules must define the respective target category that they are applied to. The calculation rule(s) that compute charges should be included in the summary must be defined as members of the target category. See Cross-Reference under Common Parameters for more information about Member and Target categories.

- Rule Name: Summary

- Base Package Calculation Rule Business Object: C1-Summary

- Apply Calculation Rule Algorithm Type / Algorithm: C1-SUMMARY

- Rule Parameters:

- Calculation Details: Details regarding how the calculation rule performs its calculations:

- Error If No Value: Indicates what should happen if the system cannot find any calculation rules that are members of the target category at billing time.

- Example: This calculation rule creates a consumption summary on the bill based on other calculation rules included in the rate that belong to the "Revenue / Consumption Charge" categroy.
Calculation Group: Electric Residential Charges

Calculation Rule: USGSUM

Sequence: 30

Description: Usage Summary

Description On Bill: Summary

Print: Yes

Print if Zero: No

Rounding Type: Nearest

Precision: 0.01000

FCPO: No

Calculation Details:

- Error If No Value: No
Cross Reference:

- Target Category (Category Type / Value): Revenue / Consumption Charge

- Member Category (Category Type / Value): Summary / Summary of Consumption Charge

Rate Check - New Style

This version of Oracle Utilities Customer Care and Billing includes a new version of the Rate Check feature that can be used with New Style rate schedules.

Note: This section assumes you are already familiar with the classic Rate Check feature available in pre-v2.4 versions of Oracle Utilities Customer Care and Billing.

Note: Refer to the Rate Check section of the Rates chapter for more information about the rate check feature.

About Rate Check

The Rate Check feature allows you to test your rate schedules under various scenarios. For example, you can test your rates for an existing account using previous bill segments, or by providing user-specified bill period and service quantities.

Performing a Rate Check

Note: The new style Rate Check portal works with both Classic and New Style rate schedules.

Use this procedure to perform a rate check.

- Select Main Menu, Rates, Rate Check.

- Select the Rate Schedule for the rate check.

- Select the Service Agreement for the rate check.

- Select the Bill Segment for the rate check (if you wish to base the rate check on an existing bill segment).

- Enter the Start Date, End Date, and Accounting Date for the rate check.

- Select the Revenue Class for the rate check.

- If you are basing the rate check on user-specified Service Quantities, enter the following for each as applicable:

- UOM: The unit of measure applicable for the rate check (based on the specified rate schedule)

- TOU: The time of use applicable for the rate check (based on the specified rate schedule)

- SQI: The service quantity identifier applicable for the rate check (based on the specified rate schedule)

- Measured Quantity: The amount of the service quantity specified.

- Service Point ID: The service point which recorded the service quantities, if applicable
Note: If you specified a Service Agreement and Bill Segment, this section is populated basd on the selected data, but can be manually overwritten.
.

- Specify characteristic types and values for any Characteristics are applicable to the rate check. Characteristic types and values are used to apply appropriate bill factor values during rate processing.

- If you are using a New Style rate schedule for the rate check, specify if the system Should Trace the process. This produces logs that outline the calculation groups and rules used by the rate schedule.

- Execute the rate check:

- If you wish to execute the rate check using a specified bill segment or service quantities, click Check Rate.

- If you wish to execute the rate check using billing determinants retrieved from an external system (such as Oracle Utilities Meter Data Management), select the appropriate function from the Select Function drop-down list.

Viewing Results of a Rate Check

The results of the rate check are displayed on the Results tab. This tab contains the following zones:

- Main: Displays results of the rate check, including:

- Rate Schedule: The rate schedule used in the rate check

- Revenue Class: The revenue class used for the rate check.

- Bill Period: The start and end dates for the bill period used by the rate check.

- Consumption Period: The start and dates for the consumption period used by the rate check.

- Accounting Date: The Accounting Date used by the rate check.

- Calculated Amount: The calculated total for the rate check

- Calculation Lines: Displays the bill calculation headers and lines for the rate schedule.

- Read Details: Displays meter read details for the consumption used in the rate calculation.

- SQ Details: Displays a list of service quantities used in the rate calculation.

- Characteristics: Displays characteristics referenced by the rate calculation (if applicable).

- Trace Log: Displays logs that outline the calculation groups and rules used by the rate schedule. This zone is populated only if using a New Style rate schedule, and if the Should Trace drop-down list is set to "No".

Table of Contents

Cover Page

Legal Notices

Customer Information

Understanding The V

Persons

Accounts

Service Agreements (SAs)

Premises

Service Points (SPs)

Metered versus Item-Based versus Non-Badged Service Points

Service Points With Multiple Items

Putting It All Together

Sample V For A Residential Customer

Sample V For A Commercial Customer With Multiple Premises

How To Set Up Customer Hierarchies

Navigating The V Using Control Central

Control Central - Main

Search Facilities

Search Options

Wild Cards

Search Results

Control Central - Account Information

Account Activity History Zone

Account Financial History Zone

Alert Zone

Applicable Campaigns Zone

Bill Graph Zone

Billed Consumption Zone

Context Zone

Credit and Collections Info Zone

Customer Information Zone

Field Activity Information Zone

Financial Information Zone

Premise Information Zone

SA Premise List Zone

Service Credit Membership Zone

Timeline Zone - Account Info

Timelines Zones Are Configured By Your Implementation Team

The Anatomy Of A Timeline Zone

You Can Move Through Time

Timelines Can Have Many Lines

Each Line Shows Events

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

An Event's Hover-Text Can Contain Additional Information

Clicking On An Event Shows More Information In The Detail Area

Control Central - Customer Information

Communication History Zone

Person Tree Zone

Active Account Summary Zone

Timeline Zone - Customer Info

Control Central - Account Tree

Control Central - Premise Tree

Control Central - Bill/Payment Tree

Control Central - Pay Plan Tree

How To Add A New Customer From Control Central

Finding Who Pays For A Meter

Finding Who Pays For An Item

Maintaining The V

Maintaining Persons

Person - Main Information

Person - Correspondence Information

Person - Characteristics

Person - Persons

Person - Person Portal

Maintaining Accounts

Account - Main Information

Account - Auto Pay

Account - Person Information

Account - Financial Balances

Account - Bill Messages

Account - C&C

How are credit rating transactions created?

How is credit rating calculated?

What impact does credit rating have in the system?

How is cash-only score calculated?

What impact does cash-only score have in the system?

Account - Budget

Account - Deposits

Account - Characteristics

Account - Alerts

Account - Account Portal

Account Management Portal

Account - SAs For A Debt Class

Using The Account / Person Replicator

Information Replicated for New Persons

Information Replicated for New Accounts

Maintaining Service Agreements

The Lifecycle Of A Service Agreement

Renewing Service Agreements

Expiring Service Agreements

Service Agreement - Main Information

Changing A Start Option

The Impact of Proposal Service Agreements

Service Agreement - Rate Info

Rate Information Tree

Service Agreement - SA / SP

Service Agreement - Chars, Qty & Rec. Charges

Service Agreement - Miscellaneous

Service Agreement - Contract Options

Service Agreement - Interval Info

Service Agreement - TOU Contract Values

TOU Contract Values Tree

Service Agreement - Billing Scenarios

Service Agreement - SA Portal

Maintaining SA Relationships

Service Provider SA Relationship

Maintaining Premises

Premise - Main Information

Premise - Characteristics

Premise - Miscellaneous

Premise - Geographic Data

Premise - Alternate Address

Premise - Premise Portal

Maintaining Service Points

Service Point - Main Information

Service Point - Facilities

Service Point - Characteristics

Service Point - SP Type Info

Service Point - Geographic Information

Service Point - Multiple Items

Service Point - Device History

Service Point - Equipment

Service Point - Operations Area

Service Point - SP/SA

Service Point - Field Info

Service Point - SP Route Configuration

Service Point - SP Portal

Dashboard Portal

Current Context Zone

Customer Contact Zone

Financial Information Dashboard Zone

Alert Dashboard Zone

Setting Up Bill Print Groups

Bill Print Group - Main

Bill Print Group - SA Sub Group

Landlord Reversion

Setting Up Landlord Agreements

Using The Premise Replicator

Premise Replicator - Main Information

Premise Replicator - Premise

Premise Replicator - Premise SPs

Start / Stop

The Big Picture Of Starting Service

The Lifecycle Of A Pending Start Service Agreement

Starting Service & Field Activities

What Type Of Start Field Activities Are Created

When Start Field Activities Are Created

How To Start Service Using A Scheduled Meter Read

Activating Pending Starts

What Is Necessary To Start Service?

The System Activates Most Service Agreements Behind-The-Scenes

What Happens At Activation Time?

What Happens After A SA Is Started?

The Big Picture Of Stopping Service

The Lifecycle Of A Pending Stop Service Agreement

Stopping Service & Field Activities

What Type Of Stop Field Activities Are Created

When Stop Field Activities Are Created

How To Stop Service Using A Scheduled Meter Read

Finalizing Pending Stops

The System Finalizes Most Service Agreements Behind-The-Scenes

What Happens At Finalization Time?

What Happens After A Service Agreement Is Stopped?

Start/Stop Maintenance

Start/Stop - Main

Start/Stop - Start Confirmation

Start/Stop - Stop Confirmation

Start/Stop - Address/Phone

Start/Stop - Pending SA

Start/Stop - Pending Field Activity

How To

How To Start Service At A Premise

How To Stop Service At A Premise

How To Start A Deposit

How To Start A Charitable Contribution

How To Start A One-Time Charge Service Agreement

How To Start Service When Multiple Service Points Measure Consumption

The Big Picture Of Customer Contacts

Customer Contacts Are Associated With Persons, NOT Accounts

How Customer Contacts Are Created

Customer Contacts Are Used To Trigger Letters

A Customer Contact May Trigger Reminders

Customer Contacts Can Be Used As Case Files

Maintaining Customer Contacts

Customer Contact - Main

Customer Contact - Log

Customer Contact - Characteristics

Customer Contact - Customer Contact Portal

Printing Letters

Letter Templates Control The Information Merged Onto Letters

BI Publisher Versus Documaker

Where Does The Address Come From?

Technical Implementation Of Online Letter Images

Technical Implementation Of Batch Letter Production

Reproducing The Letter Print Flat File

How To Reprint A Specific Letter

The Documaker Records

Printer Keys (Record Types)

Sort Key

Mailing Key

Letter Information

Global Information Record

Letter Record

Mailing Information Record

Collection Process / Event Record

Severance Process / Event Record

Write Off Process / Event Record

Workflow Process / Event Record

Overdue Process / Event Record

End of Letter Record

Definition of Address Subrecord

The Word Records

Additional Fields For A Collection Process / Event Letter

Additional Fields For A Severance Process / Event Letter

Additional Fields For A Write Off Process / Event Letter

Additional Fields For A Workflow Process / Event Letter

Additional Fields For An Overdue Process / Event Letter

Maintaining Declarations

Service Tasks

The Big Picture of Service Tasks

Searching and Viewing Service Tasks

Self-Service Tasks

The Big Picture of Service Tasks

Searching and Viewing Self-Service Tasks

About Self-Service Task Types

Defining Self-Service Task Types

Meter Management

Background Topics

Meters versus Items versus Equipment

Meters & The V

Items & The V

Gaining Access To The V Using Meter/Item Search

Meter/Item Search - Main

Maintaining Meters

Meter - Main Information

Meter - Meter ID

Meter - Characteristics

Meter - SP Installation History

Meter - Equipment

Meter - Location History

Meter - Meter Tree

Meter - Meter Portal

Maintaining Meter Configurations

Changing A Configuration

Meter Configuration Maintenance

Meter Configuration - Main Information

Regular (Non Interval) Meter Configuration Maintenance

Interval Meter Configuration Maintenance

Meter Configuration - Meter Configuration Tree

Meter Configuration - Meter Configuration Portal

Validating Register Constants

Maintaining Items

Item - Main Information

Item - Characteristics

Item - SP Installation History

Item - Equipment

Item - Location History

Installing / Removing A Meter

SP / Meter Installation

SP Meter Installation History

Installing / Removing An Item

SP / Item Installation

SP Item Installation History

Testing A Device

The Lifecycle Of A Device Test

Device Test - Main

Device Test - Characteristics

Device Test - Components

Device Test Selection

Meter Replicator

Meter Replicator - Main Information

Meter Replicator - Meter

Meter Replicator - Meter Configuration

Item Replicator

Item Replicator - Main Information

Item Replicator - Item

Usage Requests

Usage Query

Usage - Main

Actions

Usage

Usage - Log

Meter Reading

Background Topics

The Cyclical Meter Read Process

Managing Metered Service Routes

High / Low Checks

Meter Reads and Billing

Meter Read Maintenance

Meter Read - Main

Meter Read - Characteristics

Meter Read - Meter Read Portal

Correcting Reads Versus Entering New Reads

Meter Read Remark Exceptions

Setting Up Trends

Trends Are Updated Behind-The-Scenes

Maintaining Trends

No Trends At Startup

Renumber Service Route Sequences

Service Route Transfer

Service Route Transfer - Main

Service Route Transfer - Transfer To

Read History

Downloading Meter Reads

Meter Read Download Processes

MSR - Create Service Schedule Routes

MDS - Create Download Staging

MDL - Create Download Flat File

Uploading Meter Reads

Meter Read Upload Background Processes

Process X - Populate MR Upload Staging

Meter Read Upload Staging

Upload Register Read

Upload Read Remark

Upload Read Characteristics

MUP1 - Populate Meter Configuration

MUP2 - Create Meter Read

MRUP-PRG - Purge Meter Read Upload Objects

MR Upload Staging

MR Upload Staging - Main

MR Upload Staging - Remarks

MR Upload Staging - Characteristics

MR Upload Exception

TD-HILO - To Do for Meter Read High/Low Errors

Low / Very Low

High / Very High

Set Use On Bill

Multiple Register Priority

Create ToDo Entry

Review High / Low

Field Order

The Big Picture Of Field Orders

An Illustration Of A Field Order And Its Field Activities

An Illustration Of The Entities Involved In Field Order Dispatch

Field Activity Type Controls What Is Done In The Field

The Lifecycle Of Field Activities And Field Orders

How Are Field Activities Created?

How Are Field Orders Created And Dispatched?

How Does A Field Order Get Routed To A Field Crew?

How Does A Field Order Get Completed?

What Happens After A Field Activity Is Completed?

How To Schedule Appointments

Dispatch Field Activities Automatically

The Daily Tasks Of A Dispatcher

Dispatching Field Activities

Marking Field Orders As Being Worked

Look For Orders That Have Slipped Through The Cracks

How To Handle Unusual Situations

Tidying Up Field Orders That Were Not Worked

Hold A Field Activity

Canceling A Field Activity

Printing Field Orders

Dispatch Groups Control The Information Merged Onto Field Orders

Technical Implementation Of Online Field Order Image

Technical Implementation Of Batch Field Order Production

Reproducing The Field Order Print Flat File

How To Reprint A Specific Field Order

Who Gets A Copy Of A Field Order?

The Documaker Records

Printer Keys (Record Types)

Sort Key

Field Order Information

Field Order Maintenance

Lifecycle of a Field Order

Field Order - Main Information

Field Order - Field Activities

Field Activity Maintenance

Lifecycle of a Field Activity

Field Activity - Main Information

Field Activity - Steps

Field Activity - Characteristics/Remarks

Field Activity - Field Activity Portal

Field Activity - Log

FA Log Entry Events

How To Add A Step To A Field Activity

Field Activity Remark Exceptions

Group Premise FAs (Field Activities)

Using Alternate Dispatch Groups To Find The Lowest Common Denominator

Field Order Search

Field Order Search Dialog

Field Order Query Page

Dispatch Field Activities

Field Activity Search Dialog

Field Activity Query Page

How Do You Link An Activity To An Existing Order?

Downloading Field Orders

The Field Order Download Processes

FDS - Create Download Staging

FODL - Create Download Flat File

Uploading Field Order Completion Information

Field Order Completion Upload Background Processes

Process X - Populate MR and FA Upload Staging

Meter Read Upload Staging Tables

Field Activity Upload Staging

Field Activity Step Upload Staging

Field Activity Characteristic Upload Staging

Field Activity Remark Upload Staging

MUP1 - Populate Meter Configuration

MUP2 - Create Meter Read

FACOMPL - Upload and Complete Field Activities

FAUP-PRG - Purge Field Activity Upload Objects

Maintaining Field Activity Upload Staging

FA Upload Staging - Main

FA Upload Staging - Steps

FA Upload Staging - Characteristics/Remarks

How To

How To Complete A Simple Field Activity That Requires A Read

Field Activity Upload Exception

Outage Calls

Outage Call Actions

Outage Call Zone

Outage Call Log

Outage Information

Job History

Call History

Planned Outages

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

Credit Notes - Presenting Cancellation Details on a Separate Bill

Credit Notes Are Only Possible if the Installation Option Is Turned On

Credit / Correction Notes and Auto Pay

Adjustments On Credit Notes

Credit Note Routing Suppression

Correction Notes - Presenting Correction Details on a Separate Bill

Correction Notes Are Only Possible if the Installation Option Is Turned On

Correction Notes Versus Credit Notes

Correction Notes and Auto Pay

How The System Determines How Much Was Consumed

Meter Read Snapshot

Determine The Bill Period For Metered Service

Determine The Consumption Period For Metered Service

Determine The Service Agreement's Billable Service Points

Determine The Service Points' Meters

Determine The Meters' Start And Stop Meter Reads

Item Snapshot

Service Quantity Snapshot

Calculation / Audit Read Details

Calculation / Audit Usage Details

How To Override The Commodity Amount In A Bill Segment

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 Meter Read Date Method

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

Determining the Statistical Quantity

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 Customer Balances

Auto Cancel / Rebill If A Service Agreement Is Stopped Retroactively

Cancel Historical, Estimated Bill Segments When A Real Read Is Found

Deposits May Be Refunded

FT Freeze Repercussions

Budget Billing

Account versus Service Agreement

How To Set Up A Customer To Participate In A Budget Plan

The Financial Impact Of Budget Plans

Budget Billing Background Processes

Budget True Up

Budget Monitor

Canceling A Budget

Net Energy Metering

What Is Net Energy Metering?

Net Energy Metering Service Agreements

Net Energy Metering True Up

The Lifecycle of a True Up Monitor

Setting Up the System for Net Energy Metering

Net Energy Metering Billing Examples

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

The Documaker Records

Printer Keys (Record Types)

Sort Key

Mailing Key

Bill Information

XML Bill Extracts

Sequential Bill Numbers

Sequential Numbers Are Only Assigned If The Installation Option Is Turned On

Pending Bills Do Not Have A Sequential Bill Number

When / How Is The Sequential Bill Number Assigned

Additional Functionality for Sequential Bill Numbering

Document Numbers

Document Numbers Are Only Assigned If the Installation Option Is Turned On

Pending Bills Do Not Have a Document Number

When/How Is the Document Number Assigned

Additional Functionality Exists When Document Numbers Are Used

Digital Signatures

Writing Off Bills

Idiosyncratic Manual Bill Cancellation

Maintaining Bills

Bill Lifecycle

Bill - Main Information

Generate

Freeze

Cancel Frozen

Freeze / Complete

Complete

Delete

Reopen

Credit Note

Correction Note

Write Off

Reverse Write Off

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)

Credit Note (Bill - Bill Segments)

Correction Note (Bill - Bill Segments)

Bill - Bill Routings

Bill - Bill Messages

Bill - Characteristics

How To

How To Create A Bill For All Service Agreements Linked To An Account

How To Create A Bill For A Specific Service Agreement

How To Create a Bill with no Bill Segments

How To Create A One-Time Invoice

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 Create A Credit Note

How To Create A Correction Note

How To Create An Off Cycle Bill Generator

How To Override Service Quantities On A Specific Bill Segment

How To Override The Items Billed On A Specific 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)

Credit Note (Bill Segment)

Bill Segment - Read Details

Bill Segment - Item Details

Bill Segment - SQ Details

Bill Segment - Calc Lines

Bill Segment - Financial Details

Bill Segment - Bill Segment Messages

Bill Segment - Sub Bill Segments

Bill Segment - Bill Segment Portal

Bill Segment - Usage

Financial - Bill Segment Calculation Line Characteristics

Off Cycle Bill Generator

Off Cycle Bill Generator Query

Off Cycle Bill Generator Portal

Off Cycle Bill Generator Actions

Off Cycle Bill Generator Zone

Financial Transactions On Bill

Off Cycle Bill Generator Log

Multi Cancel/Rebill

Multi Cancel/Rebill - Main

Multi Cancel/Rebill - Graph

SA Billing History

Bill Exception

Bill Segment Exception

Maintaining Billable Charges

Billable Charge - Main

Billable Charge - Line Characteristics

Billable Charge - SQ Details

Billable Charge - Read 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 Service Quantity Upload Staging Layout

Billable Charge Read 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 - SQ Details

Billable Charge Upload - Read Details

Billable Charge Upload Exception

Budget Review

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

Distributing A Payment Event

Distributing A Payment Amongst An Account's Service Agreements

Overpayment

Canceling A Tender Versus Canceling A Payment

NSF Cancellations

Transferring A Payment

Unbalanced Payment Events

How And When Payments Appear On Bills

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 Customer Balances

Open Item Accounting and Match Events

FT Freeze Repercussions

Automatic Payments

How To Set Up A Customer To Pay Automatically

What Are Automatic Payments?

How And When Are Automatic Payments Created?

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 Payments

Non-billed Budgets and Automatic Payment

Downloading Automatic Payments and Interfacing Them To The GL

ACTVTAPY - Activating Automatic Payments

APAYACH - Download Automatic Payments To The ACH (automated clearing house)

C1-APACH - Download Automatic Payments To The ACH (automated clearing house)

C1-SDDCE SEPA Direct Debit Payment Extract

BALAPY - Creating Automatic Payment Tender Controls

ACH Record Layouts

File Header Record

Company Batch Header Record

Entry Detail Record

Company Batch Control Record

File Control Record

SEPA Direct Debit Record Layouts

Group Headers

Payment Information

Direct Debit Transaction Informatjon

Issuing A Payment Advice Instead Of Creating An Automatic Payment

How To Set Up A Customer 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 - Characteristics

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 Quick Add

Multiple Payment Events Dialog

Single Payment Event Dialog

Payment Quick Add

Maintaining Payments

Payment - Main

Payment - Pay Segments

Payment - Manual Distribution

Payment - Characteristics

Payment Action Codes

Distribute (A Payment)

Redistribute (A Payment)

Confirm (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)

Payment Portal

Credit Card Payments

Non CIS Payments

Alternate Currency Payments

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 Service Agreement

How To Get An Unbalanced Tender Control In Balance (Fixing Over/Under)

How To Add A Non-CIS Payment Using A Template

How To Authorize A Credit Card Tender

How To Reverse A Credit Card Tender

How To Process An Alternate Currency Payment

Financial Transactions On A Payment

Payment History

Payment Tender 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

Deposit Control - Characteristics

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

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 Staging - Characteristics

Payment Upload Exception

Interfacing Payments Using Distribution Rules

Populating The Payment Event Upload Staging Records

Process X - Populate Payment Event Upload Staging

Data Setup Examples of Payment Distribution Details

The Lifecycle of a Payment Event Upload Staging Record

To Do Entries Instead of Exception Records

Process C1-PEPL1 - Upload Payments (Step 1)

Process C1-PEPL2 - Upload Payments (Step 2)

Process C1-PEPL3 - Upload Payments (Step 3)

Payment Event Upload Staging

Payment Event Upload Staging - Main

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

Canceling Adjustments

Transfer Adjustments

Calculated Adjustments

Adjustment Amount May Be Positive, Negative Or Zero

Adjustment Type Controls Everything

Controls Which Balance(s) Are Affected

Defines The GL Account Affected By The Adjustment

Defaults The Adjustment Amount

Calculates The Adjustment Amount

Controls The Interface To A/P & 1099 Reporting

Controls Information Printed On The Bill

Controls If The Adjustment Can Be Frozen Prior To Bill Completion

Controls If The Adjustment Requires Approval

Unbilled Adjustments And Aged Debt

An Adjustment May Affect More Than Just Customer Balances

Maintaining Adjustments

The Lifecycle Of An Adjustment

Adjustments - Main Information

Adjustments - Characteristics

Adjustments - Transfer Adjustment

Adjustments - A/P Request

Adjustments - Adjustment Portal

Adjustments - Approval

Adjustment Information

Approval Request

Approval Request Log

Financial - Adjustment Calculation Line Characteristics

How and When To Use An Adjustment

How To Create A Transfer Adjustment

How To Create A Calculated Adjustment

How To Cancel An A/P Adjustment After It Has Been Selected By A/P

How To Correct Normal Service Agreement Debt

How To Apply Ad Hoc Fees To A Service Agreement

How To Apply Interest To A Deposit

How To Apply A Deposit To Outstanding Debt

How To Refund A Deposit With A Check

How To Write-Down Deposit Due

How To Refund A Credit Balance With A Check

How To Transfer A Credit Balance To A Service Agreement In Arrears

How To Change The Age Of Debt

How To Write-Down A Charitable Contribution Service Agreement Debt

How To Write-Off Debt

How To Cancel A Service Agreement's Budget

How To Adjust A Service Agreement On A Budget

How To Adjust An Installment Plan Service Agreement

How To Use An Adjustment To Change The GL Distribution

Interfacing Adjustments From External Sources

Interfacing Adjustments

Process X - Populate Adjustment Upload Records

Adjustment Staging Control

Adjustment Staging Control Characteristic

Adjustment Upload Staging

Adjustment Characteristic Upload Staging

The Lifecycle of an Adjustment Staging Control Record

The Lifecycle of an Adjustment Upload Staging Record

Process C1-ADUP1 - Preprocess Adjustment Uploads

Phase 1 - Validate Adjustment Staging Controls

Phase 2 - Populate SA ID

Process C1-ADUP2 - Upload Adjustments

Suspense Adjustments

What Are Suspense Adjustments?

How Are Suspense Adjustments Resolved?

Process C1-ADURS - Resolve Suspense Adjustments

Maintaining Adjustment Staging Control

Maintaining Adjustment Upload Staging

Credit & Collections

The Big Picture Of Credit & Collections

Automating Your C&C Activities

The Lifecycle Of A Collection Process And Its Events

What Is A Collection Process?

How Are Collection Processes Created?

How Are Collection Events Completed?

How Are Collection Processes (and their Events) Canceled?

What Happens If A Payment Is Not Received?

The Collection Process Background Processes

Account Debt Monitor

Collection Event Activator

Collection Process Monitor

The Lifecycle Of A Severance Process And Its Events

What Is A Severance Process?

How Are Severance Processes Created?

How Are Severance Events Completed?

How Are Severance Processes (and their Events) Canceled?

What Happens If The Customer Does Not Pay?

The Severance Process Background Processes

Severance Event Activator

Completing Severance Events That Are Dependent On The Completion Of A Field Activity

Set Trigger Date

The Lifecycle Of A Write Off Process And Its Events

What Is A Write-off Process?

How Are Write-off Processes Created?

How Are Write-off Events Completed?

How Are Write-off Processes (and their Events) Canceled?

What Happens If The Debt Is Not Paid?

How Is Debt Referred To Collection Agencies

The Write-Off Process Background Processes

Write-Off Monitor

Write-Off Event Activator

Collection Process Maintenance

Collection Process - Main Information

Collection Process - SAs (Service Agreements)

Collection Process - Events

How To Perform Common Collection Process Functions

How To Create A Collection Process

How To Change Collection Events

How To Cancel A Collection Process

Severance Process Maintenance

Severance Process - Main Information

Severance Process - Severance Events

Severance Process - Field Activity/Customer Contact

How To Perform Common Severance Process Functions

How To Create A Severance Process

How To Change Severance Events

How To Cancel A Severance Process

Write-off Process Maintenance

Write-off Process - Main Information

Write-off Process - SAs (Service Agreements)

Write-off Process - Events

How To Perform Common Write-off Process Functions

How To Create A Write-off Process

How To Change Write Off Events

How To Cancel A Write Off Process

Writing Off Uncollectable Debt

Write Off - Main

How To Manually Write-Off Debt

Write Off - Write Off SAs

Collection Referral

Payment Arrangements and Pay Plans

Setting Up Payment Arrangements

Pay Arrangement - Main

How To Set Up A Payment Arrangement

How To Add Additional Debt To A Payment Arrangement

How To Break A Payment Arrangement

How To Cancel A Payment Arrangement

Pay Arrangement - History

Setting Up Pay Plans

Pay Plan - Main

How To Set Up A Pay Plan

Reviewing Pay Plans

Financial Transactions

The Big Picture Of Financial Transactions

Bill Segment Financial Transactions

Payment Segment Financial Transactions

Adjustment Financial Transactions

Financial Transactions And Aged Debt

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 Service Agreement May Be Closed

A Closed Service Agreement May Be Reactivated

A Write-Off Process May Be Deactivated If The SA Is Closed

A Reactivated Service Agreement May Be Closed

A Collection Process May Be Canceled When A Credit FT Is Frozen

A Severance Process May Be Canceled When A Credit FT Is Frozen

One Or More Algorithms May Be Executed

The Big Picture of Balance Control

The Balance Control Background Processes

BCGNEW - Create A New Balance Control Group

BCASSIGN - Assign New Financial Transactions A Balance Control Group

BCGSNAP - Insert BC Members And Check Financial Integrity Of All FTs

Consider A Backup At This Point

Balance Control Information Is Available Online

The GL Interface

GLASSIGN - Assign GL Account Numbers To GL Details

GLS - Prepare FTs for Download

GLDL - Create General Ledger Download Flat File

Header Record Layout

Detail Record Layout for GLDL

Financial Transaction

Financial Transaction - Main

Financial Transaction - FT Process

Account Financial History

Account Bill / Payment History

SA Financial History

SA Non-Accrual 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

Deposits

The Big Picture Of Deposits

Cash Deposits

Refunding Deposits

Partial Refunds

Total Amount To Bill

Current Balance versus Payoff Balance

Multiple Deposits Linked To A Single Account

Deposits and Credit & Collections

Deposit Seizures When Other SAs Are Stopped

Non-Cash Deposits

3 Party Deposits

Deposit Class Controls Everything

Controls Interest Calculation

Controls The Recommended Deposit Amount

Defines The Conditions That Cause The System To Recommend A New or Additional Deposit

Defines Automatic Refund Conditions

Controls How Deposits Are Refunded To A Customer

Deposit Background Processes

Deposit Interest

Deposit Refund

Review Deposits

Deposit Review

Interval Billing

Interval Pricing Background Topics

Billable Interval Quantities for a Service Agreement

Interval Quantities are Stored in Data Sets

Fixing Errors with Complete Data Sets

Algorithms Find the Most Up To Date Data

Time Issues

Start and End Times for Billing

Billing Time Examples

First and Last Bill Segment Considerations

Defaulting Service Agreement Time Options

Changing Service Agreement Time Options

Time Zone and Time Changes

Data is Stored in the Base Time Zone

Seasonal Time Shifts

Interval Data Serves a Role for a Service Agreement

Common Profiles vs. SA Owned Profiles

Flexibility of SA / Profile Link

The Link between Profile and SA is Effective Dated

Creation of Profile Data through Data Derivation

The Big Picture of Data Derivation

Determining What Interval Data To Derive

Preventing Gaps in Data

Using The Latest Updates to Source Data

Force Derivation of Interval Data

Process IB-SPDB - SA Interval Profile Data Creation

Validation of Profile Data

Process IPDSDVB - Interval Profile Data Validation

Auditing Your Interval Pricing Bill Lines

The Big Picture of Raw Data Collection and Aggregation

Interval Channels and Index Channels

Installation of Interval and Index Channels

Validation of Register Data

Process IREGDVB - Interval Register Data Validation

Processing Raw Data

Time of Use Mapping Background Topics

Time Period Definitions are Stored in Data Sets

Sharing TOU Map Data

TOU Map Common To All SAs on the Rate

TOU Map Common To a Subset of Service Agreements

TOU Map Owned by a Service Agreement

TOU Maps Linked to a Service Agreement

TOU Maps Serve a Role for a Service Agreement

The Link between TOU Map and SA is Effective Dated

Customer Specific TOU Values

Generating Data for a TOU Map

Automatic Creation of TOU Map Data

Determining What TOU Data To Derive

Force Derivation for TOU Map Data

Process IB-STDB - SA TOU Data Creation

Auditing Your TOU Pricing Bill Lines

Contract Option Background Topics

Overview

A Contract Option Has Events

Options and Events May Have Characteristics

SA May Override a Shared Event

Validation of Events

Maintaining Interval Data

Account Interval Info Maintenance

Interval Profile Maintenance

Interval Profile - Main

Interval Profile - Related SAs

Maintaining Interval Profile Data

Life Cycle of Interval Profile Data Sets

Interval Data Maintenance

Interval Data Query

Upload Interval Data

Process X - Populate Interval Data

Interval Data Set

Interval Data

Interval Data Set Key

Process IPDSIDB - Determine Profile For Profile Datasets

Interval Data Exception

How To Correct a Data Set in Error

Maintaining Interval Register Data

Life Cycle of Interval Register Data Sets

Interval Register Data Maintenance

Interval Register Data Query

Upload Interval Register Data

Process X - Populate Interval Register Data

Register Data Set

Register Data

Register Data Set Key

Process IREGIDB - Determine Register For Register Datasets

Interval Register Data Exception

How To Correct a Register Data Set in Error

TOU Map Maintenance

TOU Map - Main

TOU Map - Generate

TOU Map - Related SAs

Maintaining TOU Map Data

Life Cycle of TOU Data Sets

TOU Data Maintenance

TOU Data Query

Upload TOU Map Data

Process X - Populate TOU Map Data

TOU Data Set

TOU Data

TOU Data Set Key

TOU Data Exception

How To Correct a TOU Data Set in Error

Contract Option Maintenance

Contract Option - Main

Contract Option - Related SAs

Maintaining Contract Option Events

Life Cycle of Contract Option Events

Contract Option Event Maintenance

Contract Option Event Exception

How To Correct a Contract Option Event in Error

Interval Billing Calculation Details

Interval Pricing Details - Main

Interval Pricing Details - Details

Interval Pricing Details - SA Information

TOU Pricing Calc Details - Main

TOU Pricing Calc Details - Details

TOU Pricing Calc Details - SA Information

Interval Billing Examples

How to Link Common Profiles to a Service Agreement

How to Link SA Owned Profiles to a Service Agreement

For The SA That Is The Owner

For The SA That Is Not The Owner

Hedge Cover

Hedge Cover - Bill Factors

Hedge Cover - Profile Relationship Types

Hedge Cover - Profile Types

Hedge Cover - Rate Schedule and Rate Components

Hedge Cover - Common Profile

Hedge Cover - SA Type

Hedge Cover - Start Option

Hedge Cover - Service Agreements

Hedge Cover - Typical Business Flow

Tunnel Option

Tunnel Option - Bill Factors

Tunnel Option - Profile Relationship Types

Tunnel Option - Profile Types

Tunnel Option - Data Derivation Algorithm

Tunnel Option - Rate Schedule and Rate Components

Tunnel Option - Common Profile

Tunnel Option - SA Type

Tunnel Option - Start Option

Tunnel Option - Service Agreements

Tunnel Option - Typical Business Flow

Override Maps

Override Maps - TOU Codes and TOU Group

Override Maps - Rates and Bill Factors

Override Maps - Profile Relationship Type and Profile Type

Override Maps - Contract Option Types and Contract Option Event Types

Override Maps - Map Relationship Type and Map Type

Override Maps - TOU Map Templates

Override Maps - SA Characteristic

Override Maps - TOU Data Creation Algorithm

Override Maps - SA Type

Override Maps - Start Option

Override Maps - Service Agreements

Override Maps - TOU Map Data

Override Maps - Typical Business Flow

Statements

The Big Picture of Complex Statements

Constructing Statements

Producing Statements

Statement Cycles

Create Statements Background Process

Statement Routing

Where Are Statements Sent

On-line Statement Production

How to Regenerate a Specific Statement

Printing Statements

Statement Route Types Control The Information Merged Onto Statements

Technical Implementation Of Online Statement Image

Technical Implementation Of Printing Statements In Batch

Reproducing The Statement Print Flat File

How To Reprint A Specific Statement

The Documaker Records

Printer Keys (Record Types)

Sort Key

Mailing Key

Statement Information

Statement Construct Maintenance

Lifecycle of a Statement Construct

Statement Construct - Main

Statement Construct - Details

Statement Maintenance

Lifecycle of a Statement

Statement - Main

Statement - Details

Sales & Marketing

The Big Picture of Campaigns, Packages and Orders

An Overview of Campaigns, Packages and Orders

Supported Business Processes

Marketing to Prospects from a Marketing List

Marketing to Pre-selected Customers

Real-time Marketing of Additional Services to a Customer

Real-time Marketing of Services to a Prospect

Setting up a New Customer Prior To Using Start/Stop

Examples of Campaigns and Packages

Campaigns Without Packages

Marketing Surveys

Prelude to Start/Stop

Campaigns With Simple Packages

An Easier Way To Create One Time Charges

Campaigns With Complex Packages

Packages Limited By Answers And Field Values

Packages Limited By Current State Of Service

The Big Picture Of Package Eligibility Rules

Criteria Groups versus Eligibility Criteria

Defining Logical Criteria

Examples Of Package Eligibility Rules

A Package That Is Always Eligible

A Package With A Time Span Comparison

A Package With Service Type Comparison

A Package With More Complex Operators

The Big Picture Of Campaign Eligibility Rules

Campaign Eligibility Rules Are Not Strictly Enforced

Campaign Eligibility Rules Are Defined Using Algorithms

Examples Of Campaign Eligibility Rules

ACampaign That Is Always Eligible

ACampaign That Is Never Eligible

A Campaign For Residential Customers

A Campaign For California, Residential Customers

Designing Campaigns and Packages

Determine The Place Of Start / Stop

Determine Which Types Of Service Agreements Are Created

Determine The Different Start Options That Exist For Each Type Of Service Agreement

Determine The SP Type (if any) For Each Service Agreement

Determine The Method Used To Create Each Service Agreement

Extract Algorithms From The Start Method

Determine Which Combinations Can Be Grouped Under A Package

Determine Package Eligibility Rules

Eligibility Rules For Package 1

Eligibility Rules For Package 2

Eligibility Rules For Package 3

Eligibility Rules For Package 4

Extract Algorithms From The Eligibility Rules

Extract Miscellaneous Fields From The Eligibility Rules

Determine Additional Information That Is Required If A Package Is Selected

Determine If There Are Additional Questions / Fields For Your Packages

Determine If Additional Instructions Should Be Shown

Determine If There Are Campaign-Level Fields / Questions

Determine The Properties Of Every Miscellaneous Field

Extract Characteristic From The Miscellaneous Fields

Extract Column References From The Miscellaneous Fields

Extract Algorithms From The Column References

Determine Account / Premise Dependency For Each Column Reference

Determine If Any Properties Are Overridden On Any Package

Determine The Eligibility Rules For The Campaign

Determine How The Campaign Behaves

Setup Sequence

Other Useful Information

Order versus Start / Stop

Orders Cannot Be Changed After They Are Completed

Premise and SP Characteristics May Be Populated From Postal Defaults

To Do List Processing

Hold and Cancel Reason Codes

Additional Things Can Happen When An Order Is Completed

New Premises and Accounts Are Only Created if an Order is Completed

Premise Geographic Types Are Populated In An Unusual Way

Account And Premise Usage Are Controlled By The Campaign

Maintaining Orders

Lifecycle of an Order

Order User Interface Flow

Order - Main

Order - Main - Person Information

Order - Main - Service Address

Order - Main - Account Information

Order - Questions & Misc. Fields

Order - Log

Order - Package Confirmation

Order - Hold Dialog

Order - Cancel Dialog

Maintaining Campaigns

Lifecycle of a Campaign

Campaign - Main

Campaign - Questions and Misc. Fields

Campaign - Algorithm

Campaign - Package

Maintaining Packages

Lifecycle of a Package

Package - Main

Package - SAs To Create

Package - Questions & Misc Fields

Package - Eligibility

Package - Instructions

Program Management

The Big Picture of Initiatives, Leads and Sales Representatives

The Big Picture of Initiatives

The Components of an Initiative

About Initiative Eligibility Criteria

Examples of Initiative Eligibility Criteria

About Lead Event Type Profile

About Initiative Log

The Lifecycle of an Initiative

Initiative Information in Overridable

About Initiative Hierarchies

The Big Picture of Leads

How are Leads Created

The Components of a Lead

The Lifecycle of a Lead

Lead Information Can Be Overridden

Leads are Highlighted As Alerts

How and When Are Leads Activated

How Are Leads Completed

How to Discard a Lead

The Big Picture of Lead Events

How are Lead Events Created

The Components of a Lead Event

The Lifecycle of a Lead Event

Lead Event Information in Overridable

How and When Are Lead Events Activated

Activating Events Should Add A Log Entry

How Are Lead Events Cancelled

The Big Picture of Sales Representatives

Sales Representative Log

The Lifecycle of a Sales Representative

Maintaining Initiatives

Initiative Portal

How To Perform Common Initiative Functions

Creating Initiatives

Maintaining an Initiative

Allowable Record Actions on an Initiative

Defining Eligibility Criteria for an Initiative

Viewing Initiative Hierarchy

Creating Leads from an Initiative

Bulk Creation of Leads

Uploading Leads

Managing Leads from an Initiative

Viewing Lead Summary by Representative

Initiatives Leads Zone

Activating / Deleting / Discarding Leads for an Initiative in Bulk

Graphs and Statistics for an Initiative

Maintaining Leads

My Leads

Lead Portal

How To Perform Common Lead Functions

Manual Creation of a Lead

Maintaining a Lead

Adding New Lead Events to a Lead

Navigating to Related Leads

Maintaining Lead Events

Maintaining Sales Representatives

Sales Representatives Portal

How To Perform Common Sales Representative Functions

Creating Representatives

Maintaining Representatives

Displaying Leads Associated Information for a Sales Representative

Displaying Leads and Lead Event Information for a Sales Representative

Sales Representative Initiatives Leads Zone

Reassigning Leads for a Sales Representative

Initiatives Lead Event Type Summary

Initiatives Lead Events Summary

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

UOM versus TOU versus SQI

Defining Measured Quantity Manipulation Rules

When And How To Manipulate Measured Consumption

Setting Up Register Rules

Base Package Register Rules

How To Setup A Register Rule To Adjust A Cubic Foot Of Gas Based On Pressure

How To Set Up A Register Rule To Convert Cubic Feet To Therms

How To Set Up A Register Rule To Price Interval Consumption Using Interval Prices

Setting Up Service Quantity (SQ) Rules

Base Package SQ Rules

How To Set Up An SQ Rule To Add Together Two Service Quantities

Defining Service Quantity (SQ) Identifiers

Setting Up A Rate Schedule

Rate Schedule - Main

Rate Schedule - SQ Rules

Rate Schedule - Register Rules

Rate Schedule - Bill Messages

Rate Schedule - Meter Configuration Type

Rate Schedule - Sub Rates

Rate Schedule Merge

Removing A Row

Adding A New Row

Removing An Uncommitted Row

Moving Rows Up and Down

Setting Up Bill Factors

An Overview Of Bill Factors

The Structure Of A Bill Factor

An Illustration Of A Bill Factor And Its Characteristics

Deriving / Passing In Characteristic Values

Bill Factor Interval Values

Interval Values Can Be Used For More Than Just Interval Prices

Interval Data is Stored in Data Sets

Bill Factor TOU Values

TOU Values Can Be Used For More Than Just Prices

TOU Values May Differ By Customer

Defining Bill Factors

Defining General Bill Factor Information

Setting Up Bill Factor Characteristics

Defining Bill Factor Values

Bill Factor Value - Main

Bill Factor Value - GL Distribution

Defining Interval Values

Bill Factor Interval Values Query

Upload Interval Values

Process X - Populate Interval Data

Interval Value Set

Interval Value

Interval Value Set Key

Defining Bill Factor TOU Values

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 Service Quantity Comparison

A Rate Component With A Time Span Comparison

A Rate component With Service Type Comparison

Defining Rate Components

Rate Component - Main Information

How To

How To Set Up Flat Charge Rate Components

How To Set Up Service Quantity Rate Components

How To Set Up Item Type 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 Interval Pricing Rate Components

How To Set Up TOU Pricing 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 - SQ Details

Rate Check Results - Register Read

Rate Check Results - Characteristics

Use Sub Rate Schedules To Encapsulate Common Rate Components

Sub Rate Schedules and Primary Rate Schedules Have Similar Features

Primary Rates May Reference Many Sub Rates

How To Set Up A Sub Rate Schedule

Setting Up Estimated Consumption For Items

Setting Up Degree Days (and Average Temperatures)

Effective Dates & Price Proration

Types of Proration

Consumption Period Proration

Calculation Period Proration

Bill Factor Proration

Tax Exemption Proration

Contract Value Proration

Contract Rider Proration

A Service Agreement Rate Changes Are Not Prorated

Proration Factors

Normal Days

Consumption Period Factor

Calculation Period Factor

BF Value Period Factor

Overriding Proration Factors

Service Quantity Proration

Measures Peak

Step Proration

Step Multipliers

Rate Component Value Proration

Bill Factor Value Proration

Example of Generating Prorated Bill Calculation Lines

Seasonal Proration

Price Changes and Interval Quantities

Rate Examples

A Simple Electric Rate

Adding Measured Quantities Together

CCF To Therm Conversion

How To Adjust Measured Consumption By A Minimum Contract Quantity

Elevation Charges

Elevation Charges - Characteristics

Elevation Charges - Bill Factors

Elevation Charges - Rate Schedule and Rate Components

Gas Pressure Factor Adjustments

Pressure Factor - Characteristics

Pressure Factor - Bill Factors

Pressure Factor - Register Rule

Pressure Factor - Rate Schedule

Pricing Interval Consumption Using Interval Prices

Real Time Pricing - Bill Factors

Real Time Pricing - Service Quantity Identifier

Real Time Pricing - Register Rule

Interval Billing - Rate Schedule

Pricing Non Interval Consumption Using Weighted Average Prices

Weighted Average Pricing - Bill Factors

Weighted Average Pricing - RC Algorithm

Weighted Average Pricing - Rate Component

Employee Discounts

Employee Discounts - Characteristics

Employee Discounts - Bill Factors

Employee Discounts - Rate Schedule and Rate Components

Employee Discounts - Start Option

Employee Discounts - Service Agreements

Customer Specific Prices

Customer Specific Prices - Bill Factors

Customer Specific Prices - Rate Schedule and Rate Components

Customer Specific Prices - Start Option

Customer Specific Prices - Service Agreements

Hours-Based Electric Rate

Hours-Based - For Calculation Purposes Only Rate Component

Hours-Based - Dynamic Stepped SQ Rate Components

Hours-Based - Descriptions On Bill

Step Boundaries Based On The Number Of Days Of Usage And The Region In Which The Customer Resides

Dynamic Steps - SQ Rule On The Rate Schedule

Dynamic Steps - For Calculation Purposes Only Rate Component

Dynamic Steps - Bill Factors

Dynamic Steps - Dynamic Stepped SQ Rate Components

Dynamic Steps - Descriptions On Bill

Calculated Minimum Charges

Calculated Minimums - SQ Rule On The Rate Schedule

Calculated Minimums - For Calculation Purposes Only Rate Component

Calculated Minimums - Description On Bill

Stepped Taxes

How To Add A New Service Quantity Rule Algorithm

How To Add A New Register Rule Algorithm

Quotes

The Big Picture Of Quotations

Basic Quotation Concepts

A Quote Shows How Bill Segments Might Look

Proposal Service Agreements Must Exist

Proposal SAs Contain Pricing Terms

Legal Terms and Conditions May Be Specified On Both Proposal And Real SAs

Proposal SAs Contain Billing Scenarios And Template Consumption

Proposal SAs Differ From Real SAs

Proposal SA State Transition

Orders Are Used To Create Proposal SAs

Proposal SAs May Be Grouped Under An Umbrella Agreement

Proposal SAs And Interval Consumption

Creating Quotes And Quote Details

Completing A Quote Creates Quote Routings (And More)

Accepting / Declining Quote Details

Tinkering With Proposal SAs After Quote Generation

Closing Quotes

Alerts

Trees

Printing Quotes

Quote Routings Are Created For Each Recipient Of A Quote

Quote Route Types Control The Information Merged Onto Quotes

Technical Implementation Of Online Quote Image

Technical Implementation Of Printing Quotes In Batch

Reproducing The Quote Print Flat File

How To Reprint A Quote (For The Original Recipients or For Someone New)

The Documaker Records

Printer Key (Record Types)

Sort Key

Mailing Key

Quote Information

Maintaining Quotes

The Lifecycle Of A Quote And Quote Detail

Quote Lifecycle

Quote Detail Lifecycle

Quote - Main

Action Buttons On Quote Main

Quote Actions

Quote Detail Actions

Proposal SA Actions

Quote - Quote Details

Quote - Quote Routings

Service Credits

The Big Picture Of Service Credit Membership

Who are the Members?

Joint Membership

Changing the Membership Accounts

Membership Application

Creation of a Membership

Membership Fees

Stopping a Membership vs. Inactivating a Membership

The Big Picture of SC Events

Event Amounts May Contribute to a Balance

Events May Indicate a Fiscal Year

Events May Indicate a Subcategory

An Event May Cause Other Actions to Occur

Financial Transactions for an Event

How Events Are Created

Events Created by an Algorithm

Events Created as a Result of a Background Process

Creating Pending Events

Events May Be Transferred

CPCRALOC - Allocating Capital Credits

CPCRRETR - Capital Credit Retirement

Maintaining Service Credit Memberships and Their Events

Service Credit Membership

Lifecycle of a Membership

Service Credit Membership - Main

Service Credit Membership - Account

Service Credit Membership - Characteristics

Service Credit Membership - Membership Tree

Maintaining Service Credit Events

Lifecycle of a Service Credit Event

Service Credit Event - Main

Appointments

The Big Picture of Appointments

An Appointment Is Made With A Dispatch Group

A Dispatch Group Has Appointment Periods

An Appointment Is Notional

Navigating To The Make / Break Appointment Page

Appointments Are Not Applicable To All Field Activities

Determining Available Appointments

Limiting The Number Of Appointments In An Appointment Period

Canceling An Appointment

Compensating A Customer For A Missed Appointment

Enabling Appointments

Plug In The Appropriate Algorithms On Each Dispatch Group

Set Up Appointment Periods

Appointment Maintenance

Appointments And External System Integration

Appointment Period Maintenance

How To

How To Copy Appointment Periods

How To Update Maximum Number Of Appointments

How To Delete Appointment Periods

How To Overwrite Appointment Periods

Loans

The Big Picture Of Loans

Loans Are Service Agreements

Loan Interest Charges

Loan Amortization Schedules

Negative Amortization

Loan Overpayments

The Lifecycle Of A Loan

Finalizing And Closing A Loan

Navigating To The Loan Maintenance Page

Loan Maintenance

How To

How To Start A Loan Service Agreement

How To Modify The Terms Of A Loan

How To Adjust Loans

How To Stop A Loan Service Agreement

Non-billed Budgets

The Big Picture Of Non-billed Budgets

Non-billed Budget Service Agreements

Which SAs Are Covered By A Non-billed Budget?

Non-billed Budgets Versus Other Plans For Payment

There Are Two Types Of Non-billed Budgets

Navigating To The Non-billed Budget Maintenance Page

Recommending Scheduled Payments

Maintaining Non-billed Budgets

Non-billed Budget - Main

Non-billed Budget - History

How To

How To Start A Non-billed Budget Service Agreement

How To Cancel / Stop Non-billed Budget SAs

How To Renew Non-billed Budgets

How To Set Up Automatic Payment For A Non-billed Budget

Asset Inventory

The Big Picture Of Asset Inventory

The Big Picture Of Stock Locations

Stock Location History Is Created Behind The Scenes

A User May Manually Change An Asset's Stock Location

Viewing What Is At A Stock Location

Viewing Where An Asset Is / Was

How To Handle A Shipment Of New Assets

How To Transfer Assets To Another Location

Setting Up Asset Inventory Options

Setting Up Postal Defaults

Turn On Stock Location Tracking On Your Meter Types / Item Types

Maintaining Stock Locations

Stock Location - Main

Stock Location - Characteristics

Maintaining Stock Location Inventory

Stock Location Inventory - Main

Stock Location Inventory - Item Inventory

Stock Location Inventory - Meter Inventory

Case Management

Background Topics

Case Type

Creating Cases

Log Information

Alerts

To Do's and Cases

Reports

Maintaining Cases

Case - Main

Case - Case Portal

Case - Log

Premise Management

Overview

Define Premise Hierarchy

Manage Premises for a Landlord

Manage Groups of Premises

Premise Management Page

Start Service

Stop Service

Assign Parent Premise

Remove Parent Premise

Assign Landlord

Remove Landlord

Umbrella Agreement Management

Overview Of Umbrella Agreement & Terms Of Service

Umbrella Agreement - Contacts

TOS Covered Entities

Rate Terms Overridden By Terms Of Service

Rate Schedule Override by TOS

Override Of Other Rate Terms By TOS

Umbrella Agreement Renewal

Umbrella Agreement Renewal Background Process

Umbrella Agreements & Proposals

Additional Umbrella Agreement Topics

Umbrella Agreement Alerts

Orders And Umbrella Agreements

Umbrella Agreement Reports

Umbrella Agreement Maintenance

Lifecycle Of An Umbrella Agreement

Umbrella Agreement - Main

Umbrella Agreement - Contacts

Umbrella Agreement - Characteristics

Terms Of Service Maintenance

Lifecycle Of Terms Of Service

Terms Of Service - Main

Terms Of Service - SAs

Job Streams

Job Stream Summary

Job Stream Details

Workflow and Notifications

The Lifecycle Of A Workflow Process And Its Events

What Is A Workflow Process?

A Workflow Process Contains Relevant Data

How Are Workflow Processes Created?

How Are Workflow Events Completed?

How Are Workflow Processes (and their Events) Canceled?

Workflow Process Maintenance

Workflow Process - Main

Workflow Process - Char/Context

Workflow Process - Events

Workflow Process - Event Char/Context

Workflow Event Exception

Uploading Notifications

Notification Upload Background Process

Process X - Populate Notification Upload Staging

Notification Upload Staging

Notification Upload Staging Context

Notification Upload Staging Characteristics

Notification Upload Staging Extension - Base Sample

Process WFPRINIT - Initiate Workflow Processes To Execute Notification Upload Staging Records

Validation of Data Related to the Notification Upload Staging Records

Notification Upload Staging Maintenance

Notification Upload Staging - Main

Notification Upload Staging - Characteristics/Context

Notification Upload Staging - Sample Upload Extension Record

Notification Upload Exception

Downloading Notifications

Notification Download Background Processes

Process NDSXTR - Interface Notification Download Records (out of the system)

Notification and XAI

NDS Contains Interesting Data

Notification Download Staging

Notification Download Staging - Main

Notification Download Staging - Characteristics/Context

Notification Download Staging - XAI Download Staging

Notification Download Exception

Overdue Financial Obligations

Overdue Processing Background Information

Overdue Process Maintenance

Overdue Process - Main

Overdue Process - Events

Overdue Process - Log

How To Perform Common Overdue Process Functions

How To Create An Overdue Process

How To Change Overdue Events

How To Cancel An Overdue Process

Cut Process Maintenance

Cut Process - Main

Cut Process - Events

How To Perform Common Cut Process Functions

How To Create A Cut Process

How To Change Cut Events

How To Cancel A Cut Process

Payment Arrangement for Bills

How To Set Up A Payment Arrangement

How To Add Additional Debt To A Payment Arrangement

How To Break A Payment Arrangement

How To Cancel A Payment Arrangement

Rebate Claims

Rebate Claim Query Portal

Rebate Claim Portal

Rebate Claim Zone

Rebate Claim Status

Rebate Claim Actions

Editing Rebate Claims

Verifying Rebate Claims

Approving Rebate Claims

Rejecting Rebate Claims

Noting Issues Related to a Rebate Claim

Canceling Rebate Claims

Adding Rebate Claims

Rebate Claim Line Zone

Adding Rebate Claim Lines

Deleting Rebate Claim Lines

Editing Rebate Claim Lines

Verifying Rebate Claim Lines

Rebate Claim Log Zone

Adding Rebate Claim Log Entries

New Rate Engine

Understanding New Style Rate Schedules

Overview

Rate Schedule Data Model: Old vs. New

Rate Schedules: Classic vs. New Style

Rates Schedule Execution: Old vs. New

Classic and New Style Rate Schedules for a Single Customer

New Style Rate Schedule Execution

Understanding Calculation Groups and Rules

About Calculation Groups and Rules

About Calculation Groups

About Calculation Rules

Designing Calculation Groups and Rules

Analyzing Your Rates and Identifying Calculation Rules and Groups

Re-Using Calculation Rules

Leveraging Eligibility Criteria to Dynamically Apply Calculation Rules

Case Study: Three Sample Rates

Working with Calculation Groups and Rules

Defining Calculation Groups

Searching and Maintaining Calculation Groups

Defining Calculation Line Category Types

Maintaining Calculation Line Category Types

Defining Calculation Rules

Searching and Maintaining Calculation Rules

Defining Calculation Rule Eligibility Criteria

Creating New Style Rate Schedules

Administration - Master Configuration

Defining New Style Rate Schedules

Searching and Maintaining Rate Schedules

Base Package Calculation Rule Descriptions

Common Parameters

Calculation Rule Validation

Calculation Rules

Apply To

Calculate Final Reading Values

Calculate Service Quantity

Flat Charge

Item Type

Math

Maximum Charge

Minimum Charge

Service Quantity

Simple Summary

Stepped Service Quantity

Summary

Rate Check - New Style

About Rate Check

Performing a Rate Check

Viewing Results of a Rate Check