Rate Attributes File
Note:
The rate attributes file cannot be loaded into the system until after the utility account has been created by your Delivery Team. Utilities should not send the file until the Delivery Team has received the utility account information in the customer/billing file as defined in Legacy Billing Data File Specifications. The common data element that must match across the datasets is theaccount_id. The
account_id is a common value for applying rate attributes to a particular
customer’s account.
| Field | Description |
|---|---|
| account_id |
Customer account identifier. The account entity should be established following the rules and requirements in Legacy Billing Data File Specifications. Type: VARCHAR Can Be Empty?: No. |
| key |
Key identifying the attribute. See Examples of Rate Attribute Keys below for common use cases, such as for rate plans, solar customers, and low-income customers. Type: VARCHAR Can Be Empty?: No. |
| value |
Value for the attribute. See Examples of Rate Attribute Keys below for common use cases. Type: VARCHAR Can Be Empty?: No. |
| start_date |
Effective start date of the specified attribute value. See Start and End Dates for more guidance. Type: DATE(YYYYMMDD) Can Be Empty?: No. |
| end_date |
Date on which the specified attribute value is no longer effective. This day is not part of the period covered by the rate attribute. This field may be left NULL if the value is effective indefinitely. Type: DATE(YYYYMMDD) Can Be Empty?: No. |
| is_utility_account_attribute_deletion |
Deletion flag for the rate attribute. Supported values include
Note: The rate attribute deletion feature is
disabled by default to ensure that rate attributes are not
erroneously deleted. If you want to allow deletions, make a request
to your Delivery Team. Note that deleting a rate attribute entry
results in the deletion of all future values for the
Type: STRING Can Be Empty?: Yes. |
Examples of Rate Attribute Keys
| Key | Sample Value | Description |
|---|---|---|
| rate_plan_code | Rate-1 | Rate plan identifier (for example, B-1, A-1). All customers should have at least one rate_plan_code key value pair. |
| critical_peak_option | CPP | Set to the code specifying the critical peak option selected (for example, ‘CPP’). |
| low_income_discount | FERA | Indicates that an account has a low income discount. |
| budget_billing | 1 | Use a value of 1 to indicate budget billing and 0 to indicate no budget billing. |
| SOLAR_TRUE_UP | 1 |
Use a value of 1 to indicate that a customer is using solar
technology and should therefore receive insights related to solar
power. Note that the attribute name ( The solar true up indicates the dates (usually annual) on which a customer's net energy metering billing has an anniversary. The anniversary may be when an annual true-up occurs and balances are paid off or reset. Oracle Utilities Opower expects a new row in the data file for each year that a customer has solar. This data can then be used to calculate monthly and yearly net energy metering billing balances, and to send time-based insights to the customer about their solar usage. See the
Note: Oracle Utilities Opower will exclude
any customer bill periods that fall outside of the true-up period's
start and end date. For example, any bills that are partially
within the true up period will be excluded. To be included, a start
date of a bill period must begin after the true-up period's
|
Rate Attributes Sample Data
| account_id | key | value | start_date | end_date | is_utility_account_attribute_ deletion |
|---|---|---|---|---|---|
| 123 | rate_plan_code | Rate-1 | 20080501 | false | |
| 123 | low_income_discount | FERA | 20080501 | false | |
| 123 | critical_peak_option | CPP | 20080501 | false | |
| 456 | rate_plan_code | Rate-1 | 20090701 | false | |
| 456 | critical_peak_option | CPP | 20090701 | false | |
| 789 | SOLAR_TRUE_UP | 1 | 20161011 | 20171011 | false |
| 789 | SOLAR_TRUE_UP | 1 | 20171011 | 20181011 | false |