Attribute Value Based Tax Rules Disappear Between Checkout and Review [#600892]

Hi all,

There appears to be a fairly big bug in the way attribute value based tax rules are implemented between the checkout and review pages.

After some quite intensive testing (and tears) I am fairly confident to say that the checkout and review pages seem to do the exact opposite to each other and it appears to be the logic on the review page which is wrong.

If you have a tax rule that should be applied only if a product in your basket has a specific attribute selected the checkout page always seems to calculate it 100% correctly. However the review page doesn't show the additional tax line if it should but DOES show it if it shouldn't.

I've checked the logic behind my rule a million times and it's watertight - backed up by the fact the checkout page is showing it fine.

I'm fairly new to Ubercart so I may be missing something obvious but I'm really not sure if there is a reason for different logic to be in use on the checkout and review pages - surely there's a lot of code duplication?

Anyway - any help more than greatfully received!

Thanks
Krix

Ps. A little extra information I only upgraded to rc7 today to test as I thought rc5 was the problems but no such luck. It seems to do the same in both.

Comment	File	Size	Author
#16	721412-uc_attributes-order_contains_attribute.patch	1.04 KB	neclimdul
#16
#8	600892-ubercart-uc_attribute-calculate-ca.patch	1.64 KB	mrfelton
#8
#7	600892-ubercart-uc_attribute-calculate-ca.patch	1.14 KB	mrfelton
#7
#3	600892_attribute_condition.patch	1.46 KB	Island Usurper
#3

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

pompeydrupal CreditAttribution: pompeydrupal commented 14 October 2009 at 21:10

Is anybody able to direct me to the files/functions that handle the taxes in the checkout and review pages so that I can see if I can fix (hack) this myself?

Comment #2

Island Usurper CreditAttribution: Island Usurper commented 20 October 2009 at 17:39

Priority:	Critical	» Normal
Status:	Active	» Needs review

I believe this patch fixes the behavior of the attribute condition.

I'm bumping this issue down from critical because fixing this particular problem isn't going to end up making Ubercart do what you want. This is because the conditions only specify whether or not the tax is applied to the order. The tax itself doesn't make a distinction between products' attributes. That means if someone adds a product with option A and a product with option B to their cart, the option A tax will be applied to both products.

You can have taxes filter products by content type and by whether they are shippable. Any more granularity just isn't possible at this point, and adding it to the tax module is another issue, which will happen in the next major version of Ubercart, probably.

Comment #3

Island Usurper CreditAttribution: Island Usurper commented 20 October 2009 at 17:39

File	Size
600892_attribute_condition.patch	1.46 KB

And I totally forgot to attach the patch.

Comment #4

pompeydrupal CreditAttribution: pompeydrupal commented 21 October 2009 at 16:12

Status:

Needs review

» Needs work

Thanks Island Usurper.

Have tested this but it doesn't appear to have solved the issue. With that patch applied the tax is never applied on the checkout page but the review page is working correctly?

Will test further tonight but it appears to have (almost) reversed the issue.

Krix

Comment #5

pompeydrupal CreditAttribution: pompeydrupal commented 2 November 2009 at 21:22

Island Usurper,

Is this issue something you will be able to look into?

Ta
Krix

Comment #6

pompeydrupal CreditAttribution: pompeydrupal commented 25 November 2009 at 16:53

Hi - You may as well mark this bug as "won't fix" as it doesn't look like we are going to get a solution.

Comment #7

mrfelton CreditAttribution: mrfelton commented 27 February 2010 at 13:41

Version:	6.x-2.0-rc7	» 6.x-2.x-dev
Status:	Needs work	» Needs review

File	Size
600892-ubercart-uc_attribute-calculate-ca.patch	1.14 KB

Try with this patch (applies to latest code in CVS).

Comment #8

mrfelton CreditAttribution: mrfelton commented 27 February 2010 at 14:20

File	Size
600892-ubercart-uc_attribute-calculate-ca.patch	1.64 KB

ok... got it. The above patch does work in some situations, but not all. The problem is once the order is made, the attribute data is changed to just the labels - Not the names... So, with the above patch, if the label happened to be the same as the name then it would work.

This version of the patch checks if the attribute is present in the order by comparing the label rather than the name, and it works in all cases! It would surely be better to check the attribute ID, but that would require a much more major rework of how the attribute data is attached to the order.

Comment #9

TR CreditAttribution: TR commented 1 March 2010 at 07:51

I'm willing to commit it if some people test it to confirm it solves the problem.

Comment #10

UNarmed CreditAttribution: UNarmed commented 1 March 2010 at 10:36

Im giving it a test now, realy hope it does the trick =D

Comment #11

UNarmed CreditAttribution: UNarmed commented 1 March 2010 at 10:43

Great!! Thanks mrfelton it did the trick! The patch at #8 worked for me =D im going to keep testing it but so far so good.

Comment #12

Maikel CreditAttribution: Maikel commented 23 March 2010 at 15:44

Am giving it a test too. Will report back as soon as possible.

Comment #13

bisonbleu CreditAttribution: bisonbleu commented 7 July 2010 at 15:16

Discovered this morning that orders were being processed on PayPal without a fee I had setup... :-(

I have set Submit the whole order as a single line item. (admin/store/settings/payment/edit/methods)
I have applied the patch in #8 on Ubercart 6.x-2.2
Did a test : the fee is now included in the PayPal Total. Great!

Is step "1" still required?
Should I have applied the patch to 6.x-2.x-dev instead?
I usually don't use dev versions unless I really have to.

Kudos to mrfelton & all !

Comment #14

shinz83 CreditAttribution: shinz83 commented 9 August 2010 at 18:53

How do I apply this patch?

Comment #15

shinz83 CreditAttribution: shinz83 commented 9 August 2010 at 18:54

How do I apply this patch?

Comment #16

neclimdul

He/Him

CreditAttribution: neclimdul commented 9 August 2010 at 21:41

File	Size
721412-uc_attributes-order_contains_attribute.patch	1.04 KB

After some deep digging, it looks like the problem with this code is it only works for select and maybe radio display types. If you choose checkboxes it blows up. This is because when you choose checkboxes, options are grouped in the attributes array by attribute ID. This was sort of discovered in #721412: "Condition: Order has a product with a particular attribute option" is broken and is basically what Island Usurper did in #3. The attached patch deals with both cases, at least before things are converted to labels. I'm not sure if the same is still true when the second section of code is triggered. Does anyone have a test case that I could use to test that part of the code?

Comment #17

shinz83 CreditAttribution: shinz83 commented 10 August 2010 at 19:14

The only workaround for charging tax based on type of payment (personal or nonprofit credit cards/checks) tax issue is changing the Tax Conditional Actions to "Check an order's billing postal code" and then having it negate taxes when the customer types the word "exempt," which triggers the taxes to be taken off the order.

This method is shabby at best. Would love to have "based on attribute option selected from array" or something like that - rather than just having the attribute present.

Not only is it shabby, but it depends heavily upon the honor system. Meaning that those people paying with a personal credit card or check have to be respectful enough to not enter "exempt" in the field.

The great experiment continues!

Comment #18

TR CreditAttribution: TR commented 11 August 2010 at 23:41

The only workaround for charging tax based on type of payment (personal or nonprofit credit cards/checks) tax issue

Hmm, that's not the subject of this thread, is it? And the method you describe is "shabby" because it's the wrong way to do it - it's *your* idea you're criticizing. Please keep to the subject. If you want to discuss a different topic open a support issue, preferably on ubercart.org.

Comment #19

shinz83 CreditAttribution: shinz83 commented 12 August 2010 at 15:37

It is not 'exactly' what this thread is about. However, it is a quick and dirty solution to the problem at hand. I thought other individuals might need a quick solution until a solution is actually posted. Perhaps I'm violating the sanctity of the drupal forums. If that is the case, I heartily apologize.

Comment #20

neclimdul

He/Him

CreditAttribution: neclimdul commented 12 August 2010 at 16:36

This isn't the forums but an issue. It actually doesn't workaround the problem except in certain circumstances.

That said, anyone want to review the patch and see if it /actually/ fixes the problem?

Comment #21

shinz83 CreditAttribution: shinz83 commented 12 August 2010 at 17:39

I will test it in September when the current registration on my site closes. I'm looking forward to testing it. Thanks for putting it together.

Comment #22

sunward CreditAttribution: sunward commented 20 October 2010 at 05:47

I am having the problem of the fee showing in the checkout pane, when calculating shipping costs. It doesn't get passed to REVIEW ORDER or to paypal. It is not a tax but a flat fee if certain products are ordered.

Has the patch been committed? Should it be used?

Comment #23

sunward CreditAttribution: sunward commented 11 November 2010 at 21:39

patch in #16 fails. I have a fee based on what is in the cart. When the patch is applied, some of the actions do not get implemented and the fee is not added in the checkout section. Incorrect shipping quotes are returned.

Comment #24

interestingaftermath CreditAttribution: interestingaftermath commented 12 November 2010 at 15:15

subscribing

Not sure if this is related but maybe, just maybe it will contribute to the resolve of this issue: #968532: Free Shipping for specific Product Attributes - Weird Shipping Issues

Comment #25

shinz83 CreditAttribution: shinz83 commented 2 December 2010 at 15:02

None of the patches worked for me. What's worse is that they changed the attributes on the products to the admin label rather than the cleaned up version.

This is a major issue for ubercart.

Our situation is this:

As a nonprofit, we can offer tax free registrations to other nonprofits, but not to individuals. With this in mind, we need to have an attribute on the product that designates whether or not they will be paying from an individual banking account or with a nonprofit banking account. When one is checked - it should trigger or not trigger taxes.

I can get the taxes to appear properly on the checkout pane, but when we go to review order.... the taxes appear when they shouldn't.

What is being lost from checkout to review?

Comment #26

longwave

he/him

English

CreditAttribution: longwave commented 19 January 2011 at 11:17

Please try the patch in #721412-9: "Condition: Order has a product with a particular attribute option" is broken which (fingers crossed) solves this issue and a related issue in the same function where checkbox attributes are incorrectly handled.