Supplementary billing housekeeping #857
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-4403 > Part of changes to exclude the current financial year from supplementary billing if the annual bill run has not been completed We have recently migrated the SROC annual billing engine into our project ( WATER-4345 ). The primary drive to do this was to enable them run annual bill runs in April at the same time as licensees are submitting their return data. This is when the service is under its greatest load so we wanted to ensure annual billing could take advantage of the improvements we made as part of the supplementary billing we implemented. Re-visiting supplementary billing as part of that migration meant we spotted further improvements we could make. For example, thanks to our models now being [view](https://www.postgresql.org/docs/current/sql-createview.html) based means tables being in different schemas is no longer a blocker to us creating relationships in the models. In our annual billing engine we are able to fetch everything at the billing account level removing the need for additional queries and the need to pre-generate billing objects. We were also able to implement a batch process, whereby multiple bills can be processed at the same time. We want to bring these improvements to our supplementary billing engine before we start making changes to support excluding the current financial year.
We never needed the whole BillLicence, just its ID.
We seemed to have been passing whole objects around we think 'just in case'. We can see now we only ever needed their ID's or specific properties so we can stop doing that!
The original query was built when we thought we needed to get billing account details as part of the query. This was because we thought we'd be matching as we iterated the charge versions we fetch and their charge elements. The version of the supplementary billing engine that finally switched had opted to pre-generate billing data and then iterate it. The need to access billing account information on the transaction had become redundant. We should have noticed at the time but it's never too late! Because we can drop those elements we can switch to using Objection which tidies up the query some, for example, the `purposes` field now comes through as proper JSON. These changes to the what `FetchPreviousTransactionsService` returns also means we can remove some of the logic in `ReverseTransactionsService`.
Cruikshanks
added
the
housekeeping
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 have recently migrated the SROC annual billing engine into our project ( WATER-4345 ). The primary drive to do this was to enable our users to run annual bill runs in April at the same time as licensees are submitting their return data. This is when the service is under its greatest load so we wanted to ensure annual billing could take advantage of the improvements our supplementary billing engine has over the legacy one.
But having built the annual billing engine, we found there were improvements we could make to our supplementary billing engine!
So, we're doing this in two parts. This first part covers some housekeeping changes we've spotted that could be made.
ProcessBillRunServiceshould have usedcurrentTimeInNanosecondsto get the start timeHandleErroredBillRunServicewas in the wrong placeFetchPreviousTransactionsServiceto use Objection rather than Knex rawFetchPreviousTransactionsServicequery (which means we can simplify the conversion inReverseTransactionsService)