-
Notifications
You must be signed in to change notification settings - Fork 0
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
Add new SROC Billing Period service #30
Merged
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-3802 One of the factors that determines whether a charge version is to be included in a bill run, is whether it matches the 'billing period'. Initially, for SROC that's just going to be the current financial year. We're focused on getting supplementary billing sorted for this year but we know we'll need to iterate on this to handle multiple years in the future. So, to limit the change when we do that we're adding a `BillingPeriodService` in this change which will calculate what financial years need to be checked for a bill run. It's just that as of now it will just return the current financial year. Because we are adding this new service, we're also going to refactor out the current charge version query into its own service. `SupplementaryService` will then become the orchestrator for the whole process, and handle returning all relevant data to allow our QA team to confirm all is working as expected.
We were putting things in `test/` because that is where we have our controller. But it's only the endpoint that is provided for testing, hence `/test`. The services we have been writing will be retained and used for real (in some form) in the future. So, it doesn't make sense to keep them in a `test/` folder. Plus, it's blummin confusing! So, this quick change moves the services and their tests into `app/services/supplementary_billing`.
Cruikshanks
force-pushed
the
add-sroc-billing-period-service
branch
from
November 15, 2022 17:52
654b476
to
bfc0dc8
Compare
We're dealing with dates so we should probably return date values instead of strings. Also, added some documentation to the service and comments in the code that should prove helpful.
Cruikshanks
added a commit
that referenced
this pull request
Nov 22, 2022
https://eaflood.atlassian.net/browse/WATER-3787 https://eaflood.atlassian.net/browse/WATER-3802 https://eaflood.atlassian.net/browse/WATER-3826 We're trying to make it easy to test that we are selecting the right values from the DB when generating the SROC supplementary bill run. Our test endpoint currently list the charge versions, which includes the licence reference. In [Add new SROC Billing Period service](#30) we add the financial years. But it would be easier to validate the licences that have been selected if the response included a unique list of them rather than having to searching through the charge version results. This gives us a prime opportunity to split out the presentation logic from what the service is doing, especially as it is likely to be discarded when we are happy the process is working. So, in this change we move formatting the response to a new 'presenter'. As part of the change we'll add a unique list of the Licences being used.
Jozzey
approved these changes
Nov 22, 2022
Cruikshanks
added a commit
that referenced
this pull request
Nov 23, 2022
https://eaflood.atlassian.net/browse/WATER-3787 https://eaflood.atlassian.net/browse/WATER-3802 https://eaflood.atlassian.net/browse/WATER-3826 We're trying to make it easy to test that we are selecting the right values from the DB when generating the SROC supplementary bill run. Our test endpoint currently list the charge versions, which includes the licence reference. In [Add new SROC Billing Period service](#30) we add the financial years. But it would be easier to validate the licences that have been selected if the response included a unique list of them rather than having to searching through the charge version results. This gives us a prime opportunity to split out the presentation logic from what the service is doing, especially as it is likely to be discarded when we are happy the process is working. So, in this change we move formatting the response to a new 'presenter'. As part of the change we'll add a unique list of the Licences being used.
Cruikshanks
added a commit
that referenced
this pull request
Nov 23, 2022
https://eaflood.atlassian.net/browse/WATER-3787 https://eaflood.atlassian.net/browse/WATER-3802 https://eaflood.atlassian.net/browse/WATER-3826 We're trying to make it easy to test that we are selecting the right values from the DB when generating the SROC supplementary bill run. Our test endpoint currently lists the charge versions, which includes the licence reference. In [Add new SROC Billing Period service](#30) we add the financial years. But it would be easier to validate the licences that have been selected if the response included a unique list of them rather than having to search through the charge version results. This gives us a prime opportunity to split out the presentation logic from what the service is doing, especially as it is likely to be discarded when we are happy the process is working. So, in this change, we move formatting the response to a new 'presenter'. As part of the change, we'll add a unique list of the Licences being used. Example response following this change ```json { "billingPeriods": [ { "startDate": "2022-04-01T00:00:00.000Z", "endDate": "2023-03-31T00:00:00.000Z" } ], "licences": [ { "licenceId": "2627a306-23a3-432f-9c71-a71663888285", "licenceRef": "AT/SROC/SUPB/01" } ], "chargeVersions": [ { "chargeVersionId": "4b5cbe04-a0e2-468c-909e-1e2d93810ba8", "licenceRef": "AT/SROC/SUPB/01", "licenceId": "2627a306-23a3-432f-9c71-a71663888285", "scheme": "sroc", "endDate": null }, { "chargeVersionId": "732fde85-fd3b-44e8-811f-8e6f4eb8cf6f", "licenceRef": "AT/SROC/SUPB/01", "licenceId": "2627a306-23a3-432f-9c71-a71663888285", "scheme": "sroc", "endDate": null } ] } ```
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-3802
One of the factors that determine whether a charge version is to be included in a bill run, is whether it matches the 'billing period'.
Initially, for SROC that's just going to be the current financial year. We're focused on getting supplementary billing sorted for this year but we know we'll need to iterate on this to handle multiple years in the future.
So, to limit the change when we do that we're adding a
BillingPeriodService
in this change which will calculate what financial years need to be checked for a bill run. It's just that as of now it will just return the current financial year.Because we are adding this new service, we're also going to refactor out the current charge version query into its own service.
SupplementaryService
will then become the orchestrator for the whole process, and handle returning all relevant data to allow our QA team to confirm all is working as expected.Notes
We were putting things in
test/
because that is where we have our controller. But it's only the endpoint that is provided for testing, hence/test
. The services we have been writing will be retained and used for real (in some form) in the future. So, it doesn't make sense to keep them in atest/
folder. Plus, it's blummin confusing!