Invoice missing tax on custom shipping module

Hi,

I have a custom shipping module (written by myself) that works properly everywhere (I've looked) except for on the Invoice. Here, it displays the shipping without tax and does not include that tax in the ot_tax or ot_total values.

It provides all the correct amounts in the estimator, and right through the checkout process. If I use a payment method like paypal, the order total is correct.

If I use perweightunit shipping set with the same zones and classes, the displayed info and the invoice are BOTH correct. So, that points to my shipping module.

My module has 2 methods and if a particular method is passed to ->quote() then it only returns the one.

From what I can see, it returns the same array structure as (say) the USPS module.

The class scoped vars seem to be the same as any other basic module as long as the module is ->enabled.

Admin / Configuration / My Store / Display prices with tax are both set.

zen-cart 1.3.9h on LAMP. PHP 5.2.10.

I have been searching and researching this for a couple of days now and could really use some pointers as to:-

• What might be causing this OR
• Where abouts the invoice generation code is and how it builds its order information. Perhaps seeing that might tell me why my module is not providing the right info at all times.

I have been searching and researching this for a couple of days now and could really use some pointersLocate:

return $this->quotes

Then add this immediately before.

if ($this->tax_class > 0) $this->quotes['tax'] = zen_get_tax_rate($this->tax_class, $order->delivery['country']['id'], $order->delivery['zone_id']);

Cheers
Rod

Thanks for your input Rod,

I am already doing that, and using debug statements that shows the quote structure returned by the shipping module I can see it returns the correct values of tax => 10 and cost (ex-gst).

I think the tax would not be handled properly everywhere if I did not have that statement before returning the quote.

So still looking for ideas.

Rod, Your post brings up an interesting question about almost all shipping modules I have looked at. It relates to the $this->tax_basis value and this ...> RodG:

if ($this->tax_class > 0) $this->quotes['tax'] = zen_get_tax_rate($this->tax_class, $order->delivery['country']['id'], $order->delivery['zone_id']);
Many shipping modules, including the standard set, have a setting to choose (shipping|billing|store) for tax basis of the shipping. According to the documentation, this should override the main store tax basis if needed.

However, I do not see any code, in the shipping modules themselves, to handle the different cases. The above code supplied seems to force the tax to be applied to shipping address only.

In the order class, the tax_address is found properly depending on the store tax basis ONLY. But it only calcs this for products so that is absolutely correct.

In the order total shipping (ot_shipping) class, the tax basis from the shipping module is used if set, else the store basis is used. This matches the description of how it should work.

At time of writing I have not located the method the shipping estimator uses to determine the tax. But if it relies on the tax setting returned by the shipping module, then it could be wrong.

Are there any known bugs in tax handling?

greyman56:

Many shipping modules, including the standard set, have a setting to choose (shipping|billing|store) for tax basis of the shipping
< snip >
The above code supplied seems to force the tax to be applied to shipping address only.

The code I provided was from the ozpost module. I was assuming your needs would be the same, unless you are working on module other than the one I'm aware of.

The reason I went this 'forced' route rather than the 'standard' method is because until/unless the GST laws are changed the other options don't apply. Why give the end user an option that if changed from the default will only cause a problem? (a difficult one to diagnose at that). Been there, done that... wasted days....

RodG:

The reason I went this 'forced' route rather than the 'standard' method is because until/unless the GST laws are changed the other options don't apply.Good point. And I've seen a couple of other shipping modules that just hard code 'Shipping' into the $this->tax_basis and do not worry about the admin config setting at all.

Found the part of my shipping module that triggered the problem. Although have not found the code in Zen-Cart that generates the problem. For others that may fall for the same trap, here's what happened.

In the class constructor of my shipping module, I thought I'd be clever and only do most of the class scoped variables if ->enabled. Things like icon, types, allowed methods, ignored postcode lists, AND tax_basis and tax_class were left until last to set.

Basically the constructor went...
->code,
->title,
->description,
->sort_order
Check enabled
Check for restricted zone
Then if still enabled set the rest of the $this-> variables and check config DB settings etc.

So what seems to be happening is that the zen-cart code that puts the shipping costs into the $_SESSION for the checkout_process handling to use, was looking for one or other of tax_basis or tax_class but the ->enabled was not set at the time. So it did not get the tax_class and left the tax out of the calc. Obviously, the code that handles the shipping calcs BEFORE checkout_confirmation have the shipping module enabled and thus got the correct values.

Making the $this->tax_class and $this->tax_basis available all the time just after sort_order has fixed the calcs in the invoice.

One day I might find out where that code lives in zen-cart and see if it can be improved.