Handle empty supplementary bill runs #153
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-3923 From the charge version we generate transaction lines. For each charge element (reference) we look at the charge purposes connected to it and calculate the billable days. If that result is 0, we skip adding the transaction to the bill run. This means there is often a case where having calculated and rejected all the transaction lines, the bill run is 'empty'. The legacy process will update the status of the bill run to `empty`, and remove any `billing_invoice` and `billing_invoice_licence` records created. We need to do the same, though we intend to take a different approach. We'll process all the transaction lines first and only create `billing_invoice` and `billing_invoice_licence` records for those that remain. Should there be none, we'll go straight to marking the bill run as `empty` and stop the process there. Our intent is to remove needless calls to the DB and simplify the process.
Cruikshanks
force-pushed
the
handle-empty-supplementary-bill-runs
branch
from
c5e6537 to
a390d06
Compare
Copy and paste from other service. We're not doing anything async so we can drop this.
The solution that has been implemented means we don't have to worry about what transactions got persisted. So, we can delete this section.
You have to persist the billing invoices first else the billing invoice licence lines complain about a missing foreign key. Fortunately, we don't have the same problem with billing_transactions!
Have tested locally at this stage and we are able to complete a supplementary bill run!
The size of the `go()` function was concerning me at this point. I was also weighing up the trade-offs between keeping another list of objects in memory that could potentially be as large as the original `generatedInvoices` vs the overhead of calling `filter()` on our original list. My suggestion is to go with the latter, because it also helps shift some of the logic out of the `go()` function so we can break down what is happening and IMHO make things a little clearer. But this is a suggestion so I am happy to be argued out of it. 🤷
realised we were not considering the licenceID when trying to find the existing billing invoice licence record.
Hopefully, how we are dropping the persist flag is clearer. It also means we are following our convention for arrow functions. We also did some testing and found the call to `Object.values()` was just returning the same array passed in. So, we've dropped it.
A sonarcloud suggestion
We were supposed to be setting the status to empty. Stemmed from the original copy and paste.
|
The issues with SonarCloud are to do with code coverage on the |
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-3923
From the charge version, we generate transaction lines. For each charge element (reference) we look at the charge purposes connected to it and calculate the billable days. If that result is 0, we skip adding the transaction to the bill run.
This means there is often a case where having calculated and rejected all the transaction lines, the bill run is 'empty'. The legacy process will update the status of the bill run to
empty, and remove anybilling_invoiceandbilling_invoice_licencerecords created.We need to do the same, though we intend to take a different approach. We'll process all the transaction lines first and only create
billing_invoiceandbilling_invoice_licencerecords for those that remain. Should there be none, we'll go straight to marking the bill run asemptyand stop the process there.Our intent is to remove needless calls to the DB and simplify the process.