Fix comparison Section 126 factor in supp. billing #224
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-4010 We found another scenario where the bill run was always adding a credit and debit for a charge version on each bill run. The scenario was a new charge version is added which applies an abatement agreement (section 126 factor). The bill run gets run and sent. Another minor change is then made. No new debit and credit is needed. But when the engine grabs the previous debit, flips it to a credit and compares it against the calculated line it finds they don't match. This results in a debit and credit for the same amount appearing each time when they should be cancelled out and not appear at all. We tracked the problem down to the `charge_element` holding all the values as strings inside a JSONB field (`adjustments`). But when they get persisted to the `billing_transactions` table they are properly stored as a number. This is the same issue as [Fix including unnecessary supp. billing trans.](#210) only in reverse. Thanks legacy code! This change ensures when it comes to the comparison of `section126Factor` both previous and calculated and looking at the same data type.
If we pass `undefined` or `null` to `Number()` it will return `NaN` which is interpreted as `false`. So, the result is the same as previous and the default value is returned. If it has a value though, we'll now have it set as a number ready for comparison with any previous billing transactions, which save them as numbers.
Having spotted this issue we update the charge element helper to default the adjustments to match how they are actually stored in the DB. This also means we by default test our changes. `aggregate` when converted during testing of `GenerateBillingTransactionsService` should match as a number. `s126` and `charge` left as is will confirm we still use the default when no value exists.
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-4010
We found another scenario where the bill run always added credit and debit for the charge version on each bill run.
The scenario was a new charge version was added which applied an abatement agreement (section 126 factor). The bill run gets run and sent.
Another minor change is then made. No new debit and credit are needed. But when the engine grabs the previous debit, flips it to credit and compares it against the calculated line it finds they don't match.
This results in a debit and credit for the same amount appearing each time when they should be cancelled out and not appear at all.
We tracked the problem down to the
charge_elementholding all the values as strings inside a JSONB field (adjustments). But when they get persisted to thebilling_transactionstable they are properly stored as a number.This is the same issue as Fix including unnecessary supp. billing trans. only in reverse. Thanks, legacy code!
This change ensures when it comes to the comparison of
section126Factorboth previous and calculated and looking at the same data type.