DragonflyCMS Projects > Storez > [fixed] Storez Orders with 0 Tax > Community Forums > Phoenix Netology
Forum Index > eCommerce > Storez

[fixed] Storez Orders with 0 Tax Reply to topic


I'm getting a few orders with 0 (VAT) tax. But not all orders, some are correct, so tax must be set up correctly.

After some digging I can reproduce. On Checkout Shipping Info screen complete fields manually (not using Use Account) and DO NOT select a Country. System will come back with 0 tax (because it does not yet know the country) and ask for Country to be completed. When you select a Country the tax remains at 0. I.e. tax is not recalculated following a data entry error on Ship Country. (Similar issues of wrong tax value also appear to occur if you change the country after your first entry.)

This occurs on my modified 9.3.6 - although I did not change anything in this area that should affect Tax. Not had chance yet to test on vanilla 9.3.6 or 9.4.1, but I will. Although looking at code of all 3 versions, I couldn't see any differences in calls to update_tax-cost.

I tried to test on your demo Storez site here, but I was unable to figure out which country did have tax set up, to test with. So I couldn't get a non-0 tax value to start from. (Your demo store looks to be set up as a USA based store, but without knowing which State it is meant to be based in, I couldn't make it taxable - which is State-based in US.) But setting the order to ship to USA, then changing to ship to AUS didn't seem to affect the shipping cost...)

Initiated by Bugger (Original Entry) - Comments Here Please.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux/2.2.8/5.1.73/5.4.21/9.4.0


Sorry, but further investigation following another 0 tax case, has led me to a root cause.

It is true that entering Shipping address via Use Account will always calculate tax correctly.

But filling in shipping address manually, even correctly, can still cause tax to not be calculated in the following conditions: Only 1 shipping method - in my case 'Flat Rate' of 0.00 (ie free shipping) - is active. With free shipping I only needed Flat Rate so deactivated all the others. The effect seems to be that no Shipping Method screen is displayed, and consequently, no shipping or tax is calculated.

My immediate workaround is to re-activate 'Base Rate' (also at 0.00) and force the user to select 1 of these 2 (equal) choices. This gets shipping and tax calculated every time.

Any suggestions on a way around this? TIA!

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux/2.2.8/5.1.73/5.4.21/9.4.0


I'm in process of upgrading from modified 9.3.6 to 9.4.1 - a non-trivial task Wink

But I have got far enough to have tested the above. I like all the changes I see, error handling etc, looks much better, whole thing looks more "approachable".

However the above bug still exists. If only 1 of Base Cost or Flat Rate shipping is Activated, then the Shipping Options screen does not display, and Tax is "calculated" at $0. As long as there are 2 or more shipping methods, even if effectively identical, then the shipping options comes up and the tax is calculated correctly.

Any fix - or guidance to fix - for the above, please?

Seems a shame to have to make users pick between 2 free options unnecessarily.

I tried the new Free Shipping option to evaluate as possible work around. But that seems to have a worse problem. If Free Shipping is set to yes (even when Base Cost and Flat Rate are both Activated and both already 0) then in checkout the Billing Options, Shipping Method and Payment screens are all skipped. No tax is mentioned on the invoice. The uncollected amount is listed, and a note displayed "Details for access to your free product(s) have been emailed to you." And the Notification email says "Payment Method: Free", while listing the product cost at $30. Free Shipping = Free (Instant Download?) Product?

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux/2.2.8/5.1.73/5.4.21/9.4.0


hmm, almost 2 months since I worked on this - will take some time to re-acquaint myself after such a long time.

I cannot consider issues from versions prior to 9.4.1, so will only be considering the last of your 3 posts.

On that basis, you appear to have 2 issues:
1. calculation of taxes on a non-free product - it currently charges taxes on the product itself and appears to do it correctly.
2. product with free shipping not processing correctly, which I can confirm.

In any event, I need to review how taxes are done - currently they are calculated on the basis of destination which is not necessarily correct.
e.g. In Australia, I am not required to pay a tax on overseas sales, but am required to pay tax on local sales. By the same token, I don't expect to pay VAT for UK purchases I make from Australia.

DonationsPro for vBulletin, SMF, MyBB, DragonflyCMS

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):


Phoenix wrote
hmm, almost 2 months since I worked on this - will take some time to re-acquaint myself after such a long time.

I cannot consider issues from versions prior to 9.4.1, so will only be considering the last of your 3 posts.

No problem.

Phoenix wrote
On that basis, you appear to have 2 issues:
1. calculation of taxes on a non-free product - it currently charges taxes on the product itself and appears to do it correctly.


Even if you disable all but 1 shipping method? In my case is was a Base Rate (or a Flat Rate) of $0.00, but doubt that the $0.00 was the cause, as adding back a 2nd shipping method at $0.00 restored everything to correct execution. (Lack of 2nd shipping method caused the shipping method selection screen to be skipped, and seemed to skip calculating tax too as a result.)

Phoenix wrote
2. product with free shipping not processing correctly, which I can confirm.

In any event, I need to review how taxes are done - currently they are calculated on the basis of destination which is not necessarily correct.
e.g. In Australia, I am not required to pay a tax on overseas sales, but am required to pay tax on local sales. By the same token, I don't expect to pay VAT for UK purchases I make from Australia.


I can't speak to Australia. But in USA the ship to address defines the tax rate as it varies (accumulatively) by State, County, City (and even Parish in parts of FL). But tax is collectable if and only if the vendor has a bricks-n-mortar operation it the state I'm shipping to. So for a typical Storez user this would only be the state in which the store operates, and would probably get away with just charging State tax unless high turnover items/total. (Tax is liable in all cases, but out-of-state and it is left to the buyer to pay to their local state on the honor system at tax time. Honest! Wink ) In UK, tax is collectable if shipped within EU, each at the respective VAT rate for the member state. No tax if shipped outside EU. Note that shipping charges are liable for VAT.

So taking your last example, it works I think. I create a tax rate for each country that I collect tax against (at least UK, and should do for all EU, except for moment only selling product for processing UK-specific gift taxes), and not for other countries, so if you order for Australia there is no tax rate defined, so I would expect tax to compute to 0.

(Sorry for delay in responding, but ForumsPlus still doesn't seem to send notifications, although I do get them from other parts of nukebiz.)

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux/2.2.8/5.1.73/5.4.21/9.4.0


Hi all, just thought I'd post this as it may help. I got around the above by adding the line:

$checkout->update_tax_cost();

after the lines

}

$checkout->update_shipping_cost();

$checkout->update_handling_cost();

at line 574 in modules/Storez/checkout.php.
I needed to have a 0.00 flat rate on all items except for a few heavy items which have a handling fee of £5.00 ( entered manually per item in handling charge)
Also the option 'Free Shipping' = No on all items, and only flat_rate (0.00) activated as a shipping method.
Cheers

John

PS and running on it on nginx 0.7.65 so no Apache verison

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Debian 5.0/nginx/MYSQL 5.05/PHP 5.2.13/9.4.1


Thanks, John.

I was slow getting to it, but it fixed the issue perfectly! Appreciate your posting.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux/2.2.8/5.1.73/5.4.21/9.4.0

All times are Australia/Adelaide


Jump to: