Fractional Quantity Sub-Total Rounding Discrepency

[saturate]

We are selling fabric that is cut to length. There is a discrepancy between in the Sub-Total of the Items as they are displayed to the customer (2 decimal places) and the Sub-Total that is calculated using 4 decimal places. Here is the contents of an Invoice:

Products Model Tax Price (ex) Price (inc) Total (ex) Total (inc)
0.5 x Random Pencil Check in Linen CX4840-LINE-D 6% $9.75 $9.75 $4.88 $4.88
0.5 x Medium Cream Dot in Aqua C630-20-AQUA 6% $9.75 $9.75 $4.88 $4.88
0.5 x Medium Cream Dot in Gray C630-40-GRAY 6% $9.75 $9.75 $4.88 $4.88
0.5 x Small Cream Dot in Gray C610-40 GRAY 6% $9.75 $9.75 $4.88 $4.88
0.5 x Small Cream Dot in Orange C610-20 ORAN 6% $9.75 $9.75 $4.88 $4.88
0.5 x Ta Dot in Lime CX1492-LIME-D 6% $9.75 $9.75 $4.88 $4.88
0.5 x Ta Dot in Sea CX1492-SEAX-D 6% $9.75 $9.75 $4.88 $4.88
0.5 x Medium Cream Dot in Navy C630-21-NAVY 6% $9.75 $9.75 $4.88 $4.88
0.5 x Boy Triangles in Aqua C3305-AQUA 6% $9.75 $9.75 $4.88 $4.88
Sub-Total: $43.88
Zone Rates (Shipping to US): $5.50
PA Sales Tax: $2.96
Total: $52.34

Nine products were ordered, .5 yard of each.
Using the price for each displayed to the customer: 9 * 4.88 = 43.92
Using the price calculated under the hood: 9 * (.5 * 9.75) = 43.875

I've been looking at other threads concerning rounding with discounts and taxes, but I have not seen any involving fractional quantities. I understand that in the database and in the code prices are stored to 4 decimal places. But, the invoice only displays 2, if someone adds it up it doesn't add up.

[saturate]

Sorry for the messy invoice data. I added spaces to reformat it, but after I posted all my spaces got removed.

[mc12345678]

Sorry for the messy invoice data. I added spaces to reformat it, but after I posted all my spaces got removed.

So in this case you are concerned that a customer will feel like they have gotten away with a discount and owes you more money? I would say that the problem lies in the pricing not in the calculation. If offering something in partial amounts I would price to the smallest partial amount and multiply across to get the individual unit rather than be concerned that the part of the total doesn't come out, or add some sort of text somewhere to explain what is going on. Otherwise in your scenario, one may want to have the subtotals show up something like 4.88 for the first, and 4.87 for the second and repeat that process for every pair of that item/item type.

Yeah, most conversations on the rounding calculation issues are about those regarding VAT tax where pricesare shown with tax already in the price and a portion of the price is to be shown as the tax that it is... A lot of "variables" and ways for the calculation to go wrong, depending on which organization gets the extra penny on each calculation and a number of other factors.

[lat9]

You might take a look at this thread (no verified solutions, yet, but acknowledgment that a fractional/multiplier/tax rounding issue is present): http://www.zen-cart.com/showthread.p...nding-error%29

[saturate]

I looked at that post. It looked like a lot of code changes in a lot of files and is not yet a proven solution. I'm still new to PHP and trying to figure out the Zen Cart architecture. I've been writing code professionally for over 20 years, but mostly C/C++/C#/VB, motion control, and device interfacing. Did some HTML, Java, Perl, and SQL 19 years ago then my career track shifted. I'm not sure what function does what yet, so I'm cautiously approaching code changes. I'm looking forward to the day when I can answer questions instead of asking them.

For now it's not a big deal, a few cents in the customer's favor. It's just that when math is wrong it may cause people to question the integrity of the site and business.

Thanks, I'll keep studying the post you referenced.

[RixStix]

FWIW, PayPal doesn't like receiving those fractional quantities & associated rounding issues either.

We sell in tenth units are in the process of editing all our product prices in dime increments instead of penny increments in an attempt to lessen the number of PayPal error files.... as suggested by mc12345678. TNX, that was a DUH moment for me.

[frank18]

I looked at that post. It looked like a lot of code changes in a lot of files and is not yet a proven solution. I'm still new to PHP and trying to figure out the Zen Cart architecture. I've been writing code professionally for over 20 years, but mostly C/C++/C#/VB, motion control, and device interfacing. Did some HTML, Java, Perl, and SQL 19 years ago then my career track shifted. I'm not sure what function does what yet, so I'm cautiously approaching code changes. I'm looking forward to the day when I can answer questions instead of asking them.

For now it's not a big deal, a few cents in the customer's favor. It's just that when math is wrong it may cause people to question the integrity of the site and business.

Thanks, I'll keep studying the post you referenced.

Don't be afraid to make changes as long as you make backups of the files and DB before you hack some code.

[frank18]

You might take a look at this thread (no verified solutions, yet, but acknowledgment that a fractional/multiplier/tax rounding issue is present): http://www.zen-cart.com/showthread.p...nding-error%29

Thumbs up, I have implemented my solution (post #14 in that thread) on a couple of sites with satisfactory results