Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement annual two-part tariff billing engine #1172

Merged
merged 8 commits into from
Jul 9, 2024

Conversation

Cruikshanks
Copy link
Member

@Cruikshanks Cruikshanks commented Jul 8, 2024

https://eaflood.atlassian.net/browse/WATER-4196

Part of the work for two-part tariff annual billing

We're ready to generate a bill run from our two-part tariff review data and with Add Continue bill run btn to 2PT review screen and Add new two-part tariff generate bill run endpoint we have the means to trigger it. We can now also Fetch all the billing accounts and related data needed to generate the bills.

This implements the remaining services needed to transform that data into actual bills using the same pattern we implemented for SROC annual billing.

  • a service to manage the process - GenerateBillRunService
  • a service to transform the data into bills ProcessBillingPeriodService
  • a mirror of GenerateTransactionService amended specifically for two-part tariff bill runs (because of the need to incorporate values from the review stage)

With this in place, users will finally be able to generate an annual two-part tariff SROC bill run!

https://eaflood.atlassian.net/browse/WATER-4196

> Part of the work for two-part tariff annual billing

We're ready to generate a bill run from our two-part tariff review data and with [Add Continue bill run btn to 2PT review screen](#1122) and [Add new two-part tariff generate bill run endpoint](#1123) we have the means to trigger it. We can now also [Fetch all the billing accounts and related data](#1129) needed to generate the bills.

This implements the remaining services needed to transform that data into actual bills using the same pattern we implemented for SROC annual billing.

- a service to manage the process - `GenerateBillRunService`
- a service to transform the data into bills `ProcessBillingPeriodService`
- a mirror of `GenerateTransactionService` amended specifically for two-part tariff bill runs (because of the need to incorporate values from the review stage)

With this in place users will finally be able to generate an annual two-part tariff SROC bill run!
@Cruikshanks Cruikshanks added the enhancement New feature or request label Jul 8, 2024
@Cruikshanks Cruikshanks self-assigned this Jul 8, 2024
Will be used in our ProcessBillingPeriodService tests to generate realistic data.
We overlooked including this when we added the service. But we must have it to support `ChargingModuleCreateTransactionPresenter` being able to generate the content needed for a POST transaction request to the charging module API.
We added the button logic in the view dependent on this property but never added it to the presenter!
@Cruikshanks Cruikshanks marked this pull request as ready for review July 9, 2024 08:26
@Cruikshanks Cruikshanks merged commit 7162104 into main Jul 9, 2024
5 of 6 checks passed
@Cruikshanks Cruikshanks deleted the implement-2pt-billing-engine branch July 9, 2024 08:27
Cruikshanks added a commit that referenced this pull request Jul 11, 2024
https://eaflood.atlassian.net/browse/WATER-4196

> Part of the two-part tariff annual billing work

We recently completed [implementation to the annual two-part tariff billing engine](#1172). But we've immediately spotted an error with the results.

We are not populating the correct field in order to see the amended billing volume being sent to the Charging Module and persisted against the transaction.

This change corrects the issue.
Cruikshanks added a commit that referenced this pull request Jul 11, 2024
https://eaflood.atlassian.net/browse/WATER-4196

> Part of the two-part tariff annual billing work

We recently completed [implementation of the annual two-part tariff billing engine](#1172). But we've immediately spotted an error with the results.

We are not populating the correct field in order to see the amended billing volume being sent to the Charging Module and persisting against the transaction.

However, that uncovered something else we'd overlooked. Now that we were using the review allocated amount, some transactions were being returned from `GenerateTransactionService` with a 0 volume, which caused the Charging Module to error.

Of course! If a return was submitted as a 'Nil return' then we should not be trying to generate a charge for those charge elements linked to it. 🤦 

So, this change corrects which value we are assigning to the generated transaction and therefore passing to the charging module. But it also updates the engine to handle ignoring transactions with no volume rather than attempting to send them to the Charging Module API.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant