Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.One thing that has always bothered me is that when adding new taxes, they are immediately applied to orders until a condition is set. This is a pretty annoying usability-wise, because the user has to rush to set the conditions for the tax rate. Seems that the only way around this is to have the tax rate not apply to any product types initially - set conditions - and then go back and set what product types it applies to.
I couldn't find any other threads about this. Perhaps this is a "can't fix" type deal because of conditional actions?
Thanks
Comments
Comment #1
longwaveHow often do you add new tax rates, especially while a store is open?
Defaulting to applying taxes if no conditions are present is also the most intuitive way to deal with stores that only sell to one country; they are taxing unconditionally, there is no reason for them to need to specify any condition.
Comment #2
bkosborneNot too often, but it will certainly happen. For instance, once the client begins selling (physical goods) in a new state in USA, they need to tax those products that get shipped there for the online store, and add a new tax for that state.
I think this could be solved by adding an enabled/disabled field for each tax. But considering Ubercart is already matured, not sure how you feel about that.
It's just very difficult to explain to a client of a high-traffic store that if they add a new tax rule, it will apply to every order automatically until they are fast enough to add a condition to have it apply to just one state.
Comment #3
TR CreditAttribution: TR commentedThat's exactly what I thought of when I read the original post. We do this for quote methods: first define one or more flatrate and/or weightquote methods, then enable them separately on a page that lists these user-created methods as well as module-defined methods like UPS, USPS, etc. However, we don't have a similar mechanism for taxes. We should.
This will solve another problem as well. Now that we have hook_uc_calculate_tax(), which we didn't have when the tax rate UI was first defined, there's no one place that displays all the user-defined rates AS WELL AS all module-defined rates - the two cases are handled completely different. This would benefit greatly from using the same model we have with quotes.
Changing to a feature request, and changing to 7.x-3.x. Let's get it in D7 first then backport to D6.
Comment #4
TR CreditAttribution: TR commentedNew features need to go into 8.x-4.x at this point.
Comment #5
TR CreditAttribution: TR commentedAll the features I mentioned in #3 will be addressed in 8.x-4.x by #2672628: Convert TaxRate entities to use plugins.
Since there's been no community interest / participation in this issue for 4 years, there's no real incentive to backport the D8 changes (it would be difficult to do anyway), so I'm going to mark this as fixed in the current version but won't fix in D7.