Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved structure for Solar Time Varying Tariffs #624

Closed
DannyDuong opened this issue Dec 7, 2023 · 15 comments
Closed

Improved structure for Solar Time Varying Tariffs #624

DannyDuong opened this issue Dec 7, 2023 · 15 comments
Labels
Breaking change A change expected to result in a new endpoint version. Energy Proposal made The DSB has proposed a specific change to the standards to address the change request

Comments

@DannyDuong
Copy link

DannyDuong commented Dec 7, 2023

Description

Time Varying Tariffs for Solar Feed-In Tariffs are relatively new and were introduced as part of EnergyPlanResponseV2.
In Victoria, one offer/plan, can have up to 4 solarFeedInTariff objects, to cater for different solar policies:
• Premium FiT
• Current FiT
• Variable FiT – option 1
• Variable FiT – option 2

It’s important for the data standards to facilitate all the items relating to a given Solar FiT policy in the same object.

For reference, in Victoria, the approved Feed-in Tariff structures and rates for 2023–24 are below:

image

Source: Essential Services Commission website, https://www.esc.vic.gov.au/electricity-and-gas/prices-tariffs-and-benchmarks/minimum-feed-tariff/minimum-feed-tariff-review-2023-24, accessed 16 May 2023.

Area Affected

The EnergyPlanResponseV2 response payload for the Get Generic Plan Detail API.

The following are key requirements regarding standards for the Solar Tariff:

  1. Each solarFeedInTariff to be a full tariff, i.e. it covers 24hrs by 7 days for Solar FiT with multiple rates with different time periods.
  2. In addition, all the items relating to this tariff should be kept in the same object – e.g. Overnight, Day and Early evening are different tariffs (timeVaryingTariffs) for the same variable Solar FiT object.

It is important, that the data standards can support an offer having multiple Solar FiT policies, and each Solar FiT policies may have multiple rates with different time periods.
The current standard does not support this, and hence the need for this CR.

The work-around using the current standards may be possible, but it would lead to:
• be a very confusing and incorrect way to represent timeVaryingTariffs, as they are not nested at the right level
• could have a flow-on effect on anyone consuming the CDR offer data
• result in duplication of implementation costs to develop with this work-around and then to correct it later

Change Proposed

DEECA propose a CR to change the timeVaryingTariffs from an object to be an array of objects to cater for the three set of timebands and rates.
This change will facilitate the data standards to support an offer having multiple Solar FiT policies, and each Solar FiT policies may have multiple rates with different time periods.

In addition, a timeVaryingTariffs.displayName field is required to describe each object in the timeVaryingTariffs array.
Note: This is separate from the timeVaryingTariffs.type field which is a generic Peak, Off-Peak and Shoulder

Refer to the following sample payload
solarFeedInTariff_example_nested.jsonc

DSB Proposed Solution

The proposed solution can be found through the staging link provided in #624 (comment)

@DannyDuong DannyDuong changed the title Improved structure for Time Varying Tariffs Improved structure for Solar Time Varying Tariffs Dec 7, 2023
@mattyp
Copy link

mattyp commented Jan 29, 2024

+1

I see an original proposal for the timeVaryingTariffs has it as an array, so I am guessing it was accidently converted to a single object somewhere along the implementation journey.

Also doesn't make sense to have a plural name for only a single value 😛

@mattyp
Copy link

mattyp commented Jan 29, 2024

PS - duplicate of #456 (comment)

@HemangCDR
Copy link

After the discussion in today's MI call (February 2), I've pulled out the example from the file linked in the original CR comment and labeled it as option 1, making some minor adjustments for clarity. @DannyDuong, please correct are inaccuracies or mistakes I may have made.

I've also noted an alternative option 2 for consideration. Feedback on both these options along with any alternative suggestions are welcome.

Option 1 - Original proposal in CR

Summary:

  • Make timeVaryingTariffs into an array. This is to allow representing multiple tariffs associated with a single FiT option
  • Add new mandatory field displayName to timeVaryingTariffs. This will allow specifying the type of tariff (e.g. overnight, day).
  • An alternative to adding a new displayName field could be to add new values to the existing type ENUM as below:
      "type" : ["PEAK", "OFF_PEAK", "SHOULDER", "OVERNIGHT", "DAY", "EARLY_EVENING"]
  • This would be considered a breaking change. A Future Dated Obligation (FDO) would need to be discussed as part of this CR
  • Example structure below:
"solarFeedInTariff" : [
    {
        "displayName": "Time-Varying - Option 1",
        "description": "Victorian time-varying FIT",
        "scheme": "Variable FiT",
        "payerType": "GOVERNMENT",
        "tariffUType": "timeVaryingTariffs",
        "timeVaryingTariffs": [ // converted into an array
			{
				"type": "OFF_PEAK",
				"displayName": "Overnight", // new mandatory field
				"rates": [
					{
						"unitPrice": "0.113",
						"measureUnit": "KWH"
					}
				],
				"timeVariations": [
					{
						"days": [
							"MON","TUE","WED","THU","FRI","SAT","SUN"
						],
						"startTime": "22:00",
						"endTime": "07:00"
					}
				]
			},
			{
				"type": "PEAK", 
				"displayName": "Day", // new mandatory field
				"rates": [
					{
						"unitPrice": "0.044",
						"measureUnit": "KWH"
					}
				],
				"timeVariations": [
					{
						"days": [
							"MON","TUE","WED","THU","FRI"
						],
						"startTime": "07:00",
						"endTime": "15:00"
					},
					{
						"days": [
							"MON","TUE","WED","THU","FRI"
						],
						"startTime": "21:00",
						"endTime": "22:00"
					},
					{
						"days": [
							"SAT",
							"SUN"
						],
						"startTime": "07:00",
						"endTime": "22:00"
					}
				]
			},
			{
				"type": "SHOULDER", 
				"displayName": "Early evening", // new mandatory field
				"rates": [
					{
						"unitPrice": "0.093",
						"measureUnit": "KWH"
					}
				],
				"timeVariations": [
					{
						"days": [
							"MON","TUE","WED","THU","FRI"
						],
						"startTime": "15:00",
						"endTime": "21:00"
					}
				]
			}
		]
    }
]

Option 2 - Leverage existing standards to represent FiT

Summary:

  • Use existing solarFeedInTariff array to represent the different FiT options
  • The displayName field can be used to describe the varions options
  • As noted in the main comment, this could result in interpretation issues
  • This would not be a breaking change as there are no changes to the standards
  • Example structure below:
"solarFeedInTariff" : 
[
	{
		"displayName": "Time-Varying - Option 1 - Day", // FiT rate options described here
		"description": "Victorian time-varying FIT",
		"scheme": "Variable FiT",
		"payerType": "GOVERNMENT",
		"tariffUType": "timeVaryingTariffs",
                "timeVaryingTariffs": 
			{
				"type": "OFF_PEAK",
				"rates": [
					{
						"unitPrice": "0.113",
						"measureUnit": "KWH"
					}
				],
				"timeVariations": [
					{
						"days": [
							"MON","TUE","WED","THU","FRI","SAT","SUN"
						],
						"startTime": "22:00",
						"endTime": "07:00"
					}
				]
			},
	},
	{
		"displayName": "Time-Varying - Option 1 - Overnight",   // FiT rate options described here
		"description": "Victorian time-varying FIT",
		"scheme": "Variable FiT",
		"payerType": "GOVERNMENT",
		"tariffUType": "timeVaryingTariffs",
               "timeVaryingTariffs": 
			{
				"type": "PEAK", 
				"rates": [
					{
						"unitPrice": "0.044",
						"measureUnit": "KWH"
					}
				],
				"timeVariations": [
					{
						"days": [
							"MON","TUE","WED","THU","FRI"
						],
						"startTime": "07:00",
						"endTime": "15:00"
					},
					{
						"days": [
							"MON","TUE","WED","THU","FRI"
						],
						"startTime": "21:00",
						"endTime": "22:00"
					},
					{
						"days": [
							"SAT",
							"SUN"
						],
						"startTime": "07:00",
						"endTime": "22:00"
					}
				]
			},
		},
		{
			"displayName": "Time-Varying - Option 1 - Early evening",   // FiT rate options described here
			"description": "Victorian time-varying FIT",
			"scheme": "Variable FiT",
			"payerType": "GOVERNMENT",
			"tariffUType": "timeVaryingTariffs",
			"timeVaryingTariffs": 
				{
					"type": "SHOULDER", 
					"rates": [
						{
							"unitPrice": "0.093",
							"measureUnit": "KWH"
						}
					],
					"timeVariations": [
						{
							"days": [
								"MON","TUE","WED","THU","FRI"
							],
							"startTime": "15:00",
							"endTime": "21:00"
						}
					]
				},
			}
  ]

@mattyp
Copy link

mattyp commented Feb 21, 2024

Option 1 ✅. It’s a shame a bug fix is a breaking change, but best to just fix it up, get it right and move onto the next bug.

@Jacqui-AER
Copy link

The AER support option 1.

@DannyDuong
Copy link
Author

DEECA proposed and hence support option 1

@DannyDuong
Copy link
Author

DannyDuong commented Feb 27, 2024

@HemangCDR I've included a revised file and have pasted the content below - which should replace the Option 1 that you have posted above.

It is largely the same as the initial file that I've shared, but for completeness, I've included the "period" and "volume" fields to ensure that it supports the step tariff linked to this ticket here #625

"solarFeedInTariff" : [
    {
        "displayName": "Time-Varying - Option 1",
        "description": "Victorian time-varying FIT",
        "scheme": "Variable FiT",
        "payerType": "GOVERNMENT",
        "tariffUType": "timeVaryingTariffs",
        "period": "string",
        "timeVaryingTariffs": [
		{
            "type": "PEAK", 
            "displayName": "Overnight",
            "rates": [
                {
                    "unitPrice": "0.113",
                    "measureUnit": "KWH",
                    "volume": 0
                }
            ],
            "timeVariations": [
                {
                    "days": ["MON","TUE","WED","THU","FRI","SAT","SUN"],
                    "startTime": "22:00", 
                    "endTime": "07:00" 
                }
            ]
        },
		{
            "type": "OFFPEAK", 
            "displayName": "Day",
            "rates": [
                {
                    "unitPrice": "0.044",
                    "measureUnit": "KWH",
                    "volume": 0
                }
            ],
            "timeVariations": [
                {
                    "days": ["MON","TUE","WED","THU","FRI"],
                    "startTime": "07:00", 
                    "endTime": "15:00"
                },
                {
                    "days": ["MON","TUE","WED","THU","FRI"],
                    "startTime": "21:00",
                    "endTime": "22:00" 
                },
                {
                    "days": ["SAT","SUN"],
                    "startTime": "07:00", 
                    "endTime": "22:00" 
                }
            ]
        },
		{
            "type": "SHOULDER", 
	    "displayName": "Early Evenning",
            "rates": [
                {
                    "unitPrice": "0.093",
                    "measureUnit": "KWH",
                    "volume": 0
                }
            ],
            "timeVariations": [
                {
                    "days": ["MON","TUE","WED","THU","FRI"],
                    "startTime": "15:00", 
                    "endTime": "21:00"
                }
            ]
        }
	]
    }
]

solarFeedInTariff_example - DEECA Feb 2024.jsonc

@CDR-API-Stream CDR-API-Stream moved this from Iteration Candidates to In Progress: Design in Data Standards Maintenance Mar 12, 2024
@ElizabethArnold-DSB ElizabethArnold-DSB added the Breaking change A change expected to result in a new endpoint version. label Mar 19, 2024
@AGL-CDR
Copy link

AGL-CDR commented Mar 20, 2024

Should this item be accepted, we will need at least six months lead time, starting from the date that final standards are published. With that in mind, we propose a FDO of early December.

@HemangCDR
Copy link

HemangCDR commented Mar 26, 2024

Noting the feedback recieved thus far, and as per the action noted during the MI call on March 20, below is the proposed solution (i.e. option 1 in this comment) for this CR:

It consists of the following changes:

  1. Convert solarFeedInTariff.timeVaringTariffs into an array to allow representation of multiple feed in tariff for a given plan
    2. Incorporate the new tariff types noted in the essential services review by extending the solarFeedInTariff.timeVaryingTariffs.type ENUM.
  2. Add new displayName field as per original proposal. This is based on feedback received during MI call on 3rd April noting that it aligns with other time of use structures and gives DHs the flexibility as the use custom names.
  3. Add new ENUM values VARIABLE and CURRENT to solarFeedInTariff.scheme. Refer to this comment for clarification.
  4. The FDO date of 11/11/2024 is recommended, which is the last obligation date noted in the obligation date schedule. This is in alignment with the FDO of other energy CRs being discussed in this MI.

The changes would appear as below:

"solarFeedInTariff": [
  {
    "displayName": "string",
    "description": "string",
    "startDate": "string",
    "endDate": "string",
    "scheme": ["PREMIUM", "VARIABLE", "CURRENT", "OTHER"] // new VARIABLE and CURRENT ENUM values
    "payerType": "GOVERNMENT",
    "tariffUType": "singleTariff",
    "singleTariff": {
      "rates": [
        {
          "unitPrice": "string",
          "measureUnit": "KWH",
          "volume": 0
        }
      ]
    },
    "timeVaryingTariffs": [ //converted into array of objects
        {
          "type": ["PEAK", "OFF_PEAK", "SHOULDER"],
          "displayName" : "string", // new mandatory field
          "rates": [
            {
              "unitPrice": "string",
              "measureUnit": "KWH",
              "volume": 0
            }
          ],
          "timeVariations": [
            {
              "days": [
                "SUN"
              ],
              "startTime": "string",
              "endTime": "string"
            }
          ]
        }
    ]
  }
]

Feedback on the above is welcome.

@HemangCDR HemangCDR added the Proposal made The DSB has proposed a specific change to the standards to address the change request label Mar 26, 2024
@biza-io
Copy link

biza-io commented Apr 3, 2024

Biza.io supports the proposal most recently posted proposal by @HemangCDR as we believe it is in the best interests of the ecosystem.

@CDR-API-Stream
Copy link
Collaborator

Note the proposed solution has been updated based on feedback received on the MI call held on 3rd April.

Specifically:

  • Removed extra ENUM values
  • Added displayName field as noted in original CR proposal

If no further feedback is received, it will be recommended to the Chair for review and approval.

@CDR-API-Stream
Copy link
Collaborator

The change has been staged and can be reviewed here: ConsumerDataStandardsAustralia/standards-staging@release/1.30.0...maintenance/624

Note: The retirement date for the following endpoints impacted as a result of this change has been set to September 8th 2025

  • Get Generic Plan Detail v2
  • Get Energy Account Detail v3

@CDR-API-Stream CDR-API-Stream moved this from In Progress: Design to In Progress: Staging in Data Standards Maintenance Apr 10, 2024
@nils-work nils-work moved this from In Progress: Staging to Awaiting Chair Approval in Data Standards Maintenance Apr 16, 2024
@DannyDuong
Copy link
Author

DannyDuong commented Apr 17, 2024

Noting the feedback recieved thus far, and as per the action noted during the MI call on March 20, below is the proposed solution (i.e. option 1 in this comment) for this CR:

It consists of the following changes:

  1. Convert solarFeedInTariff.timeVaringTariffs into an array to allow representation of multiple feed in tariff for a given plan
    2. Incorporate the new tariff types noted in the essential services review by extending the solarFeedInTariff.timeVaryingTariffs.type ENUM.
  2. Add new displayName field as per original proposal. This is based on feedback received during MI call on 3rd April noting that it aligns with other time of use structures and gives DHs the flexibility as the use custom names.
  3. The FDO date of 11/11/2024 is recommended, which is the last obligation date noted in the obligation date schedule. This is in alignment with the FDO of other energy CRs being discussed in this MI.

The changes would appear as below:

"solarFeedInTariff": [
  {
    "displayName": "string",
    "description": "string",
    "startDate": "string",
    "endDate": "string",
    "scheme": "PREMIUM",
    "payerType": "GOVERNMENT",
    "tariffUType": "singleTariff",
    "singleTariff": {
      "rates": [
        {
          "unitPrice": "string",
          "measureUnit": "KWH",
          "volume": 0
        }
      ]
    },
    "timeVaryingTariffs": [ //converted into array of objects
        {
          "type": ["PEAK", "OFF_PEAK", "SHOULDER"],
          "displayName" : "string", // new mandatory field
          "rates": [
            {
              "unitPrice": "string",
              "measureUnit": "KWH",
              "volume": 0
            }
          ],
          "timeVariations": [
            {
              "days": [
                "SUN"
              ],
              "startTime": "string",
              "endTime": "string"
            }
          ]
        }
    ]
  }
]

Feedback on the above is welcome.

@HemangCDR The following are DEECA feedback on this.

  1. "scheme": ["PREMIUM", "OTHER", "CURRENT", "VARIABLE"], // Adding CURRENT and VARIABLE for clarity, otherwise they will be treated as OTHER
  2. "period": "string", // the period field should be added here for completeness, at the same level as tariffUType. This is link to Additional field to support Step Tariff calculations #625
  3. I'm assuming that the standards nesting structure support the example "Time-Varying - Option 1" that was provided above

@CDR-API-Stream
Copy link
Collaborator

CDR-API-Stream commented Apr 17, 2024

@DannyDuong thank you for your comment. Please note the following response:

  1. "scheme": ["PREMIUM", "OTHER", "CURRENT", "VARIABLE"], // Adding CURRENT and VARIABLE for clarity, otherwise they will be treated as OTHER

This is a good pickup and can be included as part of this change noting that this was implied in the original proposal. The proposed solution has been updated to reflect this.

  1. "period": "string", // the period field should be added here for completeness, at the same level as tariffUType. This is link to Additional field to support Step Tariff calculations #625

This has been already been addressed as part of #625

  1. I'm assuming that the standards nesting structure support the example "Time-Varying - Option 1" that was provided above

That is correct.

The above was discussed in the MI19 call today (17th April) and participants supported introducing the two ENUM values as part of this change and MI18 for Chair approval. The staged changes will be updated to reflect this.

@nils-work
Copy link
Member

Standards version 1.30.0 was published on 24/04/2024 incorporating this change from MI18.

@github-project-automation github-project-automation bot moved this from Awaiting Chair Approval to Done in Data Standards Maintenance Apr 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Breaking change A change expected to result in a new endpoint version. Energy Proposal made The DSB has proposed a specific change to the standards to address the change request
Projects
Status: Done
Development

No branches or pull requests

9 participants