Attachment 3 – Software Customization Requirements
This attachment describes the Software Customizations or modifications required by the City.
Modification Number: M1
Area: Billing Management - Low Income Discount
Program Functional Requirement Item: #91, #352, #729, #817
Problem Description:
The City’s Low Income Discount program needs to be tracked and managed automatically specific to the rules that govern this program. The following rules need to be governed by the System to effectively manage the discount program:
• Only available to Water & Sewer residences, Water Only residences and Sewer Only residences.
• Available to Single-Family Residences only.
• The credit is a per diem charge for Water and another for Sewer. These flat credit amounts are given on a daily basis based on the number of days of service within the billing cycle. They are credited by fund, however they are summed on the Customer’s bill as one line item.
• Setting Up the LINC Discount:
› Must be able to start with a backdated or future dated effective date.
› Both Water fund and Sewer fund must give credit separately.
› Must show effective date (date credit will begin to calculate)
› Must show creation date (date LINC activated on account)
› Must show Expiration Date (or two year anniversary from effective date),
› Must show Review Date (two months prior to expiration date)
› Must show the user who set up the discount.
› The Expiration Date and Renewal Date should be automatically updated by SYSTEM once the user enters the Effective Date.
› The Creation Date & User ID should be an automatic time-stamp.
› The Review Date is to initiate automated process for sending expiration letter.
• LINC Termination Rules and system preferences:
› Rule 1: Low Income eligibility is for two years. The discount is terminated automatically when the two year anniversary is reached. However, a user can override the auto-termination so that the discount does not get terminated, or reverse the termination if necessary.
› Rule 2: Low Income Credits will be terminated if there is illegal usage on the account by turning a meter on after it has been disconnected for non-pay. The discount is terminated automatically via debt recovery rules. The debt recovery step after ‘disconnect for non-pay’ is called a meter lock. We lock the meter from being used further. It is at the completion of this step that we would want the discount to automatically terminate. However, a user can override the auto-termination so that the discount does not get terminated, or reverse the termination if necessary.
› Rule 3: If a customer moves outside our service area and closes their account then the discount is terminated automatically when the Move Out/Turn Off or Move In/Force Out service order is completed.
› Rule 4: In all cases the user must be able to manually terminate the discount, regardless if there is an auto-terminate condition in place.
› Rule 5: If a customer who is receiving the Low Income Discount moves within our service area, then we want the Discount to transfer with the customer keeping all original conditions. The only exception to this would be if they were moving from a Water Only service to a Sewer Only service (or vice-versa) then the discounts would need to be terminated at the old property & started at the new property for the appropriate funds.
Recommended Solution or Objective:
1. A form is to be created to manage the granting of a low-income discount to an account:
a. This form shall allow the selection of the account and the location / services that it is connected. Needs to be built so that only Single-Family residential properties can be connected to the discount. Basically eliminate the chance for user error setting up discount on a commercial property or multi-family property.
b. This form should also manage the date requirements:
› Must be able to start with a backdated or future dated effective date.
› Both Water fund and Sewer fund must give credit separately.
› Must show effective date (date credit will begin to calculate)
› Must show creation date (date LINC activated on account)
› Must show Expiration Date (or two year anniversary from effective date),
› Must show Review Date (two months prior to expiration date)
› Must show the user who set up the discount.
› The Expiration Date and Renewal Date should be automatically updated by SYSTEM once the user enters the Effective Date.
› The Creation Date & User ID should be an automatic time-stamp.
c. The discount should be awarded to individual services (i.e. water and sewer) through a manual selection. Needs to be built so that user cannot set discount for Water Service when the property/account is a Sewer Only service, etc. Basically eliminate the chance for user error setting up an erroneous discount.
d. The special rates (bill codes implementing the discount) are to be manually selected for each service that is given the discount. Needs to be built so that user cannot set discount for Water Service when the property/account is a Sewer Only service, etc. Basically eliminate the chance for user error setting up an erroneous discount.
e. The new form shall automatically manage the de-activation of an account’s existing, non-discount rates and the activation of the new, discounted rates.
f. The form shall provide a function to terminate the account’s discount program, which will de-activate the discounted rates and re-instate the account’s original rates. This function will be driven either by a user manually initiating the termination or automatically when the two (2) year anniversary is reached, or illegal usage is captured. However, a user can override the auto-termination so that the discount does not get terminated, or reverse the termination if necessary.
g. The form shall provide a review function that selects all accounts where their discount program is about to expire within “x” months and initiate automated process for sending expiration letter.
2. The move-in and move-out processes are to be modified so that the discount program can “travel” with the customer when they move from one location to another within the Utility’s service area providing they are moving to like services. The system needs to not allow the discount to moving from Water Only service to a Sewer Only service (or vice-versa). In these situations the discount would need to be terminated at the old property & started at the new property for the appropriate funds.
3. If a customer moves outside our service area and closes their account then the discount is terminated automatically when the Move Out/Turn Off or Move In/Force Out service order is completed.
4. Meter read upload / approval and Service Order resolution shall be modified so that a “meter tampered” status can initiate the termination of an account’s discount program. However, a user can override the auto-termination so that the discount does not get terminated, or reverse the termination if necessary.
5. No modification required for the implementation of the discount rate itself. Bill code functionality is able to meet the requirements where the discount is to be allocated separately to water and sewer funds. Discount cap functionality in CU also guarantees that a discount will not exceed the billed charges.
Modification Number: M2
Area: Billing Management – Multi-Period Bills (Rebills, Final Bills, Retro-activated services, etc.)
Program Functional Requirement Item: #303, #314, #316, #360-371, #373, #374
Client Business Requirements
The issue of multi-period bills arises from a few areas of billing management, specifically Final Bill Scenarios, Cancel/Rebills and Winter Average Billing.
Pertaining to the Final Bill scenarios, where bills are issued for accounts that are put through a back dated move-in, Portland requires that the re-bill is broken down into sub-periods for the measured services based on the on-cycle meter reads that have been captured on the re-bill. (Current practice in Cayenta Utilities is to create a meter read based on prorated consumption, this system generated meter read does not necessarily correspond to the actual meter read).
Per Winter Average billing, where an account is put through a back dated move-in on the sewer service, Portland requires that the next account billing be broken down into sub-periods on the sewer billing for each water read billed since the sewer connection. Cayenta Utilities is able to bill for an entire service period of “connection date to current period ending date” but this is not broken down into sub-periods.
Per Cancel/Rebills, if the rebill is for more than one service period, then Portland requires that the re-bill is broken down into sub-periods for the measured services based on the on-cycle meter reads that have been captured on the re-bill.
In all cases, the sub-period plays an important role in accurately billing tiered rates for measured water, and how sewer is to be billed based on winter averages. Depending on the time of year, a sewer sub-period is either billed for actual consumption or for a winter average.
Recommended Solution or Objective:
1. Sub-period billing functionality shall be modified to be based on on-cycle meter reads (whether actual, estimated or prorated) instead of on the system generated estimated (prorated) read (generated automatically by the system) to process the back bill. Functionality currently exists that allows this to occur in a deregulation environment; this modification will extend the functionality to operate in a non-deregulated environment.
2. The Billing process shall be modified so that a backdated service connection will generate sub-periods bills for that service when the account is next billed (e.g. next cycle billing).
Modification Number: M3
Area: Budget Billing
Program Functional Requirement Item: #488-504
Problem Description:
The City offers Budget Billing to their residential customers. Customers on bi-monthly or quarterly billing are paying for their budget billing on a monthly basis, even though their meter is being read bi-monthly or quarterly. The City requires the following:
1. Cayenta Software will generate a monthly “coupon” for the budget bill installment on the months that are off-cycle (where meters are not read for these months). All bi-monthly or quarterly, residential customers that have a budget pay plan will receive a monthly coupon for the off-cycle months.
2. The City also needs to start Budget Billing on “pending” accounts, not just limited to “active” accounts only.
3. Customers that fail to pay a monthly budget bill “coupon” (or quarterly budget bill) shall have their budget pay plan terminated. The termination of a budget pay plan is a configuration setting but the implication here is that all customers are subject to the same rules regardless of when their budget pay plan starts.
Recommended Solution or Objective:
1. Modify the Billing process to allow a new mode of operation (currently has six modes) that will produce budget bills for accounts on budget billing where the account is not required to have a meter read.
2. This allows for bi-monthly or quarterly budget bill accounts to be billed on a monthly basis. The one or two intervening months will not have meter reads but the account will be invoiced for a budget bill “coupon” (the invoice will have the appropriate collection stream or debt recovery path associated to it).
3. The accounts being billed in this mode will require a monthly Cycle schedule so that the Billing process can take it’s cue from the account’s extracted for billing on a monthly basis.
Modification Number: M4
Area: Sewer Billing – Winter Average Billing
Program Functional Requirement Item: #278, #285, #338, #341, #403, #411, #417-425, #431, #438, #650, #660, #661, #667-673.
Problem Description:
The City’s residential sewer charges are calculated two different ways depending on the season. During the winter season, the charges are calculated based on actual water consumed. During the other seasons (non winter seasons), the consumption amount used for sewer charges is the lowest value of either the service provision’s previous winter’s average consumption or the current usage.
Calculating the Winter Average – A winter average is calculated for each appropriate sewer service provision. If the reading for the winter period covers less than 25 days of service, a winter average cannot be established. In this case class average will be used. See class average description below. It is calculated differently depending on whether the service provision bills quarterly, bi-monthly or monthly and whether the account is residential or multi-family.
Winter Average = (total winter consumption / days in winter) * days of service multiplier
The average is rounded to the nearest integer. The calculations for winter average should be complete once the final billable read that occurs within the review period is obtained.
Quarterly Bills – The Billable Reads that take place from 2/1 – 4/30 are considered to represent the Winter Days of Service. This read (there is usually 1) is used to establish the winter average. The daily winter average is multiplied by a days of service multiplier of 90 to obtain the average consumption of a quarterly bill.
Bi-monthly Bills – The Billable Reads from 1/1 – 4/30 are considered to represent the Winter Days of Service. They are used to calculate the winter average (there are usually 2). The daily winter average is multiplied by a days of service multiplier of 60 to obtain the average consumption of a bi-monthly bill.
Monthly Bills – The Billable Reads from 12/1 – 4/30 are considered to represent the Winter Days of Service (there are usually 5). They are used to calculate the winter average. The daily winter average is multiplied by a days of service multiplier of 30 to obtain the average consumption of a monthly bill.
During the Winter Months we bill the Sewer Volume based on actual usage x rate. But after the Winter Months have passed, the City then bill [the lesser of winter average consumption or actual consumption].
Recommended Solution or Objective:
1. The Seasonal Average Calculation process shall be changed so that if the process is performed multiple times, the subsequent winter averages will update the existing averages (as calculated by the initial process). Cayenta’s current process will not overwrite existing seasonal averages. This change will allow the averages to be updated, as more meter reads become available within the evaluation period.
2. The bill code rate component that gets winter average consumption shall be modified such that:
a. If a winter average does not exist for the current year, the previous year’s winter average will be selected
b. If an average is selected that is not from the current year then a warning message is placed in the Billing Process Log.
3. Manually adjusted winter averages shall be logged for audit purposes.
4. Bill Inquiry shall be modified to indicate which value was used for sewer billing, winter average consumption or actual consumption.
5. Where Consumption Rate proration occurs and consumption is to be prorated across the rate change, the Billing process shall be corrected so that the total of prorated consumption is equal to the original non-prorated usage.
6. Pre-billing report for accounts missing winter averages.
Modification Number: M5
Area: Service Order Completion
Program Functional Requirement Item: #153
Problem Description:
Anytime a move in/move out is scheduled within "x" period of time to coincide with the meter reading window, the on cycle read will be used to prorate for the final bill read &/or service start read, as well as complete the service order. During the mini gap analysis August 2003, Cayenta verified that the System would prorate for the final & start read(s) using the on-cycle meter reads, and this functionality is in the base product and is not a modification. However, the service order is still sent to the field. The City needs the ability to prevent the field visit in these situations.
Recommended Solution or Objective:
Cayenta proposed in the mini gap session, developing a user-window that would request whether to send the service order to the field for a read or hold it to prorate using the on-cycle meter read.
Modification Number: M6
Area: Service Order Completion
Program Functional Requirement Item: #647, #648
Problem Description:
Move In Service Orders must be created in sequential order according to the start date/force out date of each customer. The System must only allow these Service Orders to be completed in order of creation.
Recommended Solution or Objective:
The objective is so that the System will always prorate the final bill &/or start reads accurately, as well as close & start a customer’s account correctly – carry over correct billing attributes from one customer to another, etc. The City has a city ordinance that currently requires that we have “continuous billing” at a property. In other words, a property must always have a responsible party actively billing. The City does not allow for vacant periods at a property pertaining to billing responsibility. When one Customer closes their account, that same day another is responsible for the service(s) provided. Because of this ordinance, the System must support interim billing where a renter moves out, a landlord is responsible for “x” days, and another renter takes over. All service requests (service orders created) are taken in one phone call from the Landlord.