Spike creating the 2PT supplementary bill run #1412
Closed
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
Cruikshanks
force-pushed
the
spike-two-part-tariff-bill-run
branch
from
824c0a0 to
7012be8
Compare
Cruikshanks
force-pushed
the
spike-two-part-tariff-bill-run
branch
2 times, most recently
from
8956c01 to
a7729de
Compare
Cruikshanks
added a commit
to DEFRA/water-abstraction-service
that referenced
this pull request
Feb 27, 2025
https://eaflood.atlassian.net/browse/WATER-4201 > Part of the work to support two-part tariff bill runs We are working on adding support for two-part tariff supplementary bill runs to the service. We've [spiked the logic](DEFRA/water-abstraction-system#1412) to understand how we can do this, but when doing it was being flagged as an error. No errors were thrown within [water-abstraction-system](https://github.com/DEFRA/water-abstraction-system), so we took a look at this project. That's when we spotted, after triggering `src/modules/billing/jobs/refresh-totals.js` an error was being thrown. This was because of the previous teams decision to validate all data both to and from the DB, and it not knowing about the new `two_part_supplementary` batch type.
Cruikshanks
added a commit
to DEFRA/water-abstraction-service
that referenced
this pull request
Feb 27, 2025
https://eaflood.atlassian.net/browse/WATER-4201 > Part of the work to support two-part tariff bill runs We are working on adding support for two-part tariff supplementary bill runs to the service. We've [spiked the logic](DEFRA/water-abstraction-system#1412) to understand how we can do this, but when doing it was being flagged as an error. No errors were thrown within [water-abstraction-system](https://github.com/DEFRA/water-abstraction-system), so we looked at this project. That's when we spotted, after triggering `src/modules/billing/jobs/refresh-totals.js`, an error was being thrown. This was because of the previous team's decision to validate all data both to and from the DB, and it not knowing about the new `two_part_supplementary` batch type.
https://eaflood.atlassian.net/browse/WATER-4201 User acceptance testing of the two-part tariff annual bill run is almost complete. There appear to be just a few niggles and 'nice to haves' remaining. We've moved onto repurposing this work for supplementary and made changes to support this. For example, allowing users to select 'Two-part tariff supplementary' as an option when creating a bill run (see the epic WATER-4202 for all changes). Also, lots of work to support how we flag licences for inclusion in a two-part tariff supplementary bill run. We're now at the point of needing to stitch it all together. After a user selects two-part tariff supplementary, select the licences to pass to the match and allocate engine. Then, after reviewing the matches and confirming the results, ensuring we create the actual supplementary bill run correctly. This spike is a space to get the complete journey working, and work out what exactly is needed.
We're going to add a new check in the TPT annual generate service to match one we'll include when we create the TPT supplementary generate service. And, as we'll be building the tests for TPT supplementary anew, we'll follow our current practise of stubbing out the simple calls made to the DB to reduce the number of records we're adding to the DB when running the unit tests. So, we might as well start with some refactoring of the existing tests to do the same!
We'll have two endpoints that do a similar thing for two similar bill run types going forward. So, we thought it prudent that they include a check to ensure they are processing the _right_ kind of two-part tariff bill run.
Straight up going to admit that due to time pressures, this is a bit of tech debt going on the 'credit card'. We've confirmed this service does exactly what we need it to do for tpt-supplementary. But we don't have the time to refactor it into a shared 'thing'. Our other excuse is we _know_ there are other things that could be refactored for reuse across the bill runs. Plus, a recent scare with the legacy PRE-SROC supplementary, has put it on the radar for being rebuilt. Therefore, we believe there is also a case for holding off refactoring until we have a complete picture of billing. See, told you we have an excuse! ;-)
Now, which end point the continue button triggers when clicked is dependant on the two-part tariff type of the bill run in review.
Cruikshanks
force-pushed
the
spike-two-part-tariff-bill-run
branch
from
550b48a to
8be4b40
Compare
Cruikshanks
force-pushed
the
spike-two-part-tariff-bill-run
branch
from
8be4b40 to
f764134
Compare
Cruikshanks
added a commit
that referenced
this pull request
Feb 28, 2025
https://eaflood.atlassian.net/browse/WATER-4201 As we write this description the long outstanding annual SROC two-part tariff bill runs are being 'sent' in production. The final part of two-part tariff is to add support for supplementary billing; when changes are made to a licence or the returns previously submitted and billed, we need to generate supplementary two-part tariff bill runs. We've already been making a number of changes in support of it, off the back of a [spike](#1412). That spike has shown us there are existing billing services, especially in supplementary billing, that we can reuse for two-part supplementary. This change moves them to make their reuse clearer, whilst tweaking a few things to allow the reuse to happen.
Cruikshanks
added a commit
that referenced
this pull request
Feb 28, 2025
https://eaflood.atlassian.net/browse/WATER-4201 As we write this description, the long outstanding annual SROC two-part tariff bill runs are being 'sent' in production. The final part of two-part tariff is to add support for supplementary billing; when changes are made to a licence or the returns previously submitted and billed, we need to generate supplementary two-part tariff bill runs. We've already made several changes to support it, off the back of a [spike](#1412). That spike has shown us there are existing billing services, especially in supplementary billing, that we can reuse for two-part supplementary. This change moves them to make their reuse more transparent, while tweaking a few things to allow reuse.
Cruikshanks
added a commit
that referenced
this pull request
Feb 28, 2025
https://eaflood.atlassian.net/browse/WATER-4201 > Part of the work to support two-part tariff supplementary bill runs In [Move reusable supplementary billing services](#1760) we shifted some existing supplementary billing services to make them resuable by the two-part tariff supplementary billing engine we're building. Our [spike](#1412) has shown there are some two-part tariff annual billing services we can also make reusable.
Cruikshanks
added a commit
that referenced
this pull request
Mar 1, 2025
https://eaflood.atlassian.net/browse/WATER-4201 > Part of the work to support two-part tariff supplementary bill runs In [Move reusable supplementary billing services](#1760) we shifted some existing supplementary billing services to make them reusable by the two-part tariff supplementary billing engine we're building. Our [spike](#1412) has shown there are some two-part tariff annual billing services we can also make reusable.
We want to reuse the same test data the two-part tariff annual process-billing-period service is using.
We just wanted to check that the things we expected to be persisted were, and that they were linked together. When the tests were originally written we were happy to interact with the DB. With our new ethos, if and when we can we stub the interaction instead. As we're about to duplicate a lot of the testing for supplementary, now seemed a good time to stop interacting with the DB in the existing tests.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Cruikshanks
added a commit
that referenced
this pull request
Mar 2, 2025
https://eaflood.atlassian.net/browse/WATER-4201 > Part of the work to support two-part tariff supplementary bill runs The long outstanding annual SROC two-part tariff bill runs have been 'sent' in production. The final part of two-part tariff is to add support for supplementary billing; when changes are made to a licence or the returns previously submitted and billed, we need to generate supplementary two-part tariff bill runs. We've already made several changes to support it, off the back of a [spike](#1412). This change adds the proper logic to `ProcessBillingPeriodService` for two-part tariff supplementary. `ProcessBillingPeriodService` is a service each bill run type contains, and is the 'heart' of each. It's here where the bills get generated and persisted, or ignored if found not to be billable.
Cruikshanks
added a commit
that referenced
this pull request
Mar 2, 2025
https://eaflood.atlassian.net/browse/WATER-4201 > Part of the work to support two-part tariff supplementary bill runs The long outstanding annual SROC two-part tariff bill runs have been 'sent' in production. The final part of two-part tariff is to add support for supplementary billing; when changes are made to a licence or the returns previously submitted and billed, we need to generate supplementary two-part tariff bill runs. We've already made several changes to support it, off the back of a [spike](#1412). This change adds the proper logic to `ProcessBillingPeriodService` for two-part tariff supplementary. `ProcessBillingPeriodService` is a service each bill run type contains, and is the 'heart' of each. It's here where the bills get generated, persisted, or ignored if found not billable.
Having the one service means the billing engines can follow a consistent pattern, and you can see we are having to deal with the same scenarios for both bill types (even if how you achieve them differs).
When developing the unit tests we debugged the query Objection was generating, and spotted that it was using `SELECT *` where we were using `relatedQuery()`. Ordinarily that would be fine, but as we are using it in an `exists` clause it is unnecessary. This change also means it is easier to see the queries are checking for the same things.
When developing the unit tests we debugged the query Objection was generating, and spotted that it was using `SELECT *` where we were using `relatedQuery()`. Ordinarily that would be fine, but as we are using it in an `exists` clause it is unnecessary. This change also means it is easier to see the queries are checking for the same things.
|
With Handle TPT licence flags during supp process - pt2 the final piece to implementing TPT supplementary billing was implemented. So, we can now close this spike. 🎉 |
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-4201
User acceptance testing of the two-part tariff annual bill run is almost complete. There appear to be just a few niggles and 'nice to haves' remaining.
We've moved on to repurposing this work for supplementary and made changes to support this. For example, we now allow users to select 'Two-part tariff supplementary' as an option when creating a bill run (see the epic WATER-4202 for all changes). We also have lots of work to support how we flag licences for inclusion in a two-part tariff supplementary bill run.
We're now at the point where we need to stitch it all together. After a user selects a two-part tariff supplementary, select the licences to pass to the match and allocate the engine. Then, after reviewing the matches and confirming the results, ensure we create the actual supplementary bill run correctly.
This spike is a space to get the complete journey working and determine what exactly is needed.