Assign maximum order weight for UPS

There is something a bit strange here ...

When you remove the Product from the cart that allowed the Discount Coupon ...

1 How many Products and what Quantity are in the cart?

2 What does the Discount read in the checkout_payment page?

1. A. Starting from an empty cart, add any product from C-20 or C-74 to cart -- for example, a Riviera shed kit.
2. B. Add products from C-65 to cart -- for example, 7 windows.
3. C. Go to checkout and redeem discount coupon.
4. D. Redemption code appears in order total on confirmation page.
5. E. Go to shopping cart and remove all products except C-65 (non-allowed) product(s).
6. F. Go to checkout, pick UPS shipping (only method available) and proceed to payment page.
7. Discount on checkout_payment page remains, e.g. "Redemption code: ZCZCZC : -$5.00"

Also, it just dawned on me that category 65 is a different product type than 20 and 74. The comparison I ran using the other 1.3.7 ZC utilized only one product type, not 2 as in the case of ShedKitStore.com. Could this matter?

Ajeh:

There is something a bit strange here ...

When you remove the Product from the cart that allowed the Discount Coupon ...

1 How many Products and what Quantity are in the cart?

2 What does the Discount read in the checkout_payment page?

Note that this example is just a $5 coupon. If you try it with a $400 coupon, the discount is exactly equal to the amount of the shipping. (If UPS shipping = $78.39, discount = -$78.39.)

I am looking into this ...

Meanwhile you still appear to have issues on the address book ...

If I go to edit my account I have to reselect my state ...

I am not sure if this is a template or code issue on there ... but one of the two is not correct ...

I thought the address book issues stemmed from something getting imported wrong when I migrated the database a few months ago. Had you created a new user account recently, or is it possible the customer or address book data was fuzzy?> Ajeh:

I am looking into this ...

Meanwhile you still appear to have issues on the address book ...

If I go to edit my account I have to reselect my state ...

I am not sure if this is a template or code issue on there ... but one of the two is not correct ...

Sorry -- dumb question on my part. I looked at your customer data & I see you were ported in during the migration. Let me check the address book and customers tables.

I could very well be missing the data but it should of fixed it when I edited ... and either it is not holding my state data or the code/template is not filling it in right when I edit ...

Check the address_book for the fields:
entry_country_id 223
entry_zone_id 47

I have both 223 for your entry_country_id and 47 for your entry_zone_id, but the state field is blank for all customers. Probably has to do with a modification I made to the state portion of the account forms. At the time, there was a grey input appearing with the state select dropdown, hence the modifications -- but I may have botched the way state values get to the address book in the process.

I won't torture either of us with any more of this tonight -- my brain is turning into a pumpkin and I'm going to bed before I break anything else. :sleepy:

Thanks for helping me get closer to functional, Linda. You rock!> Ajeh:

Check the address_book for the fields:
entry_country_id 223
entry_zone_id 47

The entry_state is only needed sometimes ... not always ...

The problem is the edit address is not listening to the setting so it is not selecting ...

This means either missing files or old files or template issue ...

Does a switch to Classic fix the edit?

Thanks Linda --

I tested using Classic template on a less productive site with similar address book files in its custom template. On that one, adding a new address in My Account with custom template gave> Warning: Cannot modify header information - headers already sent by (output started at /home/jjh/public_html/includes/languages/english/hd/address_book_process.php:75) in /home/jjh/public_html/includes/functions/functions_general.php on line 44. I then switched to Classic template, hit the back button on the catalog page and the new address was entered successfully. No data in the address book State field, but entry_zone_id and entry_country_id are correct.

I'll take another look at my template's account files versus template_default in Beyond Compare right now. > Ajeh:

The entry_state is only needed sometimes ... not always ...

The problem is the edit address is not listening to the setting so it is not selecting ...

This means either missing files or old files or template issue ...

Does a switch to Classic fix the edit?

After conforming all of those HardwareDog.com custom template files to match the template_default code, I then tried the address book again -- and again I got > Warning: Cannot modify header information - headers already sent by (output started at /home/jjh/public_html/includes/languages/english/hd/address_book_process.php:75) in /home/jjh/public_html/includes/functions/functions_general.php on line 44 -- and when backed up one page, the new address was entered. Apparently the error I got was not affected by the changes I made, and all it took to get the address into the database was backing up.

So I tried it again, a little different this time -- switched to Classic template, THEN went to address book and added a new address. Two things worth noting:

1. The ghost state input noted earlier wasn't there, unlike my custom template without the modified account files.
2. The address addition went through just fine.
   Knowing this, I'm looking at the modules now to see which file(s) overriding the default are blowing my address book.

Edit the language file and remove all the space(s) and blank line(s) at the end of the file that are immediately to the right of the php closing tag:
?>

Looks like the file is also double spaced or you have a heck of a lot of text in there ... mine is 38 lines long ... :cool:

Thanks! That fixed the language file problem. And I finally figured out the reason for the ghost input in the address book forms. My custom stylesheet was missing```
.hiddenField {
display: none;
}

Now back to the screwy checkout issue with denied discount coupons negating my shipping fees. ...> **Ajeh:**
>
> Edit the language file and remove all the space(s) and blank line(s) at the end of the file that are immediately to the right of the php closing tag:
> ?>
> 
> Looks like the file is also double spaced or you have a heck of a lot of text in there ... mine is 38 lines long ... :cool:

Still chasing down my bug in which checkout fails to remove discount coupon when allowed products are removed from cart after redemption code is accepted.

The bug manifests regardless whether allowed and denied products are different product types -- I tested for this just now.

It only happens when the shipping fee > 0. When free options shipping is selected, the discount is removed. Switch back to paid shipping, and the discount returns.

See for yourselves at ShedKitStore.com. I created a new coupon with redemption code EST5OFF ... it's for $5 off Estate shed kit. Add Estate to cart, then add a different shed kit to cart. (All shed kits are the same product type.) Go to checkout, redeem the EST5OFF code, then return to the cart and remove the Estate. Go back to checkout, select home delivery for $125, and proceed to billing page. Note the $5 discount is still applied in the order total, even though Top category is denied in the coupon's restrictions and only the Estate is allowed.

If anyone needs to create a new user account, please include the word TEST in the name.

Sean

As I stated before ... we are looking into this as this appears to be our bug not necessarily your's ...

Check your current settings before trying this ...

What happens if on the Modules ... Order Totals ... Discount Coupons ot_coupon ... if you edit that and set everything to:

This module is installed
true

Sort Order
280

Include Shipping
false

Include Tax
false

Re-calculate Tax
Standard

Tax Class
--none--

Fascinating -- and a little troubling.

1. I changed ShedKitStore ot_coupon as suggested, and that fixed it! :happy:
2. Further, I changed HardwareDog ot_coupon settings, which originally had Include Shipping set to false. After I changed it to true, I finally reproduced the problem in another Zen-Cart.
   I guess this means ot_coupon is a bit vulnerable in that customers who do a post-redemption cart revision can apply coupons toward shipping denied products, contrary to store owners' intent. :shocking:

THANK YOU, Linda, for greatly accelerating the solution to my problem. In the process, you have also discovered information that may help others prevent shipping mishaps due to an obscure Achilles' heel.> Ajeh:

Check your current settings before trying this ...

What happens if on the Modules ... Order Totals ... Discount Coupons ot_coupon ... if you edit that and set everything to:

NOTE: a Discount Coupon is for 1 of the following 3 things and you cannot combine them together:

1 Discount Amount

2 Discount Percentage

3 Free Shipping

You cannot combine Free Shipping with the discounts at this time ...

Just pointing out that any customer can cheat their way out of paying for shipping on item(s) whose discount (amount) coupon status is Deny -- providing the ot_coupon Include Shipping = true (in Modules/Order Total).

Or are mine the only sites with this vulnerability?> Ajeh:

NOTE: a Discount Coupon is for 1 of the following 3 things and you cannot combine them together:

1 Discount Amount

2 Discount Percentage

3 Free Shipping

You cannot combine Free Shipping with the discounts at this time ...