Learn how seasons and season groups model parts of the year that can use different rate amounts.
Many utilities (LSEs) charge different tariff rates depending on the time of year. A utility might charge 8.5¢ during summer, and 7¢ in winter, for instance. Utilities have their own definition of when these times of year start and end. For example, one utility might define "Summer" as starting on 4/1 and "Winter" on 9/15, whereas another says "Summer" starts on 6/15 but also defines different rates for "Spring" and "Fall" too. Arcadia has a data-driven way of defining these periods, called Seasons (as they usually, but not always, have names resembling seasons of the year). A Season belongs to a utility (LSE), and one or more Seasons are organized into a Season Group, where together they span a full calendar year.
Seasons can start on a fixed date, which is defined by the combination of the seasonStartMonth and seasonStartDay properties. Similarly the seasonEndMonth and seasonEndDay properties define the end date. However, in some cases, the start date or the end date of the Season is not fixed but is dynamically overridden by either the start date or end date of the billing period that it occurs in. This behavior is recorded by the Season's optional fromEdgePredominance and toEdgePredominance properties. When populated they can be set to PREDOMINANT, which tells you that this date should move to the start of the bill or SUBSERVIENT, which means it moves to the end of the bill.
As an example, consider a utility customer who gets their March 5th to April 4th bill. This utility defines their "summer" Season as starting at the beginning of the bill that includes March 15th. And to be consistent their "winter" season also ends at the start of the bill that includes March 15th. The customer would pay "summer" rates for the entire billing period, and no "winter" rates, because the "summer" start date and "winter" end date would both be dynamically overridden to March 5th.
Related endpoints
Data Definitions
Season
The Season object has the following data structure.
| Name | Type | Fields | Description |
|---|---|---|---|
| seasonId | Long | Unique Arcadia ID (primary key) for each season | |
| lseId | Long | The ID of the LSE this season belongs to | |
| seasonGroupId | Long | The ID of the season group that contains this season | |
| seasonName | String | The name of the season (i.e. "Summer" or "Winter") | |
| seasonFromMonth | Integer | Value of 1-12 representing the month this season begins | |
| seasonFromDay | Integer | Value of 1-31 (depending on month) representing the day this season begins | |
| toEdgePredominance | String | E | Can be null (to date is a fixed date), PREDOMINANT (to date is the start of the bill the season ends in), or SUBSERVIENT (to date is the end of the bill the season ends in). |
| seasonToMonth | Integer | Value of 1-12 representing the month this season ends | |
| seasonToDay | Integer | Value of 1-31 (depending on month) representing the day this season ends | |
| fromEdgePredominance | String | E | Can be null (from date is a fixed date), PREDOMINANT (from date is the start of the bill the season begins in), or SUBSERVIENT (from date is the end of the bill the season begins in). |
Season Group
The SeasonGroup object has the following data structure.
| Name | Type | Description |
|---|---|---|
| seasonGroupId | Long | Unique Arcadia ID (primary key) for each season group |
This returns a list of season groups for a given LSE. The result set is a list of season group objects in the standard response format.
Resource URI
GET /rest/public/seasons
Request Parameters
Along with the standard pagination parameters, searching and sorting parameters, and the required security parameters, the following parameters are available as part of the request:
| Name | Type | Description |
|---|---|---|
| lseId | Long | The LSE ID whose seasons you want. (Required) |