Guidelines for Common Data Elements

Certain data elements are commonly used across the rate data files, such as account and rate plan identifiers, start dates, and end dates.

Account and Rate Plan Identifiers

Rate attributes files cannot be loaded until after a utility account has been created by your Delivery Team. Therefore, you should not send rate attributes files until Oracle Utilities has received your utility account information in the customer and billing data files as defined in Legacy Billing Data File Specifications. However, there are two common data element that must match across the data sets:

Rate Plan Identifiers (rate_plan_identifier): Customer information needs to include a unique identifier which can be mapped to a specific rate structure and price. This identifier must match across all of the rate data files in which it is required.
Account Identifiers (account_id): Unique account identifiers are used as the common value for applying rate attributes to a particular customer’s account.

Start and End Dates

Many of the rates data files require effective start and end dates. For each data feed, you must order data by the effective start date. If the data is not ordered, errors may occur or the data may not be loaded as expected. A few of these scenarios are outlined below:

If there is an existing record and another record with the same primary keys (for the same customer or rate / rate component combination) and an earlier start date is received, the data cannot be loaded. This causes an overlapping period that will generate an error.
If there is an existing record and the start date for a new record is during the same period of the first record and has a null end date, this will generate an error.
If there is a rate period with an effective start and end date and there is another record with a start date during that period and a null end date, an error will occur.
If there is an existing record and another record with the same start date is received, the new record will overwrite the existing record. Corrections can only be made if the period is exactly the same.
If there is an existing record with a null end date and another record with a later start date is received, the existing record will be end dated with the later start date and a new record will be inserted with the new start date.

When you are defining the period for an event or attribute using a start_date/end_date or effective_start_date/effective_end_date, keep in mind that the period includes the start date but not the end date. To avoid a gap between periods, the start date of the next period should be the same as the end date of the previous period.