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

Fix Ret. Req. logic to determine cycle for 2PT #1124

Merged
merged 4 commits into from
Jun 20, 2024

Conversation

Cruikshanks
Copy link
Member

https://eaflood.atlassian.net/browse/WATER-4512

Part of the work to replace NALD for handling return requirements

We want to be able to offer users the option to generate return requirements from the licence's abstraction data. On the /setup page, they can select this option, and the service is expected to generate return requirements using the source abstraction data against the licence.

We added support for this in Use abstraction data to create return requirements. But after double-checking the test scenarios we've made a mistake in the logic.

We've determined a return requirement will be linked to a purpose that is two-part tariff purely based on the purpose's two-part tariff flag. This effects the collection and reporting cycle we pick for the return requirement.

But the purpose can only be interpreted as two-part tariff if the licence also has a two-part tariff agreement. So, the purpose might be spray irrigation, for example, which is flagged as two-part tariff. But if the licence doesn't also have a two-part tariff agreement we need to ignore that when determining the cycles for the return requirement.

This change fixes our logic in GenerateFromAbstractionDataService.

https://eaflood.atlassian.net/browse/WATER-4512

> Part of the work to replace NALD for handling return requirements

We want to be able to offer users the option to generate return requirements from the licence's abstraction data. On the `/setup` page, they can select this option and the service is expected to generate return requirements using the source abstraction data against the licence.

We added support for this in [Use abstraction data to create return requirements](#1107). But after double checking the test scenarios we've made a mistake in the logic.

We've determined a return requirement will be linked to a purpose that is two-part tariff purely based on the purpose's two-part tariff flag. This effects what collection and reporting cycle we pick for the return requirement.

But the purpose can only be interpreted as two-part tariff if the licence also has a two-part tariff agreement. So, the purpose might be spray irrigation, for example, which is flagged as two-part tariff. But if the licence doesn't also have a two-part tariff agreement we need to ignore that when determining the cycles for the return requirement.

This change fixes our logic in `GenerateFromAbstractionDataService`.
@Cruikshanks Cruikshanks added the bug Something isn't working label Jun 19, 2024
@Cruikshanks Cruikshanks self-assigned this Jun 19, 2024
@Cruikshanks Cruikshanks marked this pull request as ready for review June 19, 2024 19:35
Copy link
Contributor

@Jozzey Jozzey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Cruikshanks Cruikshanks merged commit 7dc37cd into main Jun 20, 2024
6 checks passed
@Cruikshanks Cruikshanks deleted the fix-ret-req-use-abstraction-2pt-agreements branch June 20, 2024 09:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants