Order Total: Disc Coupon: Displayed numbers dont add up: Total is correct

[RixStix]

156C

Didn't find anything in the BugReports that resembled this issue

When using a discount coupon which only applies to shipping, ie:free shipping checkbox, shipping is zero'd so the display is incorrect but the total is correct.

Subtotal: Correct
Discount Coupon: Correct
Shipping: Incorrect ie: changed to zero
Sales Tax: Correct
Total: Correct

Since the Shipping has been changed to zero based upon the discount code, the numbers visually do not add correctly.
Since only one discount coupon is allowed, and it is for free shipping, shouldn't the shipping value still show along with the discount code for that same amount... thus cancelling each other.

I don't recall my previous version (zc154) removing the shipping amount or zeroing the shipping amount, so that the displayed math was correct.

[RixStix]

Didn't make the deadline for edit

Actually any discount coupon that includes free shipping causes the displayed math to be incorrect while maintaining the correct OT

[lat9]

Rick, that calculation issue is due to the ordering you've got on the order_totals. Since you're offering coupons that provide free shipping, the ot_coupon's sort order should be higher than that of ot_shipping.

The change in behavior was due to a bugfix (mea culpa) in the ot_shipping processing, where previous versions of that module were providing its cost and tax values without regard to its sort-order. In techo-babble terms, the module was performing its calculations when the class was instantiated instead of when asked to process.

You, and other stores, that provide free-shipping type coupons can correct the behavior by ensuring that the sort-order for the ot_coupon's processing is higher than that of the ot_shipping one.

[RixStix]

Rick, that calculation issue is due to the ordering you've got on the order_totals. Since you're offering coupons that provide free shipping, the ot_coupon's sort order should be higher than that of ot_shipping.

The change in behavior was due to a bugfix (mea culpa) in the ot_shipping processing, where previous versions of that module were providing its cost and tax values without regard to its sort-order. In techo-babble terms, the module was performing its calculations when the class was instantiated instead of when asked to process.

You, and other stores, that provide free-shipping type coupons can correct the behavior by ensuring that the sort-order for the ot_coupon's processing is higher than that of the ot_shipping one.

Thank you Cindy,

I'll make the edit after coffee.

[lat9]

Thank you Cindy,

I'll make the edit after coffee.

Totally understand; coffee's an important part of life!

[RixStix]

Rick, that calculation issue is due to the ordering you've got on the order_totals. Since you're offering coupons that provide free shipping, the ot_coupon's sort order should be higher than that of ot_shipping.

The change in behavior was due to a bugfix (mea culpa) in the ot_shipping processing, where previous versions of that module were providing its cost and tax values without regard to its sort-order. In techo-babble terms, the module was performing its calculations when the class was instantiated instead of when asked to process.

You, and other stores, that provide free-shipping type coupons can correct the behavior by ensuring that the sort-order for the ot_coupon's processing is higher than that of the ot_shipping one.

THANK YOU. That looks much better & the numbers add correctly.