Additional Business Rules for Legacy Billing Data
Usage Value Corrections
Oracle Utilities supports corrections when a usage value or charge needs to be updated after a customer has been billed. Two kinds of usage value corrections are accepted: exact overwrites and overlapping overwrites.
Usage Value Assumptions
The examples in this section assume a month-long read cycle that begins on the first day of each month.
Exact Overwrites: You can send a new row that has the same service_point_id, date_to, and duration along with the corrected usage value and/or charge. The original usage value and charge will be replaced with the new ones. In the example below, exact overwrite correction B replaces the original usage value of billing period 2.
Overlapping Overwrites: You can send a new row that completely covers the original usage read. In this case, the date_to will be more recent and the duration will be longer than latest date_to on record for that service_point_id. The new date_to must make the corrected read the most recent read received for the service point, and the derived start date of the new usage period must match the start date of an old usage period. When an overlapping overwrite correction is loaded, the Oracle Utilities Opower application removes any old intermediate reads that fall within the duration of the new read. The usage value and usage charge of the new read must reflect all usage and all usage-based charges for the new, longer usage period. In the example below, overlapping overwrite correction E replaces the original usage values of billing period 5 though today.
Incorrect Overwrites: Below are several examples of incorrect corrections. Note how they violate the rules above by starting or ending in the middle of a usage read periods.
Multiple Service Points for a Single Fuel Type
Oracle Utilities will only generate usage comparisons for premises with a single service point for a given fuel type.
Making this subset of customers ineligible ensures that we do not attempt to compare residential usage to usage for non-residential service points such as garages, barns, and pools. Discuss options for customers with multiple active service points with your Delivery Team.
Landlords
When a site moves between a tenant and a landlord, it is treated as a standard move-out, move-in scenario. For example, if a tenant moves out, their account should have inactive_date set to the date they move out, and the landlord should have active_date set to the following day. The tenant and landlord should have their own unique customer_id and account_id. When a tenant moves back in to the site, the landlord should have an inactive_date set for their account associated with that site, and the customer should have an active_date set for the following day. This prevents usage data from being exposed when the site transfers ownership.
Customer Transfers to a New Site
When a customer moves to a new site but continues service at their new location, it is treated as though their old account closed, and they opened a new account. Their old account should have inactive_date set, and they should receive a new active_date, account_id, and premise_id at their new location. Their customer_id can remain the same. This is due to Oracle Utilities considering an account as the combination of a customer at a premise.