Refactor DetermineBillingPeriods to use type #864
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
Cruikshanks
added
the
housekeeping
https://eaflood.atlassian.net/browse/WATER-4403 We want our Billing & Data team to be able to generate supplementary bill runs all year round. However, at the moment they have to enforce a manual 'stop' on them until annual bill runs are completed. This is because of the 2 ways the engine operate. Annual just bills for the current charge versions. It doesn't look at replaced charge versions or what was previously billed. supplementary does do these things. So, if the order is 'Annual -> Supplementary' then the bill will be correct. For example, supplementary calculates a debit of a £100 for a charge version (the licence was flagged for 'reasons'!) but sees the £100 debit from the annual bill. They cancel each other out so the customer sees nothing. If the order was `Supplementary -> Annual` though, annual doesn't look back at previous transactions. It would just generate another debit to the customer for £100 leading to them being billed twice. We could guarantee annual bills were raised on April 1 we wouldn't have a problem. However, because of the additional work that goes into preparing them and then validating the what the engine generates it can take some time. That leaves a window where a supplementary could be raised and the charges for a customer get messed up. This has always been the case and billing & data have just had to deal with it by not generating supplementary. But that in itself causes problems because then bills start backing up that could be sent out. So, this year we intend to solve the problem. We are going to amend our supplementary billing engine so that it will check if an annual bill run for the same region has been raised in the current billing period. If it has we'll carry on as usual. If it hasn't, we'll move the financial year end back to the first year where one was raised. This will allow B&D to crack on with supplementary bills, at least for previous years and prevent charging data being messed up. The first step to achieving this is to refactor `DetermineBillingPeriods` to always expect a `year` and a `billRunType`. It can then use this information to generate the billing periods accordingly, rather than always from the current billing period. > How we determine the financial end year for a supplementary bill run will come in later changes.
Cruikshanks
force-pushed
the
update-determine-billing-periods
branch
from
bb55777 to
23c39db
Compare
It now expects the bill run type and uses this information to decide how many billing periods to return and not the financial year. This sets us up to be able to tell the service we need the billing periods for a supplementary bill run, but start in year X instead of the current financial year.
It now needs to pass in `batchType`.
Now we've refactored `DetermineBillingPeriodsService` to not just return a single billing period when financial year is set we can remove the temporary fix we did in [Fix determine billing periods](#859).
Cruikshanks
requested review from
Demwunz,
robertparkinson,
Jozzey,
Beckyrose200 and
rvsiyad
Cruikshanks
added a commit
that referenced
this pull request
Apr 1, 2024
https://eaflood.atlassian.net/browse/WATER-4403 We want our Billing & Data team to be able to generate supplementary bill runs all year round. However, at the moment they have to enforce a manual 'stop' on them until annual bill runs are completed. This is because of the 2 ways the engine operates. Annual just bills for the current charge versions. It doesn't look at replaced charge versions or what was previously billed. supplementary does do these things. So, if the order is 'Annual -> Supplementary' then the bill will be correct. For example, supplementary calculates a debit of £100 for a charge version (the licence was flagged for 'reasons'!) but sees the £100 debit from the annual bill. They cancel each other out so the customer sees nothing. If the order was `Supplementary -> Annual` though, annual doesn't look back at previous transactions. It would generate another debit to the customer for £100 leading to them being billed twice. We could guarantee annual bills were raised on April 1 we wouldn't have a problem. However, the additional work that goes into preparing them and validating what the engine generates, means it can take some time. That leaves a window where a supplementary could be raised and the charges for a customer get messed up. This has always been the case and billing & data have just had to deal with it by not generating supplementary. But that causes problems because bills start backing up that could be sent out. So, this year we intend to solve the problem. We will amend our supplementary billing engine to check if an annual bill run for the same region has been raised in the current billing period. If it has we'll carry on as usual. If it hasn't, we'll move the financial year end back to the first year where one was raised. This will allow B&D to crack on with supplementary bills, at least for previous years and prevent charging data from being messed up. The first step was to refactor [Refactor DetermineBillingPeriods to use type](#864). It can then use this information to generate the billing periods accordingly, rather than always from the current billing period. Now that service will work appropriately if given a type and year we can implement determining _what_ that year is.
Cruikshanks
added a commit
that referenced
this pull request
Apr 2, 2024
https://eaflood.atlassian.net/browse/WATER-4403 We want our Billing & Data team to be able to generate supplementary bill runs all year round. However, at the moment they have to enforce a manual 'stop' on them until annual bill runs are completed. This is because of the 2 ways the engine operates. Annual just bills for the current charge versions. It doesn't look at replaced charge versions or what was previously billed. supplementary does do these things. So, if the order is 'Annual -> Supplementary' then the bill will be correct. For example, supplementary calculates a debit of £100 for a charge version (the licence was flagged for 'reasons'!) but sees the £100 debit from the annual bill. They cancel each other out so the customer sees nothing. If the order was `Supplementary -> Annual` though, annual doesn't look back at previous transactions. It would generate another debit to the customer for £100 leading to them being billed twice. We could guarantee annual bills were raised on April 1 we wouldn't have a problem. However, the additional work that goes into preparing them and validating what the engine generates, means it can take some time. That leaves a window where a supplementary could be raised and the charges for a customer get messed up. This has always been the case and billing & data have just had to deal with it by not generating supplementary. But that causes problems because bills start backing up that could be sent out. So, this year we intend to solve the problem. We will amend our supplementary billing engine to check if an annual bill run for the same region has been raised in the current billing period. If it has we'll carry on as usual. If it hasn't, we'll move the financial year end back to the first year where one was raised. This will allow B&D to crack on with supplementary bills, at least for previous years and prevent charging data from being messed up. The first step was to refactor [Refactor DetermineBillingPeriods to use type](#864). It can then use this information to generate the billing periods accordingly, rather than always from the current billing period. Now that service will work appropriately if given a type and year we can implement determining _what_ that year is.
Cruikshanks
added a commit
that referenced
this pull request
Apr 2, 2024
https://eaflood.atlassian.net/browse/WATER-4403 In [Bump supplementary end year if no annual bill run](#875) we added logic that would mean when creating a new supplementary bill run the engine could tell if an annual bill run existed for the same year and region. If one doesn't it will make a mess of the billing for customers if the supplementary happened before the annual. But we don't want to block users from working. So, instead we bump the financial end year to use back to the same as the last 'sent' annual bill run for that region. We even [Refactor DetermineBillingPeriods to use type](#864) so it would know to use the calculated year when determining the billing periods for the supplementary bill run. What we forgot to do was remove a [temporary fix](#859) we'd added until this work can be completed. This means the year we've calculated is being dropped and not passed to `DetermineBillingPeriods`. This change fixes that!
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-4403
We want our Billing & Data team to be able to generate supplementary bill runs all year round. However, at the moment they have to enforce a manual 'stop' on them until annual bill runs are completed. This is because of the 2 ways the engine operates.
Annual just bills for the current charge versions. It doesn't look at replaced charge versions or what was previously billed. supplementary does do these things. So, if the order is 'Annual -> Supplementary' then the bill will be correct. For example, supplementary calculates a debit of £100 for a charge version (the licence was flagged for 'reasons'!) but sees the £100 debit from the annual bill. They cancel each other out so the customer sees nothing.
If the order was
Supplementary -> Annualthough, annual doesn't look back at previous transactions. It would generate another debit to the customer for £100 leading to them being billed twice.We could guarantee annual bills were raised on April 1 we wouldn't have a problem. However, the additional work that goes into preparing them and validating what the engine generates, means it can take some time. That leaves a window where a supplementary could be raised and the charges for a customer get messed up.
This has always been the case and billing & data have just had to deal with it by not generating supplementary. But that causes problems because bills start backing up that could be sent out.
So, this year we intend to solve the problem. We will amend our supplementary billing engine to check if an annual bill run for the same region has been raised in the current billing period. If it has we'll carry on as usual. If it hasn't, we'll move the financial year end back to the first year where one was raised. This will allow B&D to crack on with supplementary bills, at least for previous years and prevent charging data from being messed up.
The first step to achieving this is to refactor
DetermineBillingPeriodsto expect ayearand abillRunType. It can then use this information to generate the billing periods accordingly, rather than always from the current billing period.