Add relationship - billing acc. <-> chg. version #750
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-4365 > For context this came out of us working on re-implementing the SROC annual bill run using what we've learnt and components from our supplementary billing engine. As part of looking at re-implementing the SROC annual billing engine in this project our spike (WATER-4348 ) confirmed we could simplify the implementation and improve performance if we extracted the billing account details at the same time as the charge versions to be billed. When we implemented the SROC supplementary billing engine we were directly working with the legacy schemas and tables. This meant we couldn't create relationships in models that sat in different schemas. But thanks to [Create water schema views](#551) and [Create crm_v2 schema views](#556) they are hidden away from us. We can now work as if the legacy schemas are a single schema. So, this change updates the `ChargeVersionModel` and `BillingAccountModel` to add a relationship between them which we can then exploit with our [Objection.js queries](https://vincit.github.io/objection.js/).
Cruikshanks
added
the
housekeeping
Cruikshanks
deleted the
add-relationship-between-billing-account-charge-version
branch
Cruikshanks
added a commit
that referenced
this pull request
Feb 20, 2024
https://eaflood.atlassian.net/browse/WATER-4365 > For context this came out of us working on re-implementing the SROC annual bill run using what we've learnt and components from our supplementary billing engine. As part of looking at re-implementing the SROC annual billing engine in this project our spike (WATER-4348 ) confirmed we could simplify the implementation and improve performance if we extracted the billing account details at the same time as the charge versions to be billed. In supplementary billing we first use `app/services/bill-runs/supplementary/fetch-charge-versions.service.js` to fetch all the charge versions that should be considered for billing. Then we call `app/services/bill-runs/supplementary/fetch-billing-accounts.service.js` to get the billing account info and merge the two using `PreGenerateBillingDataService` to pre-generate the bare bones bills and bill licences we need. In `app/services/bill-runs/supplementary/process-billing-period.service.js` we then have some 'clever' code that builds the billing data we need from the charge versions for each bill and bill licence we pre-generated. It took us awhile to get back up to speed on all this which made us review how we were doing things and come to the conclusion; what if we started at the bill level? What if rather than fetching the charge versions to consider and then extracting from this the bills we need to generate we instead go straight to fetching the billing accounts to consider? With our new [relationship between BillingAccountModel & ChargeVersionModel](#750) we can directly associate the charge versions we need to the billing accounts we fetch. This strips away the need for any pre-generation of data or calls to methods like `_buildBillingDataWithTransactions()` and `buildDataToPersist()`. So, this change adds the new service ready for use in our coming annual billing engine.
Cruikshanks
added a commit
that referenced
this pull request
Feb 21, 2024
https://eaflood.atlassian.net/browse/WATER-4365 > For context this came out of us working on re-implementing the SROC annual bill run using what we've learnt and components from our supplementary billing engine. As part of looking at re-implementing the SROC annual billing engine in this project our spike (WATER-4348 ) confirmed we could simplify the implementation and improve performance if we extracted the billing account details at the same time as the charge versions to be billed. In supplementary billing, we first use `app/services/bill-runs/supplementary/fetch-charge-versions.service.js` to fetch all the charge versions that should be considered for billing. Then we call `app/services/bill-runs/supplementary/fetch-billing-accounts.service.js` to get the billing account info and merge the two using `PreGenerateBillingDataService` to pre-generate the bare bones bills and bill licences we need. In `app/services/bill-runs/supplementary/process-billing-period.service.js` we then have some 'clever' code that builds the billing data we need from the charge versions for each bill and bill licence we pre-generated. It took us a while to get back up to speed on all this which made us review how we were doing things and come to the conclusion; what if we started at the bill level? What if rather than fetching the charge versions to consider and then extracting from this the bills we need to generate we instead go straight to fetching the billing accounts to consider? With our new [relationship between BillingAccountModel & ChargeVersionModel](#750) we can directly associate the charge versions we need to the billing accounts we fetch. This strips away the need for any pre-generation of data or calls to methods like `_buildBillingDataWithTransactions()` and `buildDataToPersist()`. So, this change adds the new service ready for use in our coming annual billing engine.
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-4365
As part of looking at re-implementing the SROC annual billing engine in this project our spike (WATER-4348 ) confirmed we could simplify the implementation and improve performance if we extracted the billing account details at the same time as the charge versions to be billed.
When we implemented the SROC supplementary billing engine we were directly working with the legacy schemas and tables. This meant we couldn't create relationships in models that sat in different schemas. But thanks to Create water schema views and Create crm_v2 schema views they are hidden away from us. We can now work as if the legacy schemas are a single schema.
So, this change updates the
ChargeVersionModelandBillingAccountModelto add a relationship between them which we can then exploit with our Objection.js queries.