OSCommerce Product Manager

OSCommerce Product Manager for Windows

FS#353 - Rounding error when calculating and saving tax and net price

Attached to Project: OSCommerce Product Manager
Opened by Mario A. Valdez-Ramirez (mvaldez) - Friday, 18 December 2009, 13:06 GMT-5
Last edited by Mario A. Valdez-Ramirez (mvaldez) - Thursday, 18 February 2010, 15:37 GMT-5
Task Type Bug Report
Category Backend / Core
Status Closed
Assigned To Mario A. Valdez-Ramirez (mvaldez)
Operating System All
Severity Low
Priority Low
Reported Version any
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


From an email report:

"si yo introduzco 2.50 como precio final impuesto incluido, su programa automáticamente rellena la casilla de precio sin impuesto a 2.1552, y acto seguido al confirmar, redondea esta cantidad a 2.16, con lo que el precio final se guarda con valor 2.5056, 2.51 al redondear."

"If I enter 2.50 as final price with tax, your program automatically fills the net price field with 2.1552, after that when confirming, it rounds up the number to 2.16 and the final price is stored with 2.5056 value; rounded as 2.51."

Pending to review.
This task depends upon

Closed by  Mario A. Valdez-Ramirez (mvaldez)
Thursday, 18 February 2010, 15:37 GMT-5
Reason for closing:  Fixed / Implemented
Additional comments about closing:  Will close it as fixed by harcoding the rounding precision to 4.
Comment by Mario A. Valdez-Ramirez (mvaldez) - Tuesday, 16 February 2010, 14:47 GMT-5

Reviewed, confirmed.

There are two issues here:

1) The main price (which is the one stored in the database) is the Net Price (without taxes), not the Gross Price (with taxes). The reason is that taxes can vary per user, per zone, etc. so in osCommerce they are calculated on the fly. So, in OSCPMWin the Gross Price field is only a convenience for users who want to enter their prices using the price with taxes as reference; we calculate the Net price and store it on the database.

2) The Net Price is calculated from the Gross Price using the selected Tax Class, but the converted number is then rounded using only 2 decimal places, even when the database price field allow for 4 places. This precision (2 decimal places) is hardcoded in the OSCPMWin application. The function FNopm_CleanNumber in dataman.pas is used for the cleanup and conversion of user-entered numbers and inside this function is hardcoded the conversion precision. This is the main source of the reported problem.

We have three options to reduce the rounding error: 1) hardcode a bigger precision (4 would be enough for most uses and is the max precision allowed by the unmodified osCommerce database), 2) use the precision of the main currency (currencies has a decimal_places option), 3) let the user set in a configuration option how many decimal places to use for this calculations.

I feel the second option should be the preferred one.
Comment by Mario A. Valdez-Ramirez (mvaldez) - Tuesday, 16 February 2010, 14:50 GMT-5
However, by now, as a quick fix, we will hardcode a precision of 4.
Comment by Mario A. Valdez-Ramirez (mvaldez) - Tuesday, 16 February 2010, 14:50 GMT-5
Reducing priority.