Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix including unnecessary supp. billing trans. (#210)
https://eaflood.atlassian.net/browse/WATER-3989 Recent testing found an issue following the change we made in [Inc. changes to agreements & charges in supp bill](#207). Although the final result was correct, we were always creating invoices with transaction lines for scenarios we should have been returning an `EMPTY` bill run. The reason was our changed logic to compare calculated transaction lines to previous ones. It was always returning 'false' i.e. the lines were always different when they should be matching and cancelling each other out. The problem was an unexpected way the previous team was handling Section 130 agreements. Whether a charge version has one or not is held in the linked `charge_elements` table in the adjustments field, for example ```json {"s126": null, "s127": true, "s130": false, "charge": null, "winter": false, "aggregate": null} ``` We generate our calculated transaction lines using this source data so hold `section130Agreement` as a boolean. What we found when we looked at the `billing_transactions` table is that this is a varchar, not a boolean. It looks like the initial build of PRESROC billing stored values other than 'true' or 'false'. But that then changed to 'true' and 'false' and these are the only values used for SROC. This means we weren't aware `FetchPreviousBillingTransactionsService` was returning previous transactions with `section130Agreement` held as a string. So, when we came to compare it was causing it to always determine the transactions were different. So, this change fixes the issue by using [Knex raw](https://knexjs.org/guide/raw.html) to cast the value in our query to a boolean to match what we get and use in `FetchChargeVersionsService`. Doing at there will be the most performant and means it matches our expectations of what type `section130Agreement` will be.
- Loading branch information