Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Why do we have 4 decimal places?


Remulon

Recommended Posts

Posted

Hi all,

 

Here is an example of a problem that I am having:

 

When someone adds a product to their cart, if they are not using the default currency, the item sub-total does not equal the quantity * unit_price.

 

Let's say I have a product that costs $4.0000 in my default currency, and after converting to another currency it costs $4.0068

 

If a customer purchases 100 pieces of the item, in their cart it displays like this:

100 x Item1 = $400.68

 

On the printable invoice, it shows the unit price as well, and looks like this:

100 x Item1 ($4.01ea) = $400.68

 

Really, if the unit price is $4.0068 and it rounds to $4.01, the sub-total for 100 items should be $401.00 in my opinion.

 

Does anyone know why all price fields have 4 decimal places? Or why all calculations are made using 4 decimal places?

Has anyone reduced their cart to have only 2 decimal places? Or does anyone know of a different fix for this?

 

Thanks.

 

Remo :)

Posted

Rounding before multiplying is just "bad math".

 

Read this:

 

Click Me

 

When the exchange rate isn't nearly as equal as your example, rounding before multiplication produces some wildly varying results, as in the link I posted.

 

If the shoe was on the other foot (i.e. you were the customer), how would you like it to calculate the price?

:unsure:

 

Granted, in your example, the difference was only $.32

 

In the link I posted, it was 5.25 Pesos because of rounding before multiplying.

 

It works as it should (from both a mathematical and ethical standpoint) IMHO.

If I suggest you edit any file(s) make a backup first - I'm not perfect and neither are you.

 

"Given enough impetus a parallelogramatically shaped projectile can egress a circular orifice."

- Me -

 

"Headers already sent" - The definitive help

 

"Cannot redeclare ..." - How to find/fix it

 

SSL Implementation Help

 

Like this post? "Like" it again over there >

Posted

Thanks for the ethical argument there Jim.

 

And obviously I know it is correct from a mathematical point of view. BUT ONLY IF YOU NEVER ROUND ANYTHING and keep all decimal places.

 

Here is my example, in more detail:

 

100 x Item1  [base:  4.0000 AUD  (4.0068 USD)]  [price_excl:  4.0000 AUD  (4.0068 USD)]  [item_total_excl: 400.0000 AUD (400.6812 USD)]
10 x Item2   [base:  5.0000 AUD  (5.0085 USD)]  [price_excl:  5.0000 AUD  (5.0085 USD)]  [item_total_excl:  50.0000 AUD  (50.0851 USD)]
1 x Item3	[base: 14.8700 AUD (14.8953 USD)]  [price_excl: 14.8700 AUD (14.8953 USD)]  [item_total_excl:  14.8700 AUD  (14.8953 USD)]

																										 Sub-Total: $465.66 USD
																										 Shipping:   $13.87 USD
																										 Tax(10%):   $47.96 USD
																										 TOTAL:	 $527.49 USD

 

And this is what the customer sees:

 

100 x Item1  [unit_price:  4.01 USD]  [item_total_excl: 400.68 USD]
10 x Item2   [unit_price:  5.01 USD]  [item_total_excl:  50.09 USD]
1 x Item3	[unit_price: 14.90 USD]  [item_total_excl:  14.90 USD]

										Sub-Total: $465.66 USD
										Shipping:   $13.87 USD
										Tax(10%):   $47.96 USD
										TOTAL:	 $527.49 USD

 

Now, can you tell me that the item totals add up to be the Sub-Total? From a mathematical point of view?

 

If you ask me THAT is bad math.

Posted

Go to your admin control panel Localization -> Currencies and edit your currencies to use 4,5 6,7 or 8 decimal places. They should then display with greater precision. But then all displays of a currency using greater precision will display this way.

For ALL problems, please review this link first -> osCommerce Knowledge Base

Posted

Thanks Dan,

 

but I really don't see this fixing the problem... (unless I were to change the amount of decimal places on the currency conversion rates to 2 - which is not really acceptable).

 

The way I see it, more decimal places on the currency conversion rates will actually give a higher precision.

 

My main beef is that all ather price fields have 4 decimal places, and I can't see why we would ever need that.

Posted

To minimize rounding and conversion errors and there are those who need the fractions in their product prices.

 

Internally, php manipulates all numbers as double precision values. Why would _we_ ever need that?

For ALL problems, please review this link first -> osCommerce Knowledge Base

Posted
Thanks for the ethical argument there Jim.

 

And obviously I know it is correct from a mathematical point of view. BUT ONLY IF YOU NEVER ROUND ANYTHING and keep all decimal places.

 

Here is my example, in more detail:

 

100 x Item1  [base:  4.0000 AUD  (4.0068 USD)]  [price_excl:  4.0000 AUD  (4.0068 USD)]  [item_total_excl: 400.0000 AUD (400.6812 USD)]
10 x Item2   [base:  5.0000 AUD  (5.0085 USD)]  [price_excl:  5.0000 AUD  (5.0085 USD)]  [item_total_excl:  50.0000 AUD  (50.0851 USD)]
1 x Item3	[base: 14.8700 AUD (14.8953 USD)]  [price_excl: 14.8700 AUD (14.8953 USD)]  [item_total_excl:  14.8700 AUD  (14.8953 USD)]

																										 Sub-Total: $465.66 USD
																										 Shipping:   $13.87 USD
																										 Tax(10%):   $47.96 USD
																										 TOTAL:	 $527.49 USD

 

And this is what the customer sees:

 

100 x Item1  [unit_price:  4.01 USD]  [item_total_excl: 400.68 USD]
10 x Item2   [unit_price:  5.01 USD]  [item_total_excl:  50.09 USD]
1 x Item3	[unit_price: 14.90 USD]  [item_total_excl:  14.90 USD]

										Sub-Total: $465.66 USD
										Shipping:   $13.87 USD
										Tax(10%):   $47.96 USD
										TOTAL:	 $527.49 USD

 

Now, can you tell me that the item totals add up to be the Sub-Total? From a mathematical point of view?

 

If you ask me THAT is bad math.

No, it's bad programming.

 

It's rounding in some places but not everywhere.

 

When dealing with currency exchange, I think it should show 4 decimal places everywhere until the final price.

 

The final price should be the only thing rounded to two places.

 

But that's my opinion, and since I'm not head of International Commerce it probably won't happen.

If I suggest you edit any file(s) make a backup first - I'm not perfect and neither are you.

 

"Given enough impetus a parallelogramatically shaped projectile can egress a circular orifice."

- Me -

 

"Headers already sent" - The definitive help

 

"Cannot redeclare ..." - How to find/fix it

 

SSL Implementation Help

 

Like this post? "Like" it again over there >

Posted
No, it's bad programming.

 

Ok Jim, there is something we definately agree on.

 

I think that we should either:

Option #1: round the unit prices to 2 decimal places, in which case we could display 2 decimal places everywhere. Or,

Option #2: round only the final total to 2 decimal places, in which case we should display 4 decimal places everywhere and display only the total with 2 decimal places.

 

After searching for this through the forums, and eventually starting my own thread, I get the feeling that everyone else is happy to have these discrepancies in their shopping carts.

 

Is this the case? Is it just me that wants to have all items and totals to add up in a nice and clean manner?

 

Has anyone else noticed this in their carts?

 

 

I think that I am going to go with option 1 above, and reduce the number of decimal places in all my database fields to 2 that way, any calculations in my default currency will be correct.

 

Then I will run through the code and make sure that when a customer is not using the default currency, all calculations of unit prices are rounded to 2 decimal places, therefore all item totals will have only 2 decimal places and the item sub-total will then have only 2 decimal places. Therefore, regardless of what currency the customer has selected, all prices will only have 2 decimal places.

 

I guess the only possibility of more that 2 decimal places would then arise during tax calculations, in which case I will ensure that all tax calculations are rounded to 2 decimal places as well.

 

Can anyone see any flaws in my proposed solution? Or has anyone done this modification to their cart in the past?

Posted

I've never had to deal with currency exchange rates, so I don't know what the answer is.

 

Just be aware that if you round before you multiply, the larger the multiplication is the farther the result gets from the "true" answer.

 

It's just a mathematical fact.

 

You could look at it this way: Because of the fact you have to round somewhere you're bound to be .01 off somewhere eventually, so maybe people don't care if the end result is off by .01 (in any currency).

If I suggest you edit any file(s) make a backup first - I'm not perfect and neither are you.

 

"Given enough impetus a parallelogramatically shaped projectile can egress a circular orifice."

- Me -

 

"Headers already sent" - The definitive help

 

"Cannot redeclare ..." - How to find/fix it

 

SSL Implementation Help

 

Like this post? "Like" it again over there >

Posted
I've never had to deal with currency exchange rates, so I don't know what the answer is.

 

Just be aware that if you round before you multiply, the larger the multiplication is the farther the result gets from the "true" answer.

 

It's just a mathematical fact.

 

You could look at it this way: Because of the fact you have to round somewhere you're bound to be .01 off somewhere eventually, so maybe people don't care if the end result is off by .01 (in any currency).

 

Thanks Jim.

 

You're absolutely correct, I don't think that the customers will mind if the 0.01 is in their favour. But the main issue is when the 0.01 is not in their favour.

 

In my experience, customers complain and some will even go to the ends of the earth to dispute credit card transactions, thinking that we are trying to rip them off by 0.01, causing more work for our customer service department and endless headaches for me. It is this small percentage of people that has caused me to look into this problem so deeply.

 

Other than the two possible options that I posted above, I am at a loss as to how to get this problem rectified.

 

Maybe a Moderator or Board Admin could shed some light on this issue?

Posted
In my experience, customers complain and some will even go to the ends of the earth to dispute credit card transactions, thinking that we are trying to rip them off by 0.01

I can see that happening.

 

I know what I would do.

 

I'd fix the code so it showed 4 decimal places everywhere, except for the final result (total bill) being rounded (or truncated) to two places.

 

Now that I just typed the word "truncated", and thought about it a bit, maybe that's the only way to keep people off your back about the bill being .01 off.

 

If you display all the results to 4 decimal places, but at the end (final bill) throw out the last two they can't complain. Of course you "cheat" yourself out of a penny here and there. On the plus side, they can't dispute the bill.

 

Maybe it is "Internationally acceptable" to calculate to 4, then round to two.

 

Beats me!

:lol:

If I suggest you edit any file(s) make a backup first - I'm not perfect and neither are you.

 

"Given enough impetus a parallelogramatically shaped projectile can egress a circular orifice."

- Me -

 

"Headers already sent" - The definitive help

 

"Cannot redeclare ..." - How to find/fix it

 

SSL Implementation Help

 

Like this post? "Like" it again over there >

Posted
If you display all the results to 4 decimal places, but at the end (final bill) throw out the last two they can't complain. Of course you "cheat" yourself out of a penny here and there. On the plus side, they can't dispute the bill.

 

Yeah, that would be the most accurate way of working it out.

 

But then I run the risk of confusing my customers and then having them complaining about too many decimal places.

I think that many of my customers are not so mathematically minded, and they wouldn't realise that it is actually for their benefit.

 

So I am in the process of making the change to 2 decimal places as we speak.

 

I will let you know how it goes in my next post or so.

 

Thanks for your help, and point of view Jim.

Posted

Ok, I have done some changes to my database, and also my code.

 

After much deliberation, and hair pulling, I think I have found out what is contributing to my problem more than anything.

 

It is that the conversion rate is applied to the products and totals separately. What a lunatic method that is!

 

The way I see it, the conversion rate should be applied to the unit price of all products and the shipping only.

 

That way all totals should then be correct.

 

Of course the totals are going to be out if (pseudo code):

converted_price = round(final_price * conversion_rate)

converted_item_sub_total = round((final_price * qty) * conversion rate)

 

Wouldn't it be better to (again pseudo code):

converted_price = round(final_price * conversion_rate)

converted_item_sub_total = converted_price * qty

 

What is anyone's standpoint on this?

  • 1 month later...
Posted

Have you found a fix to this yet? Your problem is very similar to what I am having.

 

 

Ok, I have done some changes to my database, and also my code.

 

After much deliberation, and hair pulling, I think I have found out what is contributing to my problem more than anything.

 

It is that the conversion rate is applied to the products and totals separately. What a lunatic method that is!

 

The way I see it, the conversion rate should be applied to the unit price of all products and the shipping only.

 

That way all totals should then be correct.

 

Of course the totals are going to be out if (pseudo code):

converted_price = round(final_price * conversion_rate)

converted_item_sub_total = round((final_price * qty) * conversion rate)

 

Wouldn't it be better to (again pseudo code):

converted_price = round(final_price * conversion_rate)

converted_item_sub_total = converted_price * qty

 

What is anyone's standpoint on this?

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...