Easy-digital-downloads: 3.0 - Reports: Tax report does not display any data related to 'global' tax rates, just tax regions.

[cklosowski]

Bug Report

Expected behavior

When I have a global tax rate (not a region specific one), I expect the report to show how much tax revenue was collected for it.

Actual behavior

Only region based tax rates are ported specifically.

Steps to reproduce the behavior

1) Enable a fallback tax rate
2) Make a purchase using address information that does not use a specified tax rate, but falls back to the global tax rate.
3) View tax reports, only region specific taxes will be shown in the table.

Information (if a specific version is affected):

PHP Version: All

EDD Version (or branch): release/3.0

WordPress Version: All

Any other relevant information:
Another way way to replicate is to use WPCLI to generate a large number of orders when you have a global tax rate enabled. Since the CLI integration does not supply address information, it will use the fallback.

[JJJ]

I would like propose one solution to this problem, that I think addresses everything pretty nicely.

Let's turn the default tax rate into an actual tax rate, saved along side the others using some default type naming delimiter.

The process to complete this task looks something like:

1. Add a tiny migration script to migrate existing edd_settings[tax_rate] values into a new row in the edd_adjustments table
2. Remove the default tax rate option and key from edd_options
3. Add some code to re-route anyone trying to save edd_settings[tax_rate] into the new storage method
4. Add a new edd_default_tax_rate_id option key to edd_options as an external identifier
5. Add the above option key into the queries we use to populate the "Regional Rates" setting, to ensure it never appears in the list table(s)
6. Handle the new default row in the edd_adjustments database table using edd_add_adjustment() and friends

Things to consider:

1. EDD\Compat\Tax may require some back-compat tweaks
2. We'll need to omit this row from everywhere the default rate is undesirable, including (and primarily) reports, but also any other areas that come up

---

I think by doing it this way, we are able to do a few neat things that haven't been possible:

1. Store the global tax rate used with the orders and items that use it, just like any other tax rate
2. Run accurate reporting for only the default rate
3. Exclude default rate(s) from regional ones

[SimonChaw]

Hey there,

I took a crack at this. I upgraded using WP CLI so I'm not sure if I missed any testing points. I didn't have issues so I didn't make any changes to EDDCompatTax. Please let me know if I missed anything.

Reporting Table

Tax settings

Thank you!

[pippinsplugins]

Overall the approach in the PR above looks pretty good but there's a problem right now. If you try and enter a default tax rate on a brand new install, an infinite loop gets triggered and dozens or hundreds of tax rates end up getting created.

[pippinsplugins]

I've made a new PR based off of the work @SimonChaw submitted already. It is now mostly working but after getting it working I realized something that makes me want to change tracts.

The default tax rate is, frankly, dumb. While I probably shouldn't say _no one_, I am going to say it anyway. No one uses it because the setting simply doesn't make sense.

Tax rates are inherently by their very nature tied to locations. The idea of a global rate that applies to _everyone_ is flawed and only exists because that's how the really, really early version of EDD introduced support for collecting taxes tax. We only have a default tax rate because EDD used to only support a single tax rate period. But we've had support for multiple tax rates for years and they are really the only implementation we ever see used.

I'd like to propose that we, instead of fixing this, remove the default tax rate entirely. It fixes the problem, reduces complexity, and lessens the likelihood of an improper configuration by a store owner.

[JJJ]

I'd like to propose that we, instead of fixing this, remove the default tax rate entirely.

I am +1 this, but believe the right thing to do is to provide backwards compatibility for the folks that have set this up for their sites.

I suspect the reason people use this rate is because they simply do not know what to charge, or didn’t want to do the extra work of setting up tax rates for so many different regions, and are applying a blanket rate to everyone as a failsafe.

Or… we could package up back-compat for this as an add-on, maybe similar to the steps I outlined earlier, and pull the default rate from 3.0 onwards?

[cklosowski]

I'm :+1: for the idea of removing the setting, but we'll need a notice or something in the event they have a default tax setting configured. That way we don't catch them off guard when no taxes are being collected.

While a blanket failsafe is ok, it's likely incorrect, so I don't think the setting truly 'helps' anyone, unless they are using that tax rate as some sort of 'fee' or 'upcharge' and just renaming all the references to it being a tax rate...in which case we can't do much about that.

We'd also need to make sure all other plugins/extensions aren't looking for a default tax rate as they are doing post-processing of data after we've applied it to the cart/order.

[pippinsplugins]

Closing this as invalid and working from the newly created issue https://github.com/easydigitaldownloads/easy-digital-downloads/issues/7511

[cklosowski]

I'm not sure we should fully close this though. We should have some sort of way to report on the taxes collected on the default rate, prior to it being removed, or find a way to leave a notice that this only accounts for tax rates that specific to a country and/or reigon.

[pippinsplugins]

@cklosowski hmmm, that's true. Re-opening.