Legacy Billing Data Entity Definitions

The Oracle Utilities Opower data model includes five key data entities. These five entities allow Oracle Utilities to provide the right usage information for the right fuel type to the right customer in the right location. Clearly understanding the relationships between these entities and representing them correctly in data files are crucial to meeting our shared implementation schedule, reaching your program goals, and delivering the desired experience for your customers. You are encouraged to ask questions about these entities early and often in the data integration process. The five key entities of the data module are:

1. Customer
2. Premise
3. Account
4. Service Point
5. Usage Value

This section describes these five distinct data entities, the business rules that apply to each of them, and the relationships between them. 

Data Entity Relationships

The following image illustrates the relationships between these entities. A single row in the data file always includes all five of these entity values.

Back to Top

Customer

A customer is an individual who receives service. The best customer_id to send is the one that uniquely identifies the customer and appears on the customer’s bill. By default, Oracle Utilities will display the customer_id or a portion of it on outbound communications and the web, but if a different ID should be displayed on these communications and the web, you can provide it to Oracle Utilities in the secondary_id column.

• Customer and Premise: Oracle Utilities offers analysis of a customer’s energy consumption at a specific location. For this reason, identifiers are needed for the customer (customer_id) and the service location (premise_id). Therefore, a “customer” is defined as a person at a premise rather than just an individual.
• Multiple Premises: Oracle Utilities does not aggregate usage across premises (premise_id). Customers that receive service at more than one premise are treated as separate potential report recipients and web users for each customer and premise combination. Customers with active accounts at more than two premises are ineligible for communications that include neighbor comparisons. It is assumed that these customers are property managers rather than residents.

Back to Top

Premise

A premise is a physical, unchanging location. Oracle Utilities requires a premise identifier (premise_id) that uniquely identifies the location of the service. Individual units of multi-family dwellings, such as apartments or condos, must have unique premise identifiers. Premise identifiers should not change when residents change. When a customer moves out of a premise and another moves in, the original premise identifier should continue to appear in the data file alongside the new individual customer (customer_id) who begins to receive service at that premise.

Back to Top

Service Point

A service point identifies an unchanging device location where service is delivered. The IDs of meters located at a premise may change over time as hardware is replaced. A service point ID must remain unchanged from the time of construction until the location no longer exists. Therefore, it is important that the service point ID be distinct from a meter number ID and not change if a meter is replaced.

Do Not Change the Service Point ID
A change in service point ID will result in a loss of usage history at that service point, and render the premise ineligible to receive reports or serve as another premise's neighbor.

Service Point and Account IDs: A service_point_id can only be associated with one account_id at any given point in time, but over the life of the service point it will likely be associated with different accounts at different times. Therefore, the active_date and inactive_date on the account records are important to associate usage with the correct customer. See Account Fields for more information.

Dual Fuel Insights: Oracle Utilities offers the ability to deliver insights on a customer’s total energy usage. A customer who has both gas and electric service should have one service point for each type of service. In order to aggregate the usage, both of the service points must be associated with the same customer and the same premise.

Service Point and Premise Solutions: Some dual fuel utilities do not maintain separate premise and service point identifiers. In this case, a common solution for creating the service_point_id is to concatenate the premise_id to the service type (G, E) or concatenated to a dash and a service number (“-1”, “-2”, “-3” …).

For example, given a premise_id of 123456, you may have a gas service point where the service_point_id is 123456-G and an electric service point where service_point_id is 123456-E. However, if you expect to have multiple service points of the same fuel type at a given premise, you may also need to add an additional, unchanging identifier for each of these service points, such as 123456-1-E, 123456-2-E, and so on. Discuss the options with your Delivery Team to determine what is appropriate for your use case.

Back to Top

Account

An account links a customer to a service point for a period of time. The account_id also associates a customer with usage values by way of the service point.

The most important attributes of the account are the active_date and inactive_date values, which indicate the period of time that service was provided to a customer at a given premise. A null inactive_date indicates a currently active account. Any non-null value in the inactive_date field discontinues the outbound Oracle Utilities Opower communications and/or web access for a customer whose account has been terminated.

• Rate Changes: If a customer switches to a new rate, the new rate code should be sent along with the existing account data with the same active_date, account_id, and all other required fields. Be sure to inform your Delivery Team of any new rates that should be eligible for reports. Oracle Utilities uses an allowlist for rate codes to exclude medical rates, for example, so if a customer switches to a new rate that has not been allowed, the customer will become ineligible for reports.
• Temporary Lapses in Service or Suspension: For a customer that has a temporary lapse in service or has their account suspended, the inactive_date should still be null. The inactive_date should only be set for a customer once they have received their final bill at that premise. You should continue to send usage reads for a customer that has a temporary lapse in service. The usage value for any reads during a temporary lapse should be zero.

• Attrition: Once an account is deactivated, it can only be reactivated if you send a row with a null inactive_date where the active_date and account_id matches the earlier reads. Prematurely sending inactive_date values can result in high rates of attrition from the program and lower-than-forecast energy savings.

Never modify the active_date!
When Oracle Utilities receives a service point record with a more recent active date than currently on file, the old account is automatically deactivated to hide prior usage history from the account and protect the customer’s privacy.
If you mistakenly send a newer active date, the customer will become ineligible for the program and lose access to usage data on the web application (if applicable) prior to the new date.

Back to Top

Usage Value

A usage_value is the amount of energy consumed at a specific service point over a period of time that has specific start and end dates. This period of time is called the billing period, which is defined in the Oracle Utilities Opower system by the date_to and duration fields. The date_to should be the last day of usage that has been billed during the billing period. The duration is expected to reflect the total number of days inclusive to the billing period so that the first day of the billing period can be derived from the following equation:

date_to - duration + 1

For example, if a customer's first day of energy use for a given billing period is October 1, 2013 and the last day of consumption is October 28, 2013, then the date_to field is 20131028 and the duration is 28.

To prevent creation of a gap or an overlap in usage, the date_to minus the duration should equal the previous date_to value. Using our previous example with the most recent date_to being 20131028 and the duration is 28, the previous date_to date should be 20130930.

• Usage Gaps and Overlaps: If a gap or an overlap in usage is detected, the customer associated with that service point is ineligible to receive Oracle Utilities Opower communications for up to two years. Any gaps in usage should indicate an actual gap in service and should be a rare occurrence.
• Usage Charge: Each usage value has an associated usage_charge. This charge should only represent billed costs that vary with usage. Flat fees and/or other customer charges, for example, should not be included in the usage charges, because customers cannot control these fixed costs by reducing their usage. Costs are displayed throughout the platform because it motivates customer to take action, but only costs that customers can control will be shown.
• Net Metering: If your system supports net metering, add the delivered usage to the received usage and put the summed result in the usage_value field. You should do the same for the usage_charge value. If you mistakenly send two separate rows (one for delivered usage and another for received usage) that cover the exact same calendar days, Oracle Utilities treats the second row as a correction to the first row. You can also exclude net metering customers through a rate_code if desired.

Back to Top