[Done 155b] Shipping tax not added in order confirmation - possible bug??

mmcculli:

I have moved the line down and it seem to have worked. Taxes on Shipping are now showing up as they did before I upgraded to 1.5.5a. So this very small change looks to have fixed the issue.

So what are the side-effects of this change?

Hi

Currently hoping there aren't any. I updated our functional test suite recently, just to test this. The changes did not break any of the tests relating to tax calculations.

I am not really sure of your internal process with bugs. I assume you need to run the change through some regression test units. So do I wait for an official patch or will you just reply to this thread if it looks ok for me to move live.

At this point our internal tests are showing no obvious ill side effects.

If it were my site I'd go live with it now ... and keep a careful eye on order traffic and any errors in the /logs/ folder, etc.

Maybe this could/should be added to the "Known Bugs (and fixes) with v1.5.5" tread, so people know why the have tax issues?

rued:

Maybe this could/should be added to the "Known Bugs (and fixes) with v1.5.5" tread, so people know why the have tax issues?
Are you saying you've been encountering this same issue yourself?

Several people have, including me on several sites, yes.
Have disabled most countries and turned of zone restrictions for now in a few sites, but most are pending updating because of this bug.

rued:

Several people have, including me on several sites, yes.
Have disabled most countries and turned of zone restrictions for now in a few sites, but most are pending updating because of this bug.
I wish I could reproduce it. Particularly because I want to understand why it wasn't an issue in v154, especially since the code in the proposed fix didn't change between versions.

Beyond reproducing it I'd be even more interested in knowing exactly what's caused the change between versions.

Oh, I'll make you a test site then, after my holiday - or on a rainy day. :)

Hi all,

I can confirm the same issue happened to me upgrading from v1.5.1 to v1.5.5a. I thought I had corrupted something, but then found this post. I turned off the zone on the shipping module as suggested by Ajeh and it started to work as expected. So I've just implemented Dr Byte's suggested code change and all working again with a zone specified in the shipping module. I'll update you all if there are any logs or side effects appearing.

Thanks!

Hi all,

As an update to the fix DrByte mentioned. It works fine for my worldpay payment, however when a customer pays 'on account' using the invoice mod from the add ons the shipping is once again calculated without tax on the shipping. I can rectify the issue by removing the zone from the shipping module again.

Is anyone else able to re-produce this error?

It is worth noting that the invoice mod is only officially compatible with v1.5.1, however I can't see where in its code it would effect the shipping tax? And if it happens with this payment add on, how many others may be affected?

If anyone else could offer any ideas, they'll be much appreciated.

Thanks all!

bottyz:

however when a customer pays 'on account' using the invoice mod from the add ons the shipping is once again calculated without tax on the shipping. I can rectify the issue by removing the zone from the shipping module again.

This one: https://www.zen-cart.com/downloads.php?do=file&id=131 ?

What happens if you change:

function invoice() {

into:

function __construct() {

I don't see what else should be changed in this for 1.5.5, as it doesn't have any zone handling?!

Just completed another upgrade from 1.5.4 to 1.5.5a for a client.

He had that store going for many years without tax issues - until up and including ZC 1.5.4.

Now, after upgrading to 1.5.5a, the tax was added correctly during the checkout process but was NOT added at the checkout_success page, the order confirmation email and the invoice.

Applied Dr Byte's fix (post #59) and we are back to normal, the shipping tax now shows correctly on the checkout_success page, the order confirmation email and the invoice.

So, that adds another (upgraded) store showing the same symptoms as I reported in post #1

So, from the reports of others, this symptom only seems to appear in upgraded stores. If one of the upgraders made a mistake in the upgrade then that would be understandable. But, it seems to happen in many upgraded stores as reported here in this thread and it is unlikely that the many different upgraders are making exactly the same mistake.....

On the other hand, in Wilts's and DrByte's vanilla 1.5.5a installs (ie trying to reproduce the error in a fresh installation) the symptom does not appear.

So, why the difference in symptoms between an upgraded store and a fresh installation?

Suggested "test" would be to install a fresh earlier version of ZC for a version that didn't report the issue, setup with conditions that appear to be causing the issues and then attempt to upgrade and see if the problem persists.

If the problem exists with that upgrade, compare database dumps of both a fresh install of 1.5.5a and that upgrade. If not, then unfortunately attempt the same database compare between a troubled upgraded cart and fresh ZC 1.5.5a...

mc12345678:

Suggested "test" would be...

+1 to it all ... :)

mc12345678:

Suggested "test" would be to install a fresh earlier version of ZC for a version that didn't report the issue, setup with conditions that appear to be causing the issues and then attempt to upgrade and see if the problem persists.

If the problem exists with that upgrade, compare database dumps of both a fresh install of 1.5.5a and that upgrade. If not, then unfortunately attempt the same database compare between a troubled upgraded cart and fresh ZC 1.5.5a...

Yep, agreed! The starter could be a 1.5.1 or a 1.5.3 version and then upgrade progressively from version to version.

Did some digging.....

In includes/classes/shipping.php

ZC versions 1.5.1 and 1.5.4 we find around line 144

```

$this->notify('NOTIFY_SHIPPING_MODULE_GET_ALL_QUOTES', $quotes_array);

and in the same (corresponding) file in ZC 1.5.5a around line 176

    ```
$this->notify('NOTIFY_SHIPPING_MODULE_GET_ALL_QUOTES', $quotes_array[B], $quotes_array[/B]);

Is the duplication of , $quotes_array in the 1.5.5a file intended?

frank18:

Did some digging.....

In includes/classes/shipping.php

ZC versions 1.5.1 and 1.5.4 we find around line 144

```

$this->notify('NOTIFY_SHIPPING_MODULE_GET_ALL_QUOTES', $quotes_array);

> 
> 
> and in the same (corresponding) file in ZC 1.5.5a around line 176
> 
>     ```
$this->notify('NOTIFY_SHIPPING_MODULE_GET_ALL_QUOTES', $quotes_array[B], $quotes_array[/B]);

Is the duplication of , $quotes_array in the 1.5.5a file intended?
Yes, intended. And, unless you're actually using something that gets triggered by that notifier hook, it wouldn't be affecting your shipping. let alone taxes

DrByte:

Yes, intended. And, unless you're actually using something that gets triggered by that notifier hook, it wouldn't be affecting your shipping. let alone taxes
To clarify, the duplication enables backwards compatibility (keeping the $quotes_array as the first, read-only, parameter) but also adds the capability for an observer to *modify *those values by supplying the second (updateable) parameter containing the $quotes_array.

rued:

This one: https://www.zen-cart.com/downloads.php?do=file&id=131 ?

What happens if you change:

function invoice() {

> 
> into:
> ```
function __construct() {

I don't see what else should be changed in this for 1.5.5, as it doesn't have any zone handling?!

Hi Rued,

Sorry for the late reply (I was on holiday in Turkey), and thanks for your help. I found the issue and it wasn't anything to do with the invoice mod. It actually turned out to be a problem with the wp_checkout_proccess.php file with the worldpay module.

The above file is mostly a duplicate of the first part of the checkout_process.php file, which Dr Byte has suggested needs the shipping / order lines swapping round. I've swapped these round in the worldpay file and all seems well.

Thanks again.