CAPT 2121/expand topup functionality #3527
Merged
Conversation
This file contains hidden or 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
rjlynch
force-pushed
the
CAPT-2121/expand-topup-functionality
branch
4 times, most recently
from
d8529d0 to
a4af10f
Compare
asmega
approved these changes
Jan 27, 2025
Thanks, I checked that it doesn't change any of the old payrolls! |
rjlynch
force-pushed
the
CAPT-2121/expand-topup-functionality
branch
from
ce5a221 to
b5bb92c
Compare
rjlynch
force-pushed
the
CAPT-2121/expand-topup-functionality
branch
from
b5bb92c to
7d356df
Compare
We'll be making topups availble on all polices so we don't want any policy specific logic in the topup.
There was a bug in the previous payroll logic that couldn't handle the following scenario * Claimant paid for a claim (Claim A) in Jan payroll * Claimant paid a topup on Claim A in Feb payroll * Claimant paid for a claim (Claim B) in Feb payroll In that scenario the claimant would receive the topup payment twice as both Claim A and Claim B have the same payment and so when we joined claims to payments and left joined payments to topup both rows would have a topup, causing the coalesce to pick the topup amount.
Thankfully the original topup code used `Claim#topupable?` in most places so supporting additional policies was straightforward.
A requirement is to add a note to the claim when we add or remove a topup. We've introduced two form objects to handle generating the note and amending the claim's topups.
For policies that don't define a max award amount set £10K as the limit as per the comments on CAPT-2121.
Makes the topup form multi step with a confirmation screen. Once an admin has entered a topup amount we need to display a page to confirm the amount before we create the topup. We handle tracking the state by passing around a step param and using contextual validations. If all validations pass we consider the form complete and create the records. We use `dup` in the `complete?` method to avoid rendering errors for steps other than the one we're currently on.
rjlynch
force-pushed
the
CAPT-2121/expand-topup-functionality
branch
from
7d356df to
4f17404
Compare
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.
Allow topups for all policies
Probably easiest to review each commit separately, or at least the bug fix on
the payroll run.
Now we need to check the number of topups for each policy we make a few extra
trips to the db when showing the payroll run. I investigated caching the line
items and performing the policy filtering in Ruby which saves ~200ms but makes
the code harder to follow. Opted against including this in the pr as the page
loads in about 500ms, but something to bear in mind if we want a bit of extra
performance.