Silo rebilling from supplementary #854
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-4403 When we initially delivered SROC supplementary billing we were required to continue to support handling reissuing bills. But the feature was put behind a feature flag so we could ship supplementary and then worry about reissuing. At the time we pointed out that in the life of WRLS only 8 bills had ever been re-issued. Yet it was one of the most complex processes to support. It turns out the billing & data team had also come to the same conclusion. There were things they had to be aware of and features in the UI they need to enable for reissuing to happen. Alternatively, they can just call SSCL and request they reissue the bill from SOP. Because of they've held off asking us to enable the feature. So, it has been more than 6 months and reissuing still hasn't been enabled in production. In that time we've made many other changes where we've disregarded reissuing to avoid needless complexity and our belief a decision will be made never to enable it. Should that assumption be wrong we'd need to make a suite of changes to support it, for example, in how we display things in the billing views. We are making a series of updates to the supplementary billing engine to implement the improvements we implemented in SROC annual billing. That refactoring is a prime opportunity to silo the reissuing from the engine and the complexity it adds.
Cruikshanks
added
the
housekeeping
We move the services that currently support reissuing a bill (rebilling) into their own folder and remove the call to them in the supplementary bill run process.
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-4403
When we initially delivered SROC supplementary billing we were required to continue to support handling reissuing bills.
But the feature was put behind a feature flag so we could ship supplementary and then worry about reissuing.
At the time we pointed out that in the life of WRLS, only 8 bills had ever been re-issued. Yet it was one of the most complex processes to support.
It turns out the billing & data team had also come to the same conclusion. There are things they have to be aware of and features in the UI they need to enable reissuing to happen. Alternatively, they can just call SSCL and request they reissue the bill from SOP.
Because of this, they've held off asking us to enable the feature.
So, it has been more than 6 months and reissuing still hasn't been enabled in production. In that time we've made many other changes where we've disregarded reissuing to avoid needless complexity and our belief a decision will be made never to enable it.
Should that assumption be wrong we'd need to make a suite of changes to support it, for example, in how we display things in the billing views. We are making a series of updates to the supplementary billing engine to implement the improvements we implemented in SROC annual billing. That refactoring is a prime opportunity to silo the reissuing from the engine and the complexity it adds.