Details
-
Type:
Bug
-
Status: Done/Fixed
-
Priority:
Trivial
-
Resolution: Fixed/Completed
-
Affects Version/s: 4.6.13, 4.7.2
-
Fix Version/s: Unscheduled
-
Component/s: CiviContribute
-
Versioning Impact:Patch (backwards-compatible bug fixes)
-
Documentation Required?:None
-
Funding Source:Needs Funding
Description
Number precision or rounding causes the displayed tax exclusive amount to be out by 1c. Trying to have the Event fee of $115 tax inc. results in CiviCRM displaying $114.99 tax inc. as fee.
Steps to reproduce:
1. Set up a Tax rate of 10% (GST)
2. Create an Event and set the price to be 104.54 ex. tax.
3. The required tax inclusive amount i $115.
4. CiviCRM will then display the Event fee as $114.99
However, if you calculate this it should be:
1. Tax exclusive amount, 104.5454545455
2. 10% tax amount, 10.4545454545
2. Tax inclusive amount, 115
It seems a simple solution of either rounding up to the nearest 0.5c would solve the issue. Australia has done away with 1c, 2c and I expect the 5c is going that way too!
Agileware Reference #24197
Attachments
Issue Links
- supplements
-
CRM-19585 Sales tax issues
-
- Done/Fixed
-
Activity
Rough estimate 1-2 hours.
Agileware Do you want core team to start work on this?
Tricky: 104.54×1.1=114.994, 104.55×1.1
=115.005. So rounding is working correctly.
Yashoda, I'm not clear that rounding to nearest 5 cents should be in core...I'd prefer extension. And I think we should do some cleanup of how taxes are calculated. Currently there is a bunch of business logic in .tpl ( https://github.com/civicrm/civicrm-core/blob/master/templates/CRM/Contribute/Form/Contribution.tpl#L645) that replicates logic in php on server in order to improve UX. I'm wondering if @eileen would prefer that to be a callback to server in order to have single authoritative place for calculation to improve maintainability even at cost of UX degradation.
> Currently there is a bunch of business logic in .tpl
Wow. I thought it was bad enough that there was business logic in the form code. I didn't realise there was some at the .tpl level as well...
But I think you've hit the head of another nail there as well where fundamentally the fact that our end-users are required to enter tax-exclusive amounts (which here in Aus is an unusual way to think when setting prices and is almost unheard of when displaying them) means that certain prices points just cannot be used.
I'm not sure you're going to like this, but I think the proper approach to fixing this is to add support for tax-inclusive amounts, which is a big job. It would best be combined with refactoring sales taxes out into an extension, and then providing either different plugins to the extension or supporting both tax-inclusive and tax-exclusive prices in the same extension. Eileen McNaughton KarinG comments?
Ok - I'm curious - going to try reproduce this issue.
Bigger picture: yes to LexIm-ing sales taxes -> 1.0 should be sales taxes as is [without new features] -> 2.0 could be tax-inclusive/exclusive. That's a really complex problem. Drupal Commerce 2.x finally seems to be doing that ok now.
Ok just reviewing this as I'm going through a couple of JIRA issues - the issue here is identical to: https://issues.civicrm.org/jira/browse/CRM-16656 - and the resolution would be the same [as you also noted above]: a new feature request that would support tax-inclusive in addition to tax-exclusive - something that would have to be done in an extension - and in the process could take all (if not most) of sales tax math out of core.
Closing per Karin's comments - looks like we need to treat this as a feature request & aim for an extension-based fix
Possibly related
CRM-16656