Add SROC include in supplementary billing flag #2077
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
https://eaflood.atlassian.net/browse/WATER-3948 We have an issue that the current `include_in_supplementary_billing` was added at a time there was only 1 charge scheme. A licence gets flagged irrespective of whether the change relates to PRESROC or SROC. Where that has impacted us is when sending a billing batch. When it gets sent it clears the flag for _all_ licences included. But if we cancel one, for example the PRESROC bill run, and send the SROC one we loose which licences still need to be processed on the PRESROC one. Our solution, is to add a new `include_in_sroc_supplementary_billing` flag to the `licences` table. This change covers - a migration to add it to the table - updating the logic which sets the include in supp. billing flags when a charge version is approved to update only the relevant flag
The test setup was duplicating setting the charge version and calling `fromHash()` unnecessarily. It also had a test that was just confirming the scheme matched what we set in the test value. Pointless!
Update the charge versions workflow approve to get ready for testing whether we are just setting the respective include in supplementary billing flag.
We update the `flagForSupplementaryBilling()` to now take an optional scheme arg. Then in the `approve()` function we pass through the scheme of the newly approved and persisted charge version. It's still setting the same field, but we'll sort the migration and update that logic next.
It _is_ a pointless await because `flagForSupplementaryBilling()` was never marked as async. Now, we didn't put the await in. But because we touched SonarCloud is shouting at us.
We want to ensure our new field is available for use in the UI. But when we looked at the existing DB to Model mapper test even the existing include in supplementary billing flag was not being checked. So, first step is to ensure that is covered.
Cruikshanks
added a commit
to DEFRA/water-abstraction-ui
that referenced
this pull request
Mar 27, 2023
https://eaflood.atlassian.net/browse/WATER-3948 We have an issue that the current `include_in_supplementary_billing` flag was added at a time there was only 1 charge scheme. A licence gets flagged irrespective of whether the change relates to PRESROC or SROC. Where that has impacted us is when sending a billing batch. When it gets sent it clears the flag for _all_ licences included. But if we cancel one, for example, the PRESROC bill run, and send the SROC one we lose which licences still need to be processed on the PRESROC one. [Our solution](DEFRA/water-abstraction-service#2077) was to add a new `include_in_sroc_supplementary_billing` flag to the `licences` table and only set it to 'true' when an SROC charge version is approved. But this means a licence might be flagged only for SROC supplementary billing and the existing functionality to highlight this only looks at the `include_in_supplementary_billing` field. This change updates the 'marked for next supplementary bill run' notice to handle - marked for next PRESROC supplementary bill run only - marked for next SROC supplementary bill run only - marked for both schemes next supplementary bill run only
Cruikshanks
added a commit
to DEFRA/water-abstraction-system
that referenced
this pull request
Mar 27, 2023
https://eaflood.atlassian.net/browse/WATER-3948 We have an issue that the current `include_in_supplementary_billing` flag was added at a time there was only 1 charge scheme. A licence gets flagged irrespective of whether the change relates to PRESROC or SROC. Where that has impacted us is when sending a billing batch. When it gets sent it clears the flag for _all_ licences included. But if we cancel one, for example, the PRESROC bill run, and send the SROC one we lose which licences still need to be processed on the PRESROC one. [Our solution](DEFRA/water-abstraction-service#2077) is to add a new `include_in_sroc_supplementary_billing` flag to the `licences` table and only set it to 'true' when an SROC charge version is approved. With this in place our `FetchChargeVersionsService` needs to be altered to look at that field instead of the old one to identify charge versions to consider for billing.
Cruikshanks
added a commit
to DEFRA/water-abstraction-system
that referenced
this pull request
Mar 27, 2023
https://eaflood.atlassian.net/browse/WATER-3948 To resolve the issue of dealing with PRESROC and SROC licences flagged for supplementary billing, and how we remove those flags when bill runs get 'sent' we've [made a change to the `FetchChargeVersionsService`](#177) to look at a [new field we've added](DEFRA/water-abstraction-service#2077) to the `water.licences` table. This broke some tests, a number of which were in the `FetchLicencesService`. We were about to embark on fixing them when we remembered that with the direction our work on supplementary billing took `FetchLicencesService` had become redundant. So, rather than spend time fixing them we're just getting on and removing the service.
Cruikshanks
added a commit
to DEFRA/water-abstraction-ui
that referenced
this pull request
Mar 28, 2023
https://eaflood.atlassian.net/browse/WATER-3948 We have an issue that the current `include_in_supplementary_billing` flag was added at a time there was only 1 charge scheme. A licence gets flagged irrespective of whether the change relates to PRESROC or SROC. Where that has impacted us is when sending a billing batch. When it gets sent it clears the flag for _all_ licences included. But if we cancel one, for example, the PRESROC bill run, and send the SROC one we lose which licences still need to be processed on the PRESROC one. [Our solution](DEFRA/water-abstraction-service#2077) was to add a new `include_in_sroc_supplementary_billing` flag to the `licences` table and only set it to 'true' when an SROC charge version is approved. But this means a licence might be flagged only for SROC supplementary billing and the existing functionality to highlight this only looks at the `include_in_supplementary_billing` field. This change updates the 'marked for next supplementary bill run' notice to handle - marked for next PRESROC supplementary bill run only - marked for next SROC supplementary bill run only - marked for both schemes next supplementary bill run only
Cruikshanks
added a commit
to DEFRA/water-abstraction-system
that referenced
this pull request
Mar 28, 2023
https://eaflood.atlassian.net/browse/WATER-3948 To resolve the issue of dealing with PRESROC and SROC licences flagged for supplementary billing, and how we remove those flags when bill runs get 'sent' we've [made a change to the `FetchChargeVersionsService`](#177) to look at a [new field we've added](DEFRA/water-abstraction-service#2077) to the `water.licences` table. This broke some tests, a number of which were in the `FetchLicencesService`. We were about to embark on fixing them when we remembered that with the direction our work on supplementary billing took `FetchLicencesService` had become redundant. So, rather than spend time fixing them we're just getting on and removing the service.
Cruikshanks
added a commit
to DEFRA/water-abstraction-system
that referenced
this pull request
Mar 28, 2023
https://eaflood.atlassian.net/browse/WATER-3948 We have an issue that the current `include_in_supplementary_billing` flag was added at a time there was only 1 charge scheme. A licence gets flagged irrespective of whether the change relates to PRESROC or SROC. Where that has impacted us is when sending a billing batch. When it gets sent it clears the flag for _all_ licences included. But if we cancel one, for example, the PRESROC bill run, and send the SROC one we lose which licences still need to be processed on the PRESROC one. [Our solution](DEFRA/water-abstraction-service#2077) is to add a new `include_in_sroc_supplementary_billing` flag to the `licences` table and only set it to 'true' when an SROC charge version is approved. With this in place our `FetchChargeVersionsService` needs to be altered to look at that field instead of the old one to identify charge versions to consider for billing.
Cruikshanks
added a commit
that referenced
this pull request
Mar 28, 2023
https://eaflood.atlassian.net/browse/WATER-3948 We have an issue that the current `include_in_supplementary_billing` was added at a time there was only 1 charge scheme. A licence gets flagged irrespective of whether the change relates to PRESROC or SROC. Where that has impacted us is when sending a billing batch. When it gets sent it clears the flag for _all_ licences included. But if we cancel one, for example, the PRESROC bill run, and send the SROC one we lose which licences still need to be processed on the PRESROC one. Our solution was to add a new `include_in_sroc_supplementary_billing` flag to the `licences` table in [Add SROC include in supplementary billing flag](#2077). That also covered setting the new flag when a new charge version is approved. We now need to handle clearing the flag when the SROC bill run is 'sent'.
Cruikshanks
added a commit
to DEFRA/water-abstraction-system
that referenced
this pull request
Mar 29, 2023
https://eaflood.atlassian.net/browse/WATER-3948 We have an issue that the current `include_in_supplementary_billing` flag was added at a time there was only 1 charge scheme. A licence gets flagged irrespective of whether the change relates to PRESROC or SROC. Where that has impacted us is when sending a billing batch. When it gets sent it clears the flag for _all_ licences included. But if we cancel one, for example, the PRESROC bill run, and send the SROC one we lose which licences still need to be processed on the PRESROC one. [Our solution](DEFRA/water-abstraction-service#2077) is to add a new `include_in_sroc_supplementary_billing` flag to the `licences` table and only set it to 'true' when an SROC charge version is approved. With this in place our `FetchChargeVersionsService` needs to be altered to look at that field instead of the old one to identify charge versions to consider for billing.
Cruikshanks
added a commit
that referenced
this pull request
Mar 30, 2023
https://eaflood.atlassian.net/browse/WATER-3948 We have an issue that the current `include_in_supplementary_billing` was added at a time there was only 1 charge scheme. A licence gets flagged irrespective of whether the change relates to PRESROC or SROC. Where that has impacted us is when sending a billing batch. When it gets sent it clears the flag for _all_ licences included. But if we cancel one, for example, the PRESROC bill run, and send the SROC one we lose which licences still need to be processed on the PRESROC one. Our solution was to add a new `include_in_sroc_supplementary_billing` flag to the `licences` table in [Add SROC include in supplementary billing flag](#2077). That also covered setting the new flag when a new charge version is approved. We now need to handle clearing the flag when the SROC bill run is 'sent'.
Cruikshanks
added a commit
that referenced
this pull request
Mar 31, 2023
https://eaflood.atlassian.net/browse/WATER-3951 We had an issue that the current `include_in_supplementary_billing` flag was added at a time there was only 1 charge scheme. A licence gets flagged irrespective of whether the change relates to PRESROC or SROC. Where that has impacted us is when sending a billing batch. When it gets sent it clears the flag for _all_ licences included. But if we cancel one, for example, the PRESROC bill run, and send the SROC one we lose which licences still need to be processed on the PRESROC one. [Our solution](#2077) was to add a new `include_in_sroc_supplementary_billing` flag to the `licences` table and only set it to 'true' when an SROC charge version is approved. That is all now working for new charge versions created and approved. The remaining issue is existing charge versions that have been processed. When this change goes live there will be a number of SROC charge versions that have been approved and should be considered. But when they were approved only the `include_in_supplementary_billing` flag existed. We could try and do something clever, and look at all the SROC charge versions that have been approved this year and then only set the flag against their connect licences. But we've decided instead to just set `include_in_sroc_supplementary_billing` to true for those licences where `include_in_supplementary_billing` is true. It might result in some empty SROC bill runs. But it's far simpler, so there is less chance we'll get something wrong and miss licences. So, this change adds a migration that will set the flags when first deployed.
Cruikshanks
added a commit
that referenced
this pull request
Mar 31, 2023
https://eaflood.atlassian.net/browse/WATER-3951 We had an issue that the current `include_in_supplementary_billing` flag was added when there was only 1 charge scheme. A licence gets flagged irrespective of whether the change relates to PRESROC or SROC. Where that has impacted us is when sending a billing batch. When it gets sent it clears the flag for _all_ licences included. But if we cancel one, for example, the PRESROC bill run, and send the SROC one we lose which licences still need to be processed on the PRESROC one. [Our solution](#2077) was to add a new `include_in_sroc_supplementary_billing` flag to the `licences` table and only set it to 'true' when an SROC charge version is approved. That is all now working for new charge versions created and approved. The remaining issue is existing charge versions that have been processed. When this change goes live there will be some SROC charge versions that have been approved and should be considered. But when they were approved only the `include_in_supplementary_billing` flag existed. We could try and do something clever, and look at all the SROC charge versions that have been approved this year and then only set the flag against their connect licences. But we've decided instead to set `include_in_sroc_supplementary_billing` to true for those licences where `include_in_supplementary_billing` is true. It might result in some empty SROC bill runs. But it's far simpler, so there is less chance we'll get something wrong and miss licences. So, this change adds a migration that will set the flags when first deployed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://eaflood.atlassian.net/browse/WATER-3948
We have an issue that the current
include_in_supplementary_billingwas added at a time there was only 1 charge scheme. A licence gets flagged irrespective of whether the change relates to PRESROC or SROC.Where that has impacted us is when sending a billing batch. When it gets sent it clears the flag for all licences included. But if we cancel one, for example, the PRESROC bill run, and send the SROC one we lose which licences still need to be processed on the PRESROC one.
Our solution is to add a new
include_in_sroc_supplementary_billingflag to thelicencestable. This change covers