[FIX] point_of_sale: round product.product price analogous to backend

A rounding issue was resolved in
ee33593351. It however introduced
another issue.

Rounding functions (both round_precision in web.utils and float_round
in openerp.tools) are not perfect due to IEEE floating point
limitations. However both should produce the same output given the
same input. An example: rounding 13.95 to 2 digits yields
13.950000000000001.

The additional rounding introduced in
ee33593351 on price lead to issues in
certain cases. One example occurs when applying a 90% discount on a
product costing 13.95. The POS will do the following:

> 13.950000000000001 * 0.09999999999999998
1.3949999999999998
> round_pr(1.3949999999999998, .01)
1.4000000000000001

whereas the backend will do (as eg. in sale.order.line)

>>> 13.95 * 0.09999999999999998
1.3949999999999996
>>> round(1.3949999999999996, 2)
1.3900000000000001

Causing a difference of 0.01.

The core of the issue is that in the backend 13.95 is rounded
differently. When a Float gets written to the database doesn't just
pass through the regular float_round. It passes through
_symbol_set_float which truncates characters exceeding the precision.

This implements the same approach in the POS.

opw-715506
Closes #16119
This commit is contained in:
Joren Van Onder 2017-03-28 16:42:56 -07:00 committed by Martin Trigaux
parent 5fc3979262
commit 7f260ab517
No known key found for this signature in database
GPG Key ID: 7B0E288E7C0F83A7
1 changed files with 3 additions and 1 deletions

View File

@ -821,7 +821,9 @@ function openerp_pos_models(instance, module){ //module is instance.point_of_sal
this.trigger('change',this);
},
get_unit_price: function(){
return round_di(this.price || 0, this.pos.dp['Product Price'])
var digits = this.pos.dp['Product Price'];
// round and truncate to mimic _sybmbol_set behavior
return parseFloat(round_di(this.price || 0, digits).toFixed(digits));
},
get_base_price: function(){
var rounding = this.pos.currency.rounding;