Coupons, some bugs?

Standard Zen Cart 1.3.9h, updated in steps from 1.3.9c
No addons or hacks

First of the discount name is not stored when editing or saving discounts in admin.

Next customers in some weird circumstances gets «You must spend at least xxx to redeem this coupon»

The coupon can be set to t.ex. 1000 in minimum order value, and the customer have products for 1010.

But if adding one product more so the total of products is 1014 the coupon works fine. :shocking:

Tax rate for products is 25% and can not be a issue itself, when speeking of module config - the diff in value is to small

No specials or gift cards in cart/active.

:cry:

Issue with name seems to have been in some earlier version, there was noting stored in coupons_description table. But when adding this manually for exiting coupons it's seems fine, both for editing and new.

But the value issue is still something weird ... :)

Could you re-state this a little slower ... I am not following:

The coupon can be set to t.ex. 1000 in minimum order value, and the customer have products for 1010.

But if adding one product more so the total of products is 1014 the coupon works fine.

Are you saying a:
Minimum 1000

works for $1010 but not $1014 ... or what are you trying to say? :unsure:

No no ...

0-1012 is not working, but 1013+ is (for a coupon with minimum sett to 1000).

Weird isn't it :P

Test scenario:

• Brand new clean install of v1.3.9h, with demo products, USD as default currency. Taxes not included in prices.
• Create a new product for $1,000 price
• Create a coupon for $300 off, with minimum $1000 purchase
• Add the $1,000 product to the cart
• Start checkout, choose any shipping method
• Enter the 1000 coupon code
• "Congratulations you have redeemed teh Discount Coupon"

Looks fine to me.

Yes it does indeed, but not with several cheap products in my tests.

Do you have some ideas for debuging the values used in cart?

I repeated the test again with the 12 $25 products in the Big Unlinked category, adding various quantities of each to bring the cart to $1000.
Again, coupon worked just fine.

Sure ...

But we don't use flat prices ex tax etc.

We have amounts like 3,20 etc. ex tax (4 inc), and the cart can have 30 products or so before it's reaching the minimum.

Would be nice to debug the values used in order total module, but heck ... that's some kind of work to figure out everything there.

But OK, I'm downloading a complete copy of the site and will do a dif of it to see if something is accidentally changed in some way. Will also test the db on a fresh file base.

Will post back later ...

OK, now I see something causing this - but not how to fix it yet ...
The file system was fine btw.

If I add tax in any shipping modules it fails, if I disable tax in the shipping module the coupon code works fine. :shocking:

How the shipping modules tax can influence on coupon codes I don't see atm ... :unsure:

And it applies to all shipping modules I've tested, both core and custom.

Settings in ot_coupon:

This module is installed
true

Sort Order
280

Include Shipping
false

Include Tax
false

Re-calculate Tax
Standard

Tax Class
MVA 25%

I commented line 458 in ot_coupon.php, and it seems to be working now - in a way I will say is correct ...

    //if ($this->include_shipping != 'true') $order_total_tax -= $order->info['shipping_tax'];

Please let me know the thoughts behind this line, and if you see any potential issues with my "fix".

I have also had issues with coupons and tax and originally posted this in http://www.zen-cart.com/forum/showthread.php?t=163885 2nd Oct.

@ZC devs - please lett me know if you need a test setup or more info to investigate this issue, and I will help you out with that since this needs to be fixed in feature releases.

It surely is a bug as you should not remove shipping tax, when shipping is not included in calculation. Makes no sense to me.

rued:

Settings in ot_coupon:

Tax Class
MVA 25%
Why did you set a tax class on the coupon module?

rued:

@ZC devs - please lett me know if you need a test setup or more info to investigate this issue
To recreate the scenario, I need to know what exact steps I should take from a clean brand new install so that I can see the problem occur myself.

Thus far the following steps still don't trigger the problem for me when using v1.3.9h:

• Admin->Configuration->My Store->Display Tax in prices->True
• Admin->Configuration->My Store->Display Tax in prices (Admin)->True
• Admin->Configuration->My Store->Country->Some country with no zones
• Admin->Configuration->My Store->Zone-> blank
• Admin->Locations/Taxes->Zone Definitions->New Zone "mytest" -- add the same country from My Store setting above, all zones.
• Admin->Locations/Taxes->Tax Classes->New tax class->"Test"
• Admin->Locations/Taxes->Tax Rates->New tax rate->25%, tied to "Test" tax class and "mytest" zone.
• Admin->Catalog->Categories/Products->
  • create test product, for 3.2, which auto-calculates to 4.00 with tax (with tax class set to "Test")
  • give it a name and description and quantity
• Admin->GiftCert/Coupons->Coupon Admin->Create Coupon for 50 off a minimum 1000 purchase, unlimited uses
• Admin->Modules->Shipping->Flat Rate->price as 2.50, tax class "Test", Tax Basis "Store".

Add the product to the cart. Select qty 250, brings cart total to 1000. Commence checkout. Create an account, using address in the same country specified earlier, select the Flat Rate shipping for 2.50, proceed to payment page and enter the code for the coupon, and it applies it properly, showing my discount.

Repeated by adding additional products with varying prices. Same result.

DrByte:

Why did you set a tax class on the coupon module?
It doesn't matter ...

But why do you want to remove shipping tax from order totals tax when shipping isn't included in calculation?

DrByte:

• Admin->Modules->Shipping->Flat Rate->price as 2.50, tax class "Test", Tax Basis "Store".
  It's normal to use "Tax Basis: Shipping" in Europe

DrByte:

To recreate the scenario, I need to know what exact steps I should take from a clean brand new install so that I can see the problem occur myself.

• Fresh install of Zen Cart 1.3.9h incl. demo, with "Store Country: Norway" and "Store Zone: -None-"
• Configuration > My Store > Display Prices with tax True
• Add Zone Definition: Norway / Norwegian Tax Zone
• Chose details and add Norway all zones to it
• Add Tax Class: 25% MVA / Default Norwegian Tax Class
• Add Tax Rate: 25% MVA / Norway / 25 / Incl. 25% MVA / 1
• Run Query to save some time (adding Norwegian tax to all products):

UPDATE products SET products_tax_class_id = '2';

• Add Currencie: Norwegian Kroner / NOK / Kr. / ,- / , / . / 0 / 1 / Set as default

• Run Update Currensies

• Add a Discount Coupon with 10% off on a minimum of 1000

• Edit Flat Rate Shipping: "Tax Class: 25% MVA" and "Tax Basis: Shipping"

• Go to shop an choose Norwegian Kroner, add Matrox G400 32MB Kr. 625 + Matrox G200 MMS Kr. 375 to cart. Total should then be 1000.

• Checkout and make a test customer living in "Some street, 0001 OSLO, Norway"

• Fill in coupon code and it will fail, whatever shipping is chosen because of a rounding error in the calculation since 0 decimals is chosen for NOK (total actually is 999,97).

Now also test by adding a new product with the price 1000 incl. tax, and see it also failing in tests because of error in tax handling for the shipping modules in coupons.

As you can see there is at least two bugs in coupon module, one rounding issue and one tax issue.

I can give you access to the test site if your not able to recreate this issue locally, and you can poke around in it.

rued:

I commented line 458 in ot_coupon.php, and it seems to be working now - in a way I will say is correct ...

//if ($this->include_shipping != 'true') $order_total_tax -= $order->info['shipping_tax'];

> 
> Please let me know the thoughts behind this line, and if you see any potential issues with my "fix".

While that might work for your specific scenario, I'm reluctant to suggest it for "everyone", since there are other parts of the world which handle taxes differently than Norway, and many more which use 2 decimal places, instead of 0.

Notwithstanding, we'll look into the rounding concerns you mention.

As far as I know, most of Europe has some of the same tax handling as Norway - and for sure all Scandinavian countries. Any many of those are using 0 decimals.

That makes it quite a lots of Zen Cart shops having the same issue, and mostly without knowing it - if none of their customers has noticed them after facing the issue.

PS! If you believe someone ever will need to remove shipping tax from the tax total, when shipping isn't included in first place - make it a config option in the module.

rued:

PS! If you believe someone ever will need to remove shipping tax from the tax total, when shipping isn't included in first place - make it a config option in the module.
It is a config option in the module.

I think your points related to shipping calculations in this topic are symptoms and not root causes.

rued:

Any many of those are using 0 decimals.
Using 0 decimals as the common day-to-day method of doing commerce?
I've been looking around online and the various stores I've found that allow shopping in NOK seem to present 2 decimal places. And can't find any reference which states that 0 decimals is the "normal" practice there.

Or are you just trying to make your store prices "pretty" by rounding them to the nearest kr ?