-
-
Notifications
You must be signed in to change notification settings - Fork 824
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
Fix bug where tax_amount is miscalculated on membership renewals #16772
Conversation
(Standard links)
|
ee49b13
to
765c501
Compare
@@ -89,6 +89,7 @@ public function setUp() { | |||
'fixed_period_start_day' => '101', | |||
'fixed_period_rollover_day' => '1231', | |||
'relationship_type_id' => 20, | |||
'min_fee' => 100, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually this didn't seem to 'work' & the underlying is still set to 0 - since we are testing overrides that is OK for now
ping @JoeMurray @monishdeb @petednz @stesi561 I think you all have interest in this I think |
Yes - also @mattwire & @pradpnayak & @jitendrapurohit - since there is a code approach change in here |
Test fails look like leakage - Test Result (3 failures / +3)
|
76844ce
to
db2a8d3
Compare
In order to replicate 1) enable tax & invoicing 2) configure a financial type with sales tax 3) renew a membership, entering an amount other than the default membership amount. 4) view the membership - tax amount will be the same as it would be if the default amount had been used. Tangental bugs I noticed 1) regression in master on adding financial accounts - I will do a separate PR 2) tax term not assigned to the template - out of scope for now but I believe a pre-hook type structure should exist, assigning this to the template when enabled (as part of moving some code to a core-extension). 3) the form shows the tax amount & does not update it - this is pretty big already so that is also out of scope for now This bug affects both membership & membership renewal pages. This PR only fixes for membership renewal but the goal is to fix for membership too once this is merged. It is a fairly 'bug' fix in that it introduces a new class with new methods to get the information otherwise provided by CRM_Price_BAO_PriceSet::processAmount. processAmount is one of those functions that is hard to read and understand & has been hacked to do various things. Code that calls it is hard to read because of this. Having a cleaner way to operate has been a goal for a while. We have plans to build up the Order api to be much more usable and used. However, we really need to build up sensible helpers before we can address that. This PR adds a class that has a whole lot of functions that are more readable to do what the processAmount otherwise does. The goal is to deprecate processAmount. I started on MembershipRenewal as 1) it has a bug currently and 2) it is pretty simple in that it doesn't actually support pricesets - which is especially helpful when testing :-)
db2a8d3
to
7aa7890
Compare
Thanks @mattwire I've addressed the things you tested |
@monishdeb I'm keen for you to look at this PR - it's hopefully the start of a readability improvement across a few forms |
I will, thanks for pointing this out. Added in my todo list as it will need me some through review . |
@@ -453,9 +453,9 @@ protected static function getPriceSetID($params) { | |||
$priceSetID = CRM_Utils_Array::value('price_set_id', $params); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@eileenmcnaughton You'll need a rebase. this is now $priceSetID = $params['price_set_id'] ?? NULL;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't seem stale yet below?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I can fix after if need be)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could not apply the patch without editing on master. I am surprised this PR does not show that it has conflicts - could be me.
@eileenmcnaughton I did an I can reproduce the error and the fix does exactly what you describe. I did notice that we have an issue when you view the contribution: But that is unrelated to this PR. It does bother me that the admin tax calculation is still wrong, if the total amount is $50 the tax should be 4.55 and the fee is 45.45, but as you say this is consistent with the current behavior so out of scope. |
@kcristiano that view error is the taxTerm not being assigned to the template. I've been mulling it a bit. I think the taxTerrm should either be
I go back & forwards a bit here as I don't think 'tax and invoicing' is a logical combo. To enable tax you need to create other things as well as that (configure accounts) & my gut says the 2 are not tightly linked . |
@eileenmcnaughton I agree my comments should not be a blocker to merging. I think this is better in and we will have time to test and add on other improvements. |
Overview
Fixes a bug where tax amount is incorrectly calculated when the total amount is not left at the default on the membership renewal page.
This bug affects both membership & membership renewal pages. This PR only fixes for membership renewal
but the goal is to fix for membership too once this is merged.
Before
In order to replicate
After
Correct tax calculation - total_amount = $50, tax_amount = $5, line_total = $45 - this is consistent with contribution page overrides
Technical Details
This is a fairly 'big' fix in that it
introduces a new class with new methods to get the information otherwise provided by
CRM_Price_BAO_PriceSet::processAmount. processAmount is one of those functions that is hard to read
and understand & has been hacked to do various things. Code that calls it is hard
to read because of this. Having a cleaner way to operate has been a goal for a while. We
have plans to build up the Order api to be much more usable and used. However, we really
need to build up sensible helpers before we can address that. This PR adds a class
that has a whole lot of functions that are more readable to do what the processAmount otherwise
does. The goal is to deprecate processAmount.
I started on MembershipRenewal as
helpful when testing :-)
Comments
Tangental bugs I noticed
structure should exist, assigning this to the template when enabled (as part of moving some code to
a core-extension).