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

Just discovered a weird isue on a store upgraded from 1.5.4 to 1.5.5a with the shipping tax being correctly added in the front end (checkout pages) but the shipping tax is not added to the shipping charge in the order and the invoice.

Never noticed this until now since all other orders were over the free shipping limit of $150 hence no shipping is charged.

During the checkout process the shipping shows correctly at say $8.00 but the customer order confirmation shows $7.27 (tax is 10%, $7.27 excl + 10% tax = $8.00).

When I did the upgrade I uninstalled then re-installed the relevant Zones module and entered all values as they were in 1.5.4 - had no issues with the old ZC version. No other changes in the general tax setup has been made, same stuff now as it was in 1.5.4

No coupons, no nothing else involved........

So I double-checked the code for the zones module and it is exactly the same as in the install file set (bar the fact that it is a clone (always has been for years), all renamed from zones to zones4 in the clone). Also compared again various functions (general, prices, taxes) in the includes/functions folder to eliminate any merging errors. Order.php class is ok as well. No upgrading/merging mistakes made..... all looks as it should.

Bottom line is that I am stumped.

Could this be a bug??

Or am I missing something??

Thanks / Frank

I was going to place a bug report myself, but you beat me to it.
I was called by a customer yesterday, which i recently upgraded from Zen Cart 1.5.4 to Zen Cart 1.5.5a that in his shop the shipping tax is not calculated on the order confirmation page. The shipping module used, is the table module. In Zen Cart 1.5.4 this problem did not exist.
This is shown on the order_confirmation page
Attachment 16356
and this on the checkout_success
Attachment 16357
As you can see the shipping tax is missing.

The weird thing is when I use the zones module all goes well.
This is a store with almost no modifications, except for IH4, and mobizencart (mobile theme), but those have no effect on the check out process.

Tax settings are:
Attachment 16358

Serverinfo:
HTTP Server: Apache
PHP versie: 5.3.28 (Zend: 2.3.0)
Database: MySQL 5.5.44-0ubuntu0.12.04.1

I also tested on a vanilla install, and that gives the same result

Quote:

---

Originally Posted by Design75

I was going to place a bug report myself, but you beat me to it.
I was called by a customer yesterday, which i recently upgraded from Zen Cart 1.5.4 to Zen Cart 1.5.5a that in his shop the shipping tax is not calculated on the order confirmation page. The shipping module used, is the table module. In Zen Cart 1.5.4 this problem did not exist.
This is shown on the order_confirmation page....

---

Now that is interesting.... only diff is that I am using a Zones module.

It displays correctly on the order_confirmation page but is wrong in the order email and invoice, customer is also not charged any tax with whatever payment module they are using (PayPal, eWay, Direct Bank Deposit ... same issue).

My (local) server setup is

Server Host: arcturus (127.0.1.1)
Server OS: Linux 3.19.0-32-generic
Server Date: 26/05/2016 19:15:04
Server Up Time: Disabled/Unavailable
HTTP Server: Apache/2.4.7 (Ubuntu)
PHP Version: 5.5.9-1ubuntu4.17 (Zend: 2.5.0)
PHP File Uploads: On
Upload Max Size: 64M
PHP Memory Limit: 256M
POST Max Size: 64M
Database: MySQL 5.5.49-0ubuntu0.14.04.1
Database Host: localhost (127.0.0.1)
Database Date: 26/05/2016 19:15:04
Database Data Size: 33,769 kB
Database Index Size: 5,632 kB
MySQL Slow Query Log Status: On
MySQL Slow Query Log File: /var/lib/mysql/arcturus-slow.log



Slightly better on the live store (eg PHP 5.6 etc etc) other than that it is the same.

My tax setup is exactly the same as yours (and has been for yonkers without probs)

Store history is:
Zen Cart 1.5.5a

Database Patch Level: 1.5.5


v1.5.5 [2016-05-01 18:29:21] (Version Update 1.5.4->1.5.5)
v1.5.4 [2015-01-11 04:53:20] (Version Update 1.5.3->1.5.4)
v1.5.4 [2015-01-11 04:52:18] (Version Update 1.5.3->1.5.4)
v1.5.3 [2014-08-11 10:16:37] (Version Update 1.5.2->1.5.3)
v1.5.2 [2014-08-11 10:16:37] (Version Update 1.5.1->1.5.2)
v1.5.1 [2013-12-29 11:23:19] (Version Update 1.5.0->1.5.1)
v1.5.0 [2013-12-29 11:23:19] (Version Update 1.3.9->1.5.0)
v1.3.9c [2010-06-11 23:19:47] (Version Update 1.3.8->1.3.9c)
v1.3.9c [2010-06-11 23:12:13] (Version Update 1.3.8->1.3.9c)
v1.3.8 [2010-06-11 23:12:12] (Version Update 1.3.7->1.3.8)
v1.3.7.1 [2007-10-24 21:50:38] (Fresh Installation)
v1.3.7.1 [2007-10-24 21:50:38] (Fresh Installation)

Cheers / Frank

Quote:

---

Originally Posted by frank18

..... customer is also not charged any tax with whatever payment module they are using (PayPal, eWay, Direct Bank Deposit ... same issue)....

---

Need to clarify that the customer is not charged tax on shipping - products are being charged ok.

Doesn't seem to happen with US addresses...or is it maybe specific to tax-included pricing?

Quote:

---

Originally Posted by DrByte

......or is it maybe specific to tax-included pricing?

---

Sorry Doc, not sure what you mean with that?

I rarely use the store in "display prices with tax included " enabled. But I'm guessing that's the only way you use it. Is this isolated to that scenario?

What are your settings on the specific Shipping Module?

What are the settings on the Zone Definition and Details used for your Tax Class for shipping?

Quote:

---

Originally Posted by DrByte

I rarely use the store in "display prices with tax included " enabled. But I'm guessing that's the only way you use it. Is this isolated to that scenario?

---

That's the law in the country of Oz, tax must me included in the prices shown. It worked perfectly since 2007 up to ZC 1.5.4 , so I don't know what happened after upgrading.

Quote:

---

Originally Posted by Ajeh

What are your settings on the specific Shipping Module?

What are the settings on the Zone Definition and Details used for your Tax Class for shipping?

---

Thanks Ajeh,

In the Zone defintions only the country is selected. No change since 2007 ....

Shipping is classed as Taxable Goods

Just for giggles and grins ... peek at the Zone Details, do you have each of the Zones selected or does it read Please Select?

If it reads Please Select, what happens if you add each of the Zones listed?

Quote:

---

Originally Posted by Ajeh

Just for giggles and grins ... peek at the Zone Details, do you have each of the Zones selected or does it read Please Select?

If it reads Please Select, what happens if you add each of the Zones listed?

---

Will do that immediately after I filled my face with some (home made ) pizza :smile: - please bear with me....

Quote:

---

Originally Posted by frank18

That's the law in the country of Oz, tax must me included in the prices shown. It worked perfectly since 2007 up to ZC 1.5.4 , so I don't know what happened after upgrading.

---

It is the law in most European countries.

Quote:

---

Originally Posted by Ajeh

Just for giggles and grins ... peek at the Zone Details, do you have each of the Zones selected or does it read Please Select?

If it reads Please Select, what happens if you add each of the Zones listed?

---

This is what I have:
Attachment 16359

And I have no zones for the Netherlands. Never had, because there is no need for. We do not use them for taxes or shipping.

Quote:

---

Originally Posted by Ajeh

Just for giggles and grins ... peek at the Zone Details, do you have each of the Zones selected or does it read Please Select?

---

It reads 'Please Select' but never had to do that in previous ZC versions - always worked for all sub zones with only Australia selected as a zone in relevant local shipping modules.

Does this mean that it is working now? :lookaroun

Quote:

---

Originally Posted by Ajeh

Does this mean that it is working now? :lookaroun

---

Nope, same in another test order, shipping cost shows excluding tax (as above)

What Country are you testing for?

Quote:

---

Originally Posted by Ajeh

What Country are you testing for?

---

Just Australia - that's where the issue appeared since upgrading to 1.5.5a

And you have each Zone for Australia added individually in the Zone Details, correct?

Quote:

---

Originally Posted by Ajeh

And you have each Zone for Australia added individually in the Zone Details, correct?

---

No Ajeh, never added each zone (state) individually for Australia in the Zone Details - never have since ZC 1.3.7 as the same tax rules apply in every state of Oz. What puzzles me is that it has worked without a glitch ever since, the issue only appeared since the upgrade from 1.5.4 to 1.5.5a .....

In the Zone Details, if you Edit it what do you see:

Edit Sub Zone

Please make any necessary changes

Country:

Zone:

Quote:

---

Originally Posted by Ajeh

In the Zone Details, if you Edit it what do you see:

---

Does that help?

Attachment 16360

I would like you to go to Zone Definitions where the title on the page reads:

Quote:

---

Zone Definitions - Taxes, Payment and Shipping

---

and click on DETAILS ... then click on it to see what is in the DETAILS of the Zone and edit that ...

Either it says Country Australia and the sub zone reads Please Select or you have each of the 8 sub zones in it ...

Hi

I tried this a clean install of v155 and could not see any problems.

Here is what I did.

Clean Install
Admin set DISPLAY_PRICE_WITH_TAX = true
Created Tax Class called 'Shipping Tax'
Created tax rate for 'Shipping Tax' for 'Florida' Zone @10%
Assigned 'Shipping Tax' to Flat Rate shipping 'Tax Class'

Created an order, and at all points in checkout correct values were shown. In admin correct values were shown in orders/invoices etc

So I am stumped as to why you have problems

Anyway lets try to work backwards to see what the settings should be

Firstly, I assume you have set a Tax Class against your shipping module
You must also have previously created a 'Shipping Tax Class' in admin/tax_classes.php
Then a Shipping Tax Rate in admin/tax_rates.php using the 'Shipping Tax Class' and assigning it to a Zone
Is the Zone there the same as say the Zone you use for product taxes, or did you create a new zone for the shipping tax

Quote:

---

Originally Posted by Ajeh

I would like you to go to Zone Definitions where the title on the page reads:


and click on DETAILS ... then click on it to see what is in the DETAILS of the Zone and edit that ...

Either it says Country Australia and the sub zone reads Please Select or you have each of the 8 sub zones in it ...

---

Thanks Ajeh, it says 'Country Australia and the sub zone reads Please Select' .... as per earlier posts, no changes made to these settings since 2007.

Quote:

---

Originally Posted by wilt

Hi

I tried this a clean install of v155 and could not see any problems.

Here is what I did.

Clean Install
Admin set DISPLAY_PRICE_WITH_TAX = true
Created Tax Class called 'Shipping Tax'
Created tax rate for 'Shipping Tax' for 'Florida' Zone @10%
Assigned 'Shipping Tax' to Flat Rate shipping 'Tax Class'

Created an order, and at all points in checkout correct values were shown. In admin correct values were shown in orders/invoices etc

So I am stumped as to why you have problems

Anyway lets try to work backwards to see what the settings should be

Firstly, I assume you have set a Tax Class against your shipping module
You must also have previously created a 'Shipping Tax Class' in admin/tax_classes.php
Then a Shipping Tax Rate in admin/tax_rates.php using the 'Shipping Tax Class' and assigning it to a Zone
Is the Zone there the same as say the Zone you use for product taxes, or did you create a new zone for the shipping tax

---

Did you also set the store side tax to 'true'?

Okay, this I think is the issue ...

Where it says Please Select, do you see the 8 sub zones in the drop down?

If so, can you add each of the 8 sub zones?

Does it work?

Quote:

---

Originally Posted by Ajeh

Okay, this I think is the issue ...

Where it says Please Select, do you see the 8 sub zones in the drop down?

If so, can you add each of the 8 sub zones?

Does it work?

---

Will do that in the morning - almost 2am here now, eyes are getting a bit heavy - will report back when done. Thank you so much to all so far - talk tomorrow.

You realize we will be on pins and needles until you test that right? :lookaroun

Fresh eyes and brain...... thanks for your patience.

Quote:

---

Originally Posted by wilt

Firstly, I assume you have set a Tax Class against your shipping module

---

Yes, same since Nov 2007

Quote:

---

Originally Posted by wilt

You must also have previously created a 'Shipping Tax Class' in admin/tax_classes.php

---

Yes, no change since Nov 2007

Quote:

---

Originally Posted by wilt

Then a Shipping Tax Rate in admin/tax_rates.php using the 'Shipping Tax Class' and assigning it to a Zone
Is the Zone there the same as say the Zone you use for product taxes, or did you create a new zone for the shipping tax

---

Yes, there is only one single Tax Class.

Everything was working perfectly until the last upgrade. Shipping charge always showed with 10% GST included.

Quote:

---

Originally Posted by Ajeh

Okay, this I think is the issue ...

Where it says Please Select, do you see the 8 sub zones in the drop down?

If so, can you add each of the 8 sub zones?

Does it work?

---

Now added all 8 sub zones (previously the setting was 'All Zones' for Australia), did a test order and the shipping charge still shows without GST. Didn't think it would make any difference by adding all 8 sub zones as that is the same as have the setting 'All Zones'.

I know this is a recording, but the shipping charge always showed perfectly until the last upgrade from 1.5.4 to 1.5.5a

The interesting bit is that the shipping charge shows correctly (incl GST) during the entire checkout process (customer side) but is wrong in admin, order and invoice.

Does it show right on the checkout_success? (where it says Thank You to the customer and shows the details of the order)

Quote:

---

Originally Posted by Ajeh

Does it show right on the checkout_success? (where it says Thank You to the customer and shows the details of the order)

---

Thanks Ajeh, on my checkout_success page it shows just

Your Order Number is: 11013054

Thank You for Your Order Frank !
Your transaction has been completed, and a receipt for your purchase has been emailed to you.

Using Responsive Sheffield Blue template (adapted all changes necessary for 1.5.5a , obtained a working file set from rbarbour).

Now that triggered a light bulb: I did another test order using the new Responsive Classic template. And there it shows shipping with no tax included.

So the fault must be happening when confirming the order....

Is this a test upgrade to v155a?

If this is a Test or working site, as in not Live, can you switch to the Classic Template and try a checkout ... Does the checkout_success have the right numbers all the way through?

Is this a site that we can perhaps peek at?

Quote:

---

Originally Posted by Ajeh

Is this a test upgrade to v155a?

If this is a Test or working site, as in not Live, can you switch to the Classic Template and try a checkout ... Does the checkout_success have the right numbers all the way through?

Is this a site that we can perhaps peek at?

---

I am doing all the testing on a local clone of the live site (frnt dot com dot au) - it is the live site where this became evident with a customer doing an order below the free shipping threshold of $150 (all other orders since upgrading were over $150 - hence no shipping charged and therefore no shipping tax applicable).

Just did another test (locally) using the Contemporary Classic Green and the same issue persists: all shows fine up and including the order_confirmation page but shipping shows excluding tax on the checkout_success page and in admin.

Did another comparison (ZC install files vs site files) with my trusted Beyond Compare

includes/classes/order_total.php
includes/classes/order.php
includes/functions/functions_taxes.php

and a few other functions and various includes/modules/pages/....../header_php.php files but they all look identical!

Got it working again.

Created another fresh clone for this module (zones4), tested it locally and it works as expected - all good.

All I can put this down to is a corrupted FTP transfer when I first uploaded all the new/modified files to the server after the upgrade was completed locally.

After that my usual practice is to zip up my local upgrade file set and then delete all files locally. Then I usually download a complete live site mirror so I have exactly the same file system locally as I have it on the live store, so the 2 sets were identical but for the 2 configure files.

After creating a new clone and testing it locally to satisfaction, the newly created clone (zones4) now runs ok on the live site.

A rare incident, I know, but sometimes you-know-what :censored: happens! Just cost me a bit more hair-loss.........

Thanks again to all for taking the time and assistance.

Cheers / Frank

Quote:

---

Originally Posted by frank18

Got it working again.

Created another fresh clone for this module (zones4), tested it locally and it works as expected - all good.

All I can put this down to is a corrupted FTP transfer when I first uploaded all the new/modified files to the server after the upgrade was completed locally.

After that my usual practice is to zip up my local upgrade file set and then delete all files locally. Then I usually download a complete live site mirror so I have exactly the same file system locally as I have it on the live store, so the 2 sets were identical but for the 2 configure files.

After creating a new clone and testing it locally to satisfaction, the newly created clone (zones4) now runs ok on the live site.

A rare incident, I know, but sometimes you-know-what :censored: happens! Just cost me a bit more hair-loss.........

Thanks again to all for taking the time and assistance.

Cheers / Frank

---

In creating the clone... did you have to "install" it to the system? Ie. Any sql that had to be performed?

I don't/didn't see any such discussion (I thought) before.

Quote:

---

Originally Posted by mc12345678

In creating the clone... did you have to "install" it to the system? Ie. Any sql that had to be performed?

I don't/didn't see any such discussion (I thought) before.

---

Absolutely! That is common practice when uploading a new clone.

Quote:

---

Originally Posted by frank18

Absolutely! That is common practice when uploading a new clone.

---

And with the "previous" clone "transferred" to this file system but already populated in the database (since 2007 :P)? Was it "removed" either prior to the database upgrade or upon the database upgrade and subsequently reinstalled?

I just upgraded to 1.5.5a from 1.5.4 and I have the exact same issues as report here. My order during checkout process is showing everything right. Shipping tax is included. But once the customer purchases using PayPal and then returned to the website the Shipping taxes are now not being shown. Plus the email confirmation also doesn't include the shipping taxes included. Therefore got customers calling as Paypal has charged them more then what the confirmation email showed. Of course Paypal is correct as everything was right during checkout, but tax on shipping missing after.

If anyone who also had this issue, what exactly did you do to fix the issue. Is the issues with the zones, shipping modules?

What shipping module are you using?

Do you have display prices with tax in Catalog and the Admin turned on or off?

Also in the Zone Definitions for taxes, what Country is set?

Do you see Please Select or All Zones or do you have individual Zones added?

Quote:

---

Originally Posted by mmcculli

I just upgraded to 1.5.5a from 1.5.4 and I have the exact same issues as report here. My order during checkout process is showing everything right. Shipping tax is included. But once the customer purchases using PayPal and then returned to the website the Shipping taxes are now not being shown. Plus the email confirmation also doesn't include the shipping taxes included. Therefore got customers calling as Paypal has charged them more then what the confirmation email showed. Of course Paypal is correct as everything was right during checkout, but tax on shipping missing after.

If anyone who also had this issue, what exactly did you do to fix the issue. Is the issues with the zones, shipping modules?

---

And in addition to Ajeh's questions, did you uninstall then re-install your shipping modules when upgrading?

From the upgrade instructions (found in the /docs folder):

Quote:

---

NOTICE: Re: Payment AND Shipping Modules

You will need to re-install all your active payment and shipping modules as part of your upgrade:

• BEFORE UPGRADING, Take note of the login IDs, transaction keys, email addresses and other settings already configured in EACH of your Payment AND Shipping modules (You'll need this info so you can re-enter it after Installing the modules again).
• Remove each module by clicking the "Remove" button for each one.
• AFTER UPGRADING, Install each module (that you're using) in Admin->Modules->Payment and Admin->Modules->Shipping in order to take advantage of the bugfixes and feature improvements in each module. (you do NOT need to do this with modules you're NOT using. If you're no longer using a certain module anymore and it doesn't have a red dot next to it, click the "Remove" button to save on processing performance.)
• Re-enter all your configuration settings for each module as you go along. BE SURE TO TEST each one before you take your store live again, to make sure you've got all your settings entered correctly.

---

I am using Table Rate Shipping Modules. I didn't uninstall and reinstall any of the modules (Shipping or Payment). I didn't see that instructions, I figured going for 1.5.4 to 1.5.5a would be a small upgrade.

Attachment 16382

I am in Canada. I have the Zone Definitions groups by Provinces and each province in Canada has different tax rates, plus the shipping cost(Table Rate) would be also different by province. So have I 4 clones(copy) for the Table.php.

I have removed and reinstalled the Table Rate Shipping Module. Still no luck. The part I find interesting is it shows the taxes and total right during the checkout process. It is not until you complete the order does it show the taxes/total wrong. It forwards the right amount to the payment module (PayPal). But once complete and you are on the "main_page=checkout_success" page doe it show the taxes wrong. Plus the email sent out is also wrong. How does it do everything right until the end, plus there was not to many changes to ZenCart 1.5.5a from 1.5.4 I thought looking at the list.

Attachment 16383

Just as a test, if you edit one of the Table rates and leave the setting for the Taxes but remove the Zone setting, does it work?

Then if you edit it again and put back the Zone setting, does it break again?

Yes it works if I removed the Zone Setting. When I add the zone setting back in it breaks again.

Still not sure of the fix yet but this helps to narrow it down ...

Is there any screenshot I can sent for you can see how I have it setup. Been running the same setup since version 1.3.8 without issues.

It is a little confusing as each province has difference tax rates. See image below were I show the breakdown. I separated shipping from products.

Attachment 16385

Next in the Zone Definitions area. I have grouped the different zones(provinces) and their taxes. But for Shipping zone definitions I don't have taxes linked in, just the zones. (they are yellow status)

Attachment 16386

Then if you look at the Table Rate I link in the Tax Class and Shipping Zones.

Attachment 16387

Maybe there is a better way now days to configure this. I setup on configuration based on an article I found back in 2009. Worked fine until I upgraded to 1.5.5a.

Not sure how it all works but I just realized as I am using 4 Table Rate shipping modules I have four clones of includes/modules/shipping/table.php But my table2.php, table3.php and table4.php are not version 1.5.5. Old versions.

Of course right now when I am testing I am just using the first one table.php. Not the other three.

No, I can reproduce the problem ... now the goal is we are looking how to correct the problem ... :lookaroun

I was having issues with reproducing the problem as I did not have the Zone set on the shipping module and just had set the Tax Class ...

Just checking back in to see if you have been able to recreate the issue(bug) on your side so you can hopefully soon patch the bug.

Have recreated it and it happens when a Zone is set on the shipping module ... without the Zone set it works ...

We are still working on a solution for this ...

Quote:

---

Originally Posted by Ajeh

Have recreated it and it happens when a Zone is set on the shipping module ... without the Zone set it works ...

We are still working on a solution for this ...

---

So it wasn't just a botched up FTP upload on my end after all :huh:??

My guess is you had a Zone set then did not when you reinstalled ...

It is possible that there was another issue, but so far I am not finding any other trigger for this. I thought your reinstall was the fix also, as the same thing happened for me. But then I realized that I had the Zone set when it was broken and on the new install I did not have the Zone set.

So it was just a dilussion on my testing, making me think a new install fixed it, until I really tested it a lot further for the real issue ... :lookaroun

Quote:

---

Originally Posted by Ajeh

My guess is you had a Zone set then did not when you reinstalled ...

It is possible that there was another issue, but so far I am not finding any other trigger for this. I thought your reinstall was the fix also, as the same thing happened for me. But then I realized that I had the Zone set when it was broken and on the new install I did not have the Zone set.

So it was just a dilussion on my testing, making me think a new install fixed it, until I really tested it a lot further for the real issue ... :lookaroun

---

Thanks for the update Ajeh. If I hate any error, bug, fault, whatever then it is one of an intermittent, inconsistent nature, just like one in the electrics in a car......

Is there anything I can do to help? I do have the website in a sandbox so can test things out if you like.

As an EXPERIMENT (no guarantees here with this idea), you could try the following...

/includes/modules/checkout_process.php
Around line 51 you'll see this section of code:

Code:

---

// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');
$shipping_modules = new shipping($_SESSION['shipping']);

require(DIR_WS_CLASSES . 'order.php');
$order = new order;

---

Try moving the shipping-module part down a few lines, like this:

Code:

---

// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');

require(DIR_WS_CLASSES . 'order.php');
$order = new order;

$shipping_modules = new shipping($_SESSION['shipping']);


---

Note: ZC v155b includes this fix:
https://github.com/zencart/zencart/pull/1034

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?

Quote:

---

Originally Posted by 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?

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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!

Quote:

---

Originally Posted by 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:

Code:

---

function invoice() {

---

into:

Code:

---

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...

Quote:

---

Originally Posted by mc12345678

Suggested "test" would be...

---

+1 to it all ... :)

Quote:

---

Originally Posted by 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

Code:

---

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

---

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

Code:

---

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

---

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

Quote:

---

Originally Posted by frank18

Did some digging.....

In includes/classes/shipping.php

ZC versions 1.5.1 and 1.5.4 we find around line 144

Code:

---

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

---

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

Code:

---

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

---

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

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by rued

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

What happens if you change:

Code:

---

function invoice() {

---

into:

Code:

---

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.

Note! DrByte has added the fix for v1.5.5b:

https://www.zen-cart.com/showthread....61#post1312461

-> https://github.com/zencart/zencart/pull/1034

Quote:

---

Originally Posted by DrByte

As an EXPERIMENT (no guarantees here with this idea), you could try the following...

/includes/modules/checkout_process.php
Around line 51 you'll see this section of code:

Code:

---

// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');
$shipping_modules = new shipping($_SESSION['shipping']);

require(DIR_WS_CLASSES . 'order.php');
$order = new order;

---

Try moving the shipping-module part down a few lines, like this:

Code:

---

// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');

require(DIR_WS_CLASSES . 'order.php');
$order = new order;

$shipping_modules = new shipping($_SESSION['shipping']);


---

Note: ZC v155b includes this fix:
https://github.com/zencart/zencart/pull/1034

---

Having the same problem in 1.5.5e

I noticed the code had been moved around like this:

require(DIR_WS_CLASSES . 'order.php');
$order = new order;

// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');
$shipping_modules = new shipping($_SESSION['shipping']);

So I am just trying to move it in the same order as your post, like this to see if it fixes the issue.

So its like this:

// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');

require(DIR_WS_CLASSES . 'order.php');
$order = new order;
$shipping_modules = new shipping($_SESSION['shipping']);

@Nick1973; the change required that the order-class object be created prior to the shipping-class object ... so both the post that you reference and the code that's in the ZC 1.5.5e contain the same processing.

Make sure, too, that you don't have a template-override version of the checkout_process.php handling (i.e. /includes/modules/YOUR_TEMPLATE/checkout_process.php) that doesn't include the update.

Quote:

---

Originally Posted by lat9

@Nick1973; the change required that the order-class object be created prior to the shipping-class object ... so both the post that you reference and the code that's in the ZC 1.5.5e contain the same processing.

Make sure, too, that you don't have a template-override version of the checkout_process.php handling (i.e. /includes/modules/YOUR_TEMPLATE/checkout_process.php) that doesn't include the update.

---

No definitely no override file.

VAT is set up using the core Zen Cart System. There aren't any plugins calculating VAT other table rate shipping.

Shipping is set up using Table Rate Clones, similar to what people have talked about in this thread.

Please see the screenshots in the zip file in this link:

https://www.ventureonlineuk.co.uk/screenshots.zip

These will help you understand how shipping has been set up in the cart.

Quote:

---

Originally Posted by Nick1973

So I am just trying to move it in the same order as your post, like this to see if it fixes the issue.

So its like this:

PHP Code:

---

// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');

require(DIR_WS_CLASSES . 'order.php');
$order = new order;
$shipping_modules = new shipping($_SESSION['shipping']); 


---

---

So has this actually fixed your issue??

Quote:

---

Originally Posted by frank18

So has this actually fixed your issue??

---

Not sure yet, I am waiting for an order at the moment. I will try and test it shortly though. I realised after that my SSL was out of date on my site so you may have got a security error.

Quote:

---

Originally Posted by Nick1973

Not sure yet, I am waiting for an order at the moment. I will try and test it shortly though. I realised after that my SSL was out of date on my site so you may have got a security error.

---

SSL now fixed so you should be able to get to the attachments.

Quote:

---

Originally Posted by Nick1973

SSL now fixed so you should be able to get to the attachments.

---

Ok even after making the change as stated by Dr Byte and switching the table rate modules off then back on, VAT is still not being charged on delivery.

Quote:

---

Originally Posted by Nick1973

Ok even after making the change as stated by Dr Byte and switching the table rate modules off then back on, VAT is still not being charged on delivery.

---

In this thread that was started, the report was that VAT was not being calculated in the admin. Then here it was reported that operation of the store was the same as previously reported in this thread. So far, no data has been shown about what is actually happening.
Ie.
What does the order confirmation show?
What is the result in the various locations within the admin where the issue seems to appear?
During the checkout process where does the "calculation" appear incorrectly?
What payment module(s) are involved?
How has the store been otherwise modified or amplified (what files have been added or attempted to be renamed)?

Attachment 17078

Quote:

---

Originally Posted by mc12345678

In this thread that was started, the report was that VAT was not being calculated in the admin. Then here it was reported that operation of the store was the same as previously reported in this thread. So far, no data has been shown about what is actually happening.
Ie.
What does the order confirmation show?
What is the result in the various locations within the admin where the issue seems to appear?
During the checkout process where does the "calculation" appear incorrectly?
What payment module(s) are involved?
How has the store been otherwise modified or amplified (what files have been added or attempted to be renamed)?

---

Ok if you look further up I have supplied screenshots you can download of how shipping, countries, zones, VAT etc is set up.

You can get them here https://www.ventureonlineuk.co.uk/screenshots.zip

I've attached a further screenshot of the admin after the order, get your calculator out and you will see its not adding VAT to the shipping cost.

What does the order confirmation show? The order confirmation email shows the same as what appears in the admin.

What is the result in the various locations within the admin where the issue seems to appear? There's only one location and that is Customers > Orders

During the checkout process where does the "calculation" appear incorrectly? No it doesn't appear incorrectly, and the customer pays the 'cost of the product + VAT' and 'cost of shipping + VAT' NOT 'cost of the product + VAT' and 'cost of shipping - no VAT'

What payment module(s) are involved? - Worldpay V.3.0

How has the store been otherwise modified or amplified (what files have been added or attempted to be renamed)? - none that would affect the checkout process, and before you jump on this, I cannot give you a run down of every single file that has been changed, but I do know none of them would affect the checkout process since nothing has been changed there.

Disregard this thread https://www.zen-cart.com/showthread....ating-in-admin

I'd opened it before discovering the thread we are on now, which appears to be people experiencing similar issues.

Quote:

---

Originally Posted by bottyz

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.

---

Quote:

---

Originally Posted by Nick1973

Ok if you look further up I have supplied screenshots you can download of how shipping, countries, zones, VAT etc is set up.

You can get them here https://www.ventureonlineuk.co.uk/screenshots.zip

I've attached a further screenshot of the admin after the order, get your calculator out and you will see its not adding VAT to the shipping cost.

What does the order confirmation show? The order confirmation email shows the same as what appears in the admin.

What is the result in the various locations within the admin where the issue seems to appear? There's only one location and that is Customers > Orders

During the checkout process where does the "calculation" appear incorrectly? No it doesn't appear incorrectly, and the customer pays the 'cost of the product + VAT' and 'cost of shipping + VAT' NOT 'cost of the product + VAT' and 'cost of shipping - no VAT'

What payment module(s) are involved? - Worldpay V.3.0

How has the store been otherwise modified or amplified (what files have been added or attempted to be renamed)? - none that would affect the checkout process, and before you jump on this, I cannot give you a run down of every single file that has been changed, but I do know none of them would affect the checkout process since nothing has been changed there.

Last edited by Nick1973; 31 May 2017 at 07:36 AM.

---

So yes, had reviewed all of the images which generally showed "everything" but certainly made it difficult to identify if there was a difference that caused an issue... I.e. a sample of one "set" would have been sufficient if all testing indicated that all of the others experienced the same problem.

Now that said and in line with other communication in this thread, note the above quoted post. It specifically relates to Worldpay and does not involve the checkout_X files that supposedly have been changed away from the ZC 1.5.5 version of the sequence.

So what does your wp_checkout_process.php file look like? (Found in includes/modules/wp_checkout_process.php)

My guess is that it looks like this currently beginning at/around line 24:

Code:

---

// load selected payment module
require(DIR_WS_CLASSES . 'payment.php');
// $payment_modules = new payment($_SESSION['payment']);
$payment_modules = new payment('worldpay');
// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');
$shipping_modules = new shipping($_SESSION['shipping']);

require(DIR_WS_CLASSES . 'order.php');
$order = new order;

---

Instead of the suggested method (Moving the red text to below the new order):

Code:

---

// load selected payment module
require(DIR_WS_CLASSES . 'payment.php');
// $payment_modules = new payment($_SESSION['payment']);
$payment_modules = new payment('worldpay');

require(DIR_WS_CLASSES . 'order.php');
$order = new order;

// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');
$shipping_modules = new shipping($_SESSION['shipping']);

---

Further, to confirm that this is in fact a result of the payment module, if you were temporarily enable say check/money order and perform a checkout using that payment method and confirm that the results are as expected/desired it would identify that the payment method is at play (which bottyz already has confirmed).

Quote:

---

Originally Posted by Nick1973

Disregard this thread https://www.zen-cart.com/showthread....ating-in-admin

I'd opened it before discovering the thread we are on now, which appears to be people experiencing similar issues.

---

With the additional information validating that the issue experienced actually does match the issue described makes that quite true. As such you already provided a link from that thread to this one so if someone stumbles across it in a similar search they should come to here and hopefully find their answer.

Quote:

---

Originally Posted by mc12345678

So yes, had reviewed all of the images which generally showed "everything" but certainly made it difficult to identify if there was a difference that caused an issue... I.e. a sample of one "set" would have been sufficient if all testing indicated that all of the others experienced the same problem.

Now that said and in line with other communication in this thread, note the above quoted post. It specifically relates to Worldpay and does not involve the checkout_X files that supposedly have been changed away from the ZC 1.5.5 version of the sequence.

So what does your wp_checkout_process.php file look like? (Found in includes/modules/wp_checkout_process.php)

My guess is that it looks like this currently beginning at/around line 24:

Code:

---

// load selected payment module
require(DIR_WS_CLASSES . 'payment.php');
// $payment_modules = new payment($_SESSION['payment']);
$payment_modules = new payment('worldpay');
// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');
$shipping_modules = new shipping($_SESSION['shipping']);

require(DIR_WS_CLASSES . 'order.php');
$order = new order;

---

Instead of the suggested method (Moving the red text to below the new order):

Code:

---

// load selected payment module
require(DIR_WS_CLASSES . 'payment.php');
// $payment_modules = new payment($_SESSION['payment']);
$payment_modules = new payment('worldpay');

require(DIR_WS_CLASSES . 'order.php');
$order = new order;

// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');
$shipping_modules = new shipping($_SESSION['shipping']);

---

Further, to confirm that this is in fact a result of the payment module, if you were temporarily enable say check/money order and perform a checkout using that payment method and confirm that the results are as expected/desired it would identify that the payment method is at play (which bottyz already has confirmed).

---

I'd already moved it, like this, and missed the bit about Worldpay so my apologies if I missed that in reading.

I have now changed the below from this:
/ load selected payment module
require(DIR_WS_CLASSES . 'payment.php');
$payment_modules = new payment($_SESSION['payment']);

require(DIR_WS_CLASSES . 'order.php');
$order = new order;

// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');
$shipping_modules = new shipping($_SESSION['shipping']);

To this:

// load selected payment module
require(DIR_WS_CLASSES . 'payment.php');
// $payment_modules = new payment($_SESSION['payment']);
$payment_modules = new payment('worldpay');

require(DIR_WS_CLASSES . 'order.php');
$order = new order;

// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');
$shipping_modules = new shipping($_SESSION['shipping']);

Quote:

---

Originally Posted by Nick1973

I'd already moved it, like this, and missed the bit about Worldpay so my apologies if I missed that in reading.

I have now changed the below from this:
/ load selected payment module
require(DIR_WS_CLASSES . 'payment.php');
$payment_modules = new payment($_SESSION['payment']);

require(DIR_WS_CLASSES . 'order.php');
$order = new order;

// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');
$shipping_modules = new shipping($_SESSION['shipping']);

To this:

// load selected payment module
require(DIR_WS_CLASSES . 'payment.php');
// $payment_modules = new payment($_SESSION['payment']);
$payment_modules = new payment('worldpay');

require(DIR_WS_CLASSES . 'order.php');
$order = new order;

// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');
$shipping_modules = new shipping($_SESSION['shipping']);

---

In what file did you make the above changes? (basically commented out the use of the session payment information and forced the worldpay module as the payment method)

Quote:

---

Originally Posted by mc12345678

So yes, had reviewed all of the images which generally showed "everything" but certainly made it difficult to identify if there was a difference that caused an issue... I.e. a sample of one "set" would have been sufficient if all testing indicated that all of the others experienced the same problem.

Now that said and in line with other communication in this thread, note the above quoted post. It specifically relates to Worldpay and does not involve the checkout_X files that supposedly have been changed away from the ZC 1.5.5 version of the sequence.

So what does your wp_checkout_process.php file look like? (Found in includes/modules/wp_checkout_process.php)

My guess is that it looks like this currently beginning at/around line 24:

Code:

---

// load selected payment module
require(DIR_WS_CLASSES . 'payment.php');
// $payment_modules = new payment($_SESSION['payment']);
$payment_modules = new payment('worldpay');
// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');
$shipping_modules = new shipping($_SESSION['shipping']);

require(DIR_WS_CLASSES . 'order.php');
$order = new order;

---

Instead of the suggested method (Moving the red text to below the new order):

Code:

---

// load selected payment module
require(DIR_WS_CLASSES . 'payment.php');
// $payment_modules = new payment($_SESSION['payment']);
$payment_modules = new payment('worldpay');

require(DIR_WS_CLASSES . 'order.php');
$order = new order;

// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');
$shipping_modules = new shipping($_SESSION['shipping']);

---

Further, to confirm that this is in fact a result of the payment module, if you were temporarily enable say check/money order and perform a checkout using that payment method and confirm that the results are as expected/desired it would identify that the payment method is at play (which bottyz already has confirmed).

---

Further review indicates that possibly need to swap some of the other lines as well to at least align with the ZC 1.5.5 version of this area:

from includes/modules/pages/checkout_confirmation/header_php.php:

Code:

---

require(DIR_WS_CLASSES . 'order.php');
$order = new order;
// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');
$shipping_modules = new shipping($_SESSION['shipping']);

require(DIR_WS_CLASSES . 'order_total.php');
$order_total_modules = new order_total;
$order_total_modules->collect_posts();
$order_total_modules->pre_confirmation_check();
// load the selected payment module
require(DIR_WS_CLASSES . 'payment.php');

---

Notice the sequence: order, shipping, payment... This is still different as compared to a fresh install of WorldPay V3.0 as downloaded from the website which has it as: payment, shipping, order.

So actually looks like includes/modules/wp_checkout_process.php in this area should be changed from:

Code:

---

// load selected payment module
require(DIR_WS_CLASSES . 'payment.php');
// $payment_modules = new payment($_SESSION['payment']);
$payment_modules = new payment('worldpay');
// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');
$shipping_modules = new shipping($_SESSION['shipping']);

require(DIR_WS_CLASSES . 'order.php');
$order = new order;

---

possibly to:

Code:

---

require(DIR_WS_CLASSES . 'order.php');
$order = new order;

// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');
$shipping_modules = new shipping($_SESSION['shipping']);

require(DIR_WS_CLASSES . 'payment.php');
// $payment_modules = new payment($_SESSION['payment']);
$payment_modules = new payment('worldpay');

---

And maybe even include order totals type code moving to after the shipping code and before the payment code.

Quote:

---

Originally Posted by mc12345678

Further review indicates that possibly need to swap some of the other lines as well to at least align with the ZC 1.5.5 version of this area:

from includes/modules/pages/checkout_confirmation/header_php.php:

Code:

---

require(DIR_WS_CLASSES . 'order.php');
$order = new order;
// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');
$shipping_modules = new shipping($_SESSION['shipping']);

require(DIR_WS_CLASSES . 'order_total.php');
$order_total_modules = new order_total;
$order_total_modules->collect_posts();
$order_total_modules->pre_confirmation_check();
// load the selected payment module
require(DIR_WS_CLASSES . 'payment.php');

---

Notice the sequence: order, shipping, payment... This is still different as compared to a fresh install of WorldPay V3.0 as downloaded from the website which has it as: payment, shipping, order.

So actually looks like includes/modules/wp_checkout_process.php in this area should be changed from:

Code:

---

// load selected payment module
require(DIR_WS_CLASSES . 'payment.php');
// $payment_modules = new payment($_SESSION['payment']);
$payment_modules = new payment('worldpay');
// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');
$shipping_modules = new shipping($_SESSION['shipping']);

require(DIR_WS_CLASSES . 'order.php');
$order = new order;

---

possibly to:

Code:

---

require(DIR_WS_CLASSES . 'order.php');
$order = new order;

// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');
$shipping_modules = new shipping($_SESSION['shipping']);

require(DIR_WS_CLASSES . 'payment.php');
// $payment_modules = new payment($_SESSION['payment']);
$payment_modules = new payment('worldpay');

---

And maybe even include order totals type code moving to after the shipping code and before the payment code.

---

Well after changing that code, an order came through and the callback failed.

Quote:

---

Originally Posted by Nick1973

Well after changing that code, an order came through and the callback failed.

---

Although I will say I hadn't changed your extra bits.

Quote:

---

Originally Posted by Nick1973

Well after changing that code, an order came through and the callback failed.

---

That seems to be a running issue that is discussed in the WorldPay Version 3.0 thread with some included discussion/correction by niccol.

Long and short of it, although there was an equivalent system problem as was reported related to ZC core code, this issue is related to a plugin and its integration with ZC and not specifically ZC. It is unfortunate that countrycharm is no longer available to support further upgrade, but well, that's how life goes.

Recommendation would be to carry the discussion and problem resolution(s) further in that module's thread so that others using WorldPay may further help or also gain from the corrections.