Move reusable supplementary billing services #1760
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-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
the
housekeeping
We use `transactionsMatch()` in standard supplementary billing when comparing previous transactions to those generated as part of the 'in progress' bill run. With one minor tweak that won't effect standard supplementary, we can also make it work when comparing two-part tariff transactions. All other things being equal, if the different between a previous and current transaction is the volume, then both need to go into the bill run so we can 'bill' the charge difference between them.
Anything reusable in billing is held at the root of the folder. We change the name to try and make it clearer that this service is used in supplementary billing only.
During our spike we found it more flexible to pass through only the values needed by the service, rather than have it extract them from objects passed in.
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!
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.
Cruikshanks
added a commit
that referenced
this pull request
Mar 3, 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. Then we spotted [some two-part tariff billing services we could remove and reuse](#1765). The final step of supporting two-part tariff supplementary, like standard supplementary, is the flagging. When changes are made to licences they are flagged for supplementary billing, and it is these 'flags' that drive whether a licence is considered as part of a supplementary bill run. Just as complex as setting the flags, is unsetting them. There are various actions, either driven by the users or from logic in the engines, that triggers licences becoming unflagged. Two scenarios a two-part tariff supplementary shares with a standard supplementary, are - when a licence after processing is found _not_ to have generated a bill - when the bill has been sent and the licence can be considered as having been 'processed' for supplementary billing We already have services that handle these scenarios, which are called at the appropriate times. So, ahead of adding the two-part tariff supplementary flagging logic, we move the existing services ready for reuse.
Cruikshanks
added a commit
that referenced
this pull request
Mar 3, 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. Then we spotted [some two-part tariff billing services we could remove and reuse](#1765). The final step of supporting two-part tariff supplementary, like standard supplementary, is the flagging. When changes are made to licences, they are flagged for supplementary billing, and it is these 'flags' that drive whether a licence is considered part of a supplementary bill run. Just as complex as setting the flags is unsetting them. Various actions, either driven by the users or from logic in the engines, trigger licences becoming unflagged. Two scenarios a two-part tariff supplementary shares with a standard supplementary, are - when a licence after processing is found _not_ to have generated a bill - when the bill has been sent and the licence can be considered as having been 'processed' for supplementary billing We already have services that handle these scenarios, which are called at the appropriate times. So, before adding the two-part tariff supplementary flagging logic, we prepare the existing services for reuse.
Cruikshanks
added a commit
that referenced
this pull request
Mar 5, 2025
https://eaflood.atlassian.net/browse/WATER-4201 > Part of the work to support two-part tariff supplementary bill runs As part of [Move reusable supplementary billing services](#1760) we moved `FetchPreviousTransactionsService` so it could be reused by both the standard and two-part tariff supplementary billing engines. We just assumed on face value that we would fetch the previous transactions for a billing period, let the transactions compare and cancel out as normal, and any credits and debits that shake out at the end are what make up the bill run. But testing straight away threw up an issue with this assumption. Imagine the billing period is 2022-23 and we have licence `01/123`. A transaction was added to the annual bill run for 214 billable days and the authorised volume of 18.14ML. It also adds a compensation charge transaction. This is the 'first part charge'. Then the two-part tariff annual bill run is created for the same period. To that a transaction is added for 0 billable days and the authorised volume of 18.14ML. This is the 'second part charge'. A change is then made in the period, so the licence is flagged for two-part tariff supplementary. After the 2PT supplementary bill run is generated a user in the review pages allocates 30ML to the entry, then continues the bill run. At this point the fetch previous before this change was finding 3 debit transactions. | Bill run | Days | Volume | Charge | |----------|------|--------|--------| | Annual | 214 | 18.184 | 256.50 | | Annual | 214 | 18.184 | 0.00 | | 2PT Anl. | 0 | 18.184 | 256.50 | None of them match off against each other. So, they were then compared against the transaction generated for the two-part tariff supplementary. | Bill run | Days | Volume | Charge | |----------|------|--------|--------| | 2PT supp | 0 | 30 | 256.50 | None of the previous is a match, so no lines get cancelled. The end result is a credit of £513 against a debit of £256, with all 4 lines on it. The problem is `FetchPreviousTransactionsService` now needs to be 'billing specific'. When fetching previous transactions for a standard supplementary bill run, it should only be looking at annual and supplementary bill runs. For a two-part tariff bill run, it should only be looking at previous 2PT annual and supplementary. With this change, in our scenario the fetch will return only this transaction. | Bill run | Days | Volume | |----------|------|--------| | 2PT Anl. | 0 | 18.184 | It still wouldn't match to the one generated, but that is expected because the result needs to be the following. | Bill run | Days | Volume | |----------|------|--------| | 2PT Anl. | 0 | 18.184 | | 2PT supp | 0 | 30 |
Cruikshanks
added a commit
that referenced
this pull request
Mar 6, 2025
https://eaflood.atlassian.net/browse/WATER-4201 > Part of the work to support two-part tariff supplementary bill runs As part of [Move reusable supplementary billing services](#1760) we moved `FetchPreviousTransactionsService` so it could be reused by both the standard and two-part tariff supplementary billing engines. We just assumed on face value that we would fetch the previous transactions for a billing period, let the transactions compare and cancel out as usual, and any credits and debits that shake out at the end make up the bill run. But testing straight away threw up an issue with this assumption. Imagine the billing period is 2022-23 and we have licence `01/123`. A transaction was added to the annual bill run for 214 billable days and the authorised volume of 18.14ML. It also adds a compensation charge transaction. This is the 'first part charge'. Then the two-part tariff annual bill run is created for the same period. To that a transaction is added for 0 billable days and the authorised volume of 18.14ML. This is the 'second part charge'. A change is then made for the period (authorised bumped to 30ML), so the licence is flagged for two-part tariff supplementary. After the 2PT supplementary bill run is generated, a user in the review pages allocates 30ML to the entry and then continues the bill run. At this point, the 'fetch previous' before this change was finding three debit transactions. | Bill run | Days | Volume | Charge | |----------|------|--------|--------| | Annual | 214 | 18.184 | 256.50 | | Annual | 214 | 18.184 | 0.00 | | 2PT Anl. | 0 | 18.184 | 256.50 | None of them matched each other, so they were then compared against the transaction generated for the two-part tariff supplementary. | Bill run | Days | Volume | Charge | |----------|------|--------|--------| | 2PT supp | 0 | 30 | 256.50 | None of the previous is a match, so no lines get cancelled. The result is a credit of £513 against a debit of £256, with all four lines on it. The problem is that `FetchPreviousTransactionsService` now needs to be 'billing specific'. When fetching previous transactions for a standard supplementary bill run, it should only look at annual and supplementary bill runs. For a two-part tariff bill run, it should only look at the previous 2PT annual and supplementary bills. With this change, the fetch will return only this transaction in our scenario. | Bill run | Days | Volume | |----------|------|--------| | 2PT Anl. | 0 | 18.184 | It still wouldn't match the one generated, but that is expected because the result needs to be the following. | Bill run | Days | Volume | |----------|------|--------| | 2PT Anl. | 0 | 18.184 | | 2PT supp | 0 | 30 |
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
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.
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.