Order Total - penny rounding bug?

I've seen a few threads about penny rounding bugs, all of which seem to indicate these were solved in 1.5.0, but... I'm on 1.5.1, and here's a wee screenshot of an apparent order total bug - i.e. Sub-Total is £38.56, Delivery is £4.00, but Total is £42.55, not the expected £42.56.

ZC v1.5.1 (upgraded from a full install of 1.5.0)
Database Patch Level: 1.5.0
PHP: v5.3.28
MySQL: v5.5.42-cll

So first off this seems to only or primarily happen when the tax is considered to be a part of the entered price. Not to say it is the only condition in which it occurs, but is the condition in which it often appears.

No it is not completely solved even in yet newer versions. That said and now that you've upgraded from about four year old software to about three year old software, what's your plan to upgrade to software that is now almost 4 months old? (Assuming that your host offers a php version that supports it.)

Thanks for confirming that this is a bug.

Since you ask, my plan is to read the release notes and take a view based on the work and time involved in upgrading against the potential problems of not doing so.

1 - Are there any order total or other 'totaling' modules installed or active in your cart?

2 - Is this the byproduct of:

• rounding before final calculation
• rounding beyond a set limit or standard limit of decimals
• SQL field length restrictions
• bad math?

Twitchoo...

1. No, it's a standard install.

2. I have absolutely no idea. I'm just reporting that it happened.

When you swing on over to your admin -> modules -> order total

What's turned on and off?

arthurdent:

Thanks for confirming that this is a bug.

Since you ask, my plan is to read the release notes and take a view based on the work and time involved in upgrading against the potential problems of not doing so.

There are posted resolutions to the issue, between number of decimals, quantity of product associated, tax calculation/rounding, a mix of the above and other things I haven't listed...

Unfortunately somebody ends up losing a penny. The "state" (if the base product price increases and the sales tax remains the same or if the sales tax decreases and the product price remains the same), the customer (the tax amount increases while the price remains the same), or the store (price descreases and tax stays the same or tax increases and total payment remains the same)... And with these type calculations, it is in my opinion difficult to tell who either should get the "extra" penny and whether there really is one or what. :)

arthurdent:

I've seen a few threads about penny rounding bugs, all of which seem to indicate these were solved in 1.5.0, but... I'm on 1.5.1, and here's a wee screenshot of an apparent order total bug - i.e. Sub-Total is £38.56, Delivery is £4.00, but Total is £42.55, not the expected £42.56.

ZC v1.5.1 (upgraded from a full install of 1.5.0)
Database Patch Level: 1.5.0
PHP: v5.3.28
MySQL: v5.5.42-cll

Had the same problem some time ago and fixed it "my way" - see this thread: http://www.zen-cart.com/showthread.php?209786-Shopping-cart-Subtotal-not-equal-Checkout-Subtotal-%28rounding-error%29&p=1254894#post1254894

Works up to 1.5.4 - so far.

OK thanks Frank... when I get the time I'll investigate your solution.

Does seem a bit odd that, in all the years that ZC (and OSC) has been going, and with all the excellent people that contribute, this is still a problem. Surely "adding things up" is one of the core requirements of ecommerce software... :-/

I would say "good luck in the World Cup final on Sunday", but I'm a pommie b*****d. ;)

arthurdent:

OK thanks Frank... when I get the time I'll investigate your solution.

Does seem a bit odd that, in all the years that ZC (and OSC) has been going, and with all the excellent people that contribute, this is still a problem. Surely "adding things up" is one of the core requirements of ecommerce software... :-/

I would say "good luck in the World Cup final on Sunday", but I'm a pommie b*****d. ;)

The basic maths are fine in both ZC and OSC - but the error happens due to rounding of adding/subtracting taxes, discounts etc. My theory was to restrict decimals to 2 to try and eliminate that rounding error. After all there are no fractions of cents in the retail world even though are frequent in the manufacturing process.

Thanks for Sunday :smile: