Determine other factors for SROC transaction line #108
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-3895 To get the Charging Module API to generate a charge we need more information than just billable days (see WATER-3894) Using how the legacy code generates an SROC transaction line for an annual bill run, we need to create the same type of record in billing_transactions So, the individual data points need to be sourced from the same places. We then need to populate the same fields. N.B. We looking at the current SROC transactions specifically because there are fields they don't bother to populate.
We initially define our service (with some fields still to-do) and create a unit test which successfully passes for a simple static field. This lets us know that our testing structure is correct
When calculating `billableDays` we need the abstraction period columns to be present in the `charge_elements` table, so we create migrations to add them for our test purposes
The two fields work very similarly, just with slightly different inputs. We therefore consolidate the common code
We mistakenly used the non-existent `id` property of the charge element. We fix this by using the correct `chargeElementId` property
The test file we used as a template included Sinon, but we realised that as we're not currently using it we can remove it
`chargeFactor` depends on us passing in a flag/option to specify whether this is a standard or compensation charge. Since we know we will be introducing additional options for future fields, we go straight into using our existing pattern for passing an object of options with defaults
When we pass the `isNewLicence` option we reflect its value in the output. Note that in the legacy code, the value of this is set by the `isMinimumCharge` flag, but as we're passing this in we simply give the option the same name as the output field and we will ensure it's passed in with the correct name
Note that as we are not yet creating two-part tariff transactions, we hardcode this field to `false`
We previously returned the `billableDays` value of only one of the periods returned by `AbstractionBillingPeriodService`. After discussing this we realised that we actually needed the sum of _all_ the `billableDays` values, so we update our code accordingly
Previously we were assuming that a chargePeriod object would be passed to the service. However as this is extracted from a chargeVersion object, it makes more sense for the logic to do this to live inside our service.
Cruikshanks
approved these changes
Feb 20, 2023
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-3895
To get the Charging Module API to generate a charge we need more information than just billable days (see WATER-3894)
Using how the legacy code generates an SROC transaction line for an annual bill run, we need to create the same type of record in
billing_transactionsSo, the individual data points need to be sourced from the same places. We then need to populate the same fields. Note that we are looking at the current SROC transactions specifically because there are fields they don't bother to populate.
This PR creates
FormatSrocTransactionLineService, which takes a charge element, a charge version and a financial year (plus optionally some flags to indicate whether this is a compensation charge, two part second charge, etc.) and returns an object representing a transaction, formatted ready to be inserted into the db.