Prices are correct but upon placing order no decimals anymore

[Piemol 0]

Hey All,

 

I've got a strange problem when saving an order.

 

This is debug information from checkout_process.php, just before the order is saved to the database (with tep_db_perform()):

 

 

array(4) {
 [0]=>
 array(5) {
   ["code"]=>
   string(11) "ot_subtotal"
   ["title"]=>
   string(27) "Totaal artikelen excl. BTW:"
   ["text"]=>
   string(11) "€ 167,72"
   ["value"]=>
   float(167,72)
   ["sort_order"]=>
   string(1) "1"
 }
 [1]=>
 array(5) {
   ["code"]=>
   string(11) "ot_shipping"
   ["title"]=>
   string(8) "Afhalen:"
   ["text"]=>
   string(9) "€ 0,00"
   ["value"]=>
   string(1) "0"
   ["sort_order"]=>
   string(1) "2"
 }
 [2]=>
 array(5) {
   ["code"]=>
   string(6) "ot_tax"
   ["title"]=>
   string(8) "BTW 21%:"
   ["text"]=>
   string(10) "€ 35,22"
   ["value"]=>
   float(35,2212)
   ["sort_order"]=>
   string(1) "4"
 }
 [3]=>
 array(5) {
   ["code"]=>
   string(8) "ot_total"
   ["title"]=>
   string(7) "Totaal:"
   ["text"]=>
   string(18) "[b]€ 202,94[/b]"
   ["value"]=>
   float(202,9412)
   ["sort_order"]=>
   string(1) "5"
 }
}

 

The above information is correct, everything is fine, except when it is inserted in the database, the values are missing the decimals.

So "ot_total" gets the value "202.0000", "ot_tax" gets "35.0000".

 

I checked all settings (currencies, taxes) but that shouldn't be a problem, as everything is fine untill the data must be entered in the database.

 

I replaced my code with stock 2.3.3 code (/classes/order.php, /checkout_process.php) checked all relevant other code (classes: shopping_cart.php, order_total.php, currencies.php) , but once again, everything looks fine, the calculated prices must be floats in php, but they won't be accepted by the decimal columns in the database.

 

Of course, in checkout_process.php I can do this:

 

 

$sql_data_array = array('orders_id' => $insert_id,
'title' => $order_totals[$i]['title'],
'text' => $order_totals[$i]['text'],
'value' => number_format($order_totals[$i]['value'], 2, '.', ''), 
'class' => $order_totals[$i]['code'], 
'sort_order' => $order_totals[$i]['sort_order']);

 

But why is it needed there? Why doesn't the stock osCommerce code needs it there?

As far as I read and debugged the code, it should be used in the order class, but it isn't there.

 

What does a stock shop insert in the database on the checkout_process.php by you guys (my localhost isn't working atm)?

And from wich point on do the prices contain dots instead of comma's to be compatible with the database, to be used by tep_db_perform() ?

So where do I have to make sure no comma is in the prices, and what stock oscommerce function should handle that?

 

In the stock code I can't seem to find anything that is 'really' different then mine, and the code that should be responsible is changed to stock but that didn't work out.

 

There are a couple of related (outdated) posts on this subject, but I didn't read any other answers then 'change currency/tax settings', wich isn't the solution here (i guess so).

 

 

Best regards,

 

Leo

[♥ecartz 724]

It seems that your PHP knows about using a comma as a decimal point but your database server does not. The most reliable way is to change each tep_db_perform as you have written. If you'd prefer to hack it, you could try changing two lines in the tep_db_perform function in includes/functions/database.php:

 

		$query .= '\'' . tep_db_input($value) . '\', ';

to

		if ( is_float($value) ) {
		  $query .= '\'' . tep_db_input(number_format($value, 2, '.', '')
) . '\', ';
		} else {
		  $query .= '\'' . tep_db_input($value) . '\', ';
		}

and then

		$query .= $columns . ' = \'' . tep_db_input($value) . '\', ';

to

		if ( is_float($value) ) {
  		   $query .= $columns . ' = \'' . tep_db_input(number_format($value, 2, '.', '')) . '\', ';
		} else {
  		   $query .= $columns . ' = \'' . tep_db_input($value) . '\', ';
		}

What I don't like about that is the hard coded 2. That can be different for different floating point values.

 

You could also try reconfiguring your database server to understand numbers with commas as decimal points. It's hard to say what other effects that might have though.

[Piemol 0]

Hey ecartz,

 

Thanks for your response.

 

Your solution is more centralized then mine, but the 'hard-coded' stuff can be a problem.

So than it's better to number_format() per query.

 

Allthough this is 'a solution', i'm questioning why it's needed for my installation, and not for a stock install.

That is actually my real question.

How come it's needed ? I think it's quite normal to end with floats that has to be inserted in the database.