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
The POS uses FastClick to circumvent the 300ms touch delay implemented
by browsers before a click event is fired. (Although this has since been
removed, probably we can get rid of this in the POS at some point as
well [1]).
The way FastClick works is simple: immediately fire a synthetic event
and block the one fired by the browser 300ms later.
Recently, browsers have started to only trust native events to trigger
default actions [2][3]. Chrome in particular has started not trusting
synthetic events since v53.
FastClick provides a solution for this with the needsclick class. It
will not interfere with events triggered on elements with this class.
[1] https://developers.google.com/web/updates/2013/12/300ms-tap-delay-gone-away
[2] https://w3c.github.io/uievents/#trusted-events
[3] https://www.chromestatus.com/features/5718803933560832Fixes#14886
Chrome 50 treats percent-height divs inside of auto-height cells as
auto [1]. So from now on it's important that an explicit 'height: 100%' CSS
property is set on parent tds, otherwise you'll end up with elements
with a height of 0.
An extra difficulty is that this new height property on
subwindow-container will result in the element being as high as his
parent table. So the collapsed trick doesn't work anymore in the
customer list.
This has to be done conditionally. The proposed workaround of adding
100% height to parents of affected elements causes issues in IE/Edge
because the effect of adding a height in percent to a table-{cell,row}
element is not defined by CSS [2].
DO NOT FORWARD-PORT!
[1] 8876584335
[2] http://stackoverflow.com/a/27384730
Edge >=12 throws an error (code 800a025e) when calling the select()
method on an input element that is not currently part of document and
has a non-empty value.
When adding a paymentline a "change:selected_paymentline" event gets
triggered which in turn triggers the focus_selected_line function before
the actual paymentline gets rendered.
opw-671426
When we render the payment screen the current value of the current
paymentline is rendered to a string using
Paymentline.get_amount_str(). This conversion always rendered numbers
with a decimal separator of '.' because it just used
Number.toFixed(). This used to be fine but
5a10903e9b made the POS adhere to the set
decimal and thousands separator. Because of this, the POS now has to
parse the input with web.parse_value() which takes into account these
separators. When parse_value() parses a float it first deletes the
thousands separators and then replaces the decimal separator with '.'
before it gets cast to a Number.
In German (and other languages), the '.' is used as a thousands
separator which means that it will get deleted by parse_value() so
you'll end up with '12.34' being interpreted as '1234'. Because of this
it is important that we ensure that the default value that appears in
the input uses the correct separators.
The aforementioned issue only occurs when the user changes the default
value in the paymentline. Only then does a conversion take place from
String to Number. So just clicking on a payment method of type 'Bank'
and validating it would work fine, only when the payment amount was
updated would the issue occur.
Fixes#9395Closes#10952
note: this should not be forward-ported to >8.0 because later versions
use the rewritten payment screen which is completely different from the
one in 8.0.
In an environment where multiple database are available the company_logo
controller in the web module will return a placeholder logo (the Odoo
logo) if it can't figure out what db the request belongs to. This logo
is used on the ESC/POS receipts.
Because we load the logo with an anonymous CORS request there is no
authentication on the request. This is necessary because the POS tends
to not be served over HTTPS whereas the rest of Odoo is. Without this
crossOrigin attribute we could potentially end up in a situation where
the canvas is considered tainted by the browser which would prevent us
from extracting the canvas' data with toDataURL(). So removing the
crossOrigin attribute is not an option, specifying the db is the next
best thing.
opw-670471
note: in >=9.0 session is a variable defined in the js module instead of
a property on PosModel, so 'self.session.db' should become 'session.db'.
The product price unit should be rounded before being used in any
operation. The PoS calls the method `read` in order to get the necessary
fields. However, the product price is a non-stored calculated float. In
old API, such a field is not rounded by the `read` method. It means that
a product price of 28.067 (for example thanks to the use of a pricelist)
will be rounded to 28.07 at the server level but not rounded in the PoS
JS layer.
To lower the impact of the fix, the rounding is done at the JS level,
and not in the `_product_price` method.
opw-669024
Version 7 (and saas-3) had a self-checkout mode that was removed in
8. There are still some fields that reference the feature in
point_of_sale.py but they're obsolete and unused in the
frontend.
Both README.md and static/description/index.html (and thus
odoo.com/apps) still referenced these features.
opw-666328
When uploading an image in the client list in the POS with Firefox an
error was thrown complaining about event not being defined.
jov note: the reason it worked in other browsers like IE and Chrome is
that in those browsers `event` resolves to `window.event`. In Firefox
this doesn't happen which is why JQuery provides us with the event in
the callback function.
closes#10078
On the PosTicket receipt (non-ESC/POS receipt) we have a line titled
subtotal. The subtotal was calculated with getSubtotal(). The issue is
that getSubtotal() ends up just using the price of the product. This
doesn't make sense when taxes are included in the price, because then
the subtotal will contain taxes.
It's not an issue on the ESC/POS receipt, because there we don't show
the subtotal at all if we only have included taxes.
fixes#10137
opw-660266
This revision is related to 5a10903e9b.
The above revision makes so the decimal separator from the language
is used to display the prices.
This revision makes so this decimal separator is used as well
for quantities, to be coherent.
opw-657591
In the pos interface,
when adding a product to the order,
the quantity was set to `1`,
but, when adding the same product again,
the quantity was set to `2.000`.
We use `set_quantity` to not
copy/paste what is already done
in this method to display
correctly the quantity within
the product unit of measure rounding.
The product search field already handle product scanned by a code bar
(by adding it if it corresponds to only one product to the order) so
when the barcode is entered in this search input, the scan doesn't need to
be done.
closes#8433
opw-648856
In backend, the method "_unit_compute" doesn't round the fixed tax amount
before adding to "cur_price_unit" in the case "tax.include_base_amount".
opw:644421
The price without taxe must be rounded on each line like 'price_subtotal' in "sale.order.line"
with digits_compute= dp.get_precision('Account').
The total taxes included must be the sum of the rounded total without taxe and
the rounded taxes like in "sale.order" in _amount_all.
opw:643254
When rounding globally, the function compute_all in charge to compute the taxes for
each line uses a very high currency rounding to avoid rounding per line.
The round must be done on the sum of each total amount line with taxes. To validate a payment with the pos,
the function is_paid verified that this sum is the same that the amount just paid.
Inspired from "sale.order.line", the precision of 'price_unit' and 'price_subtotal' in "pos.order.line"
must be taken from 'Product Price' to avoid rounding per line.
ps: we could not use the function get_all_prices to round globally because it used on every line.
Fixes#6681Closes#6682
opw:639686
This is related to revision bb913d0.
':' in product names are removed, to avoid issues when
searching products with ':' in their name.
JS replace method only replaces the first occurence, if the
needle isn't set as a regex with 'g', e.g. /':'/g
opw-634547
By default, the point of sale awlways uses the rounding method per line.
But the accounting configuration allows to use the globally rounding method,
this is why the point of sale must consider this configuration.
Inspired from the compute_all of account.tax model within
addons/account/account.py.
opw:632537
The box "Tax on children" was ignored in the pos, leading to 100% taxes for these
taxes (as amount is 1.0 on these taxes).
Add child tax fields when loading the pos to be able to correctly compute
recusively the tax amount on children.
Courtesy of Jean-Nicolas Brunet
Fixes#1515, lp:1231574, opw 622143
Debian does not allow fetching data from external website at runtime.
This fixes the privacy-breach-generic lintian warnings for Debian packaging.
The removed youtube url was a dead link...
Some .xml,.csv,.po,.woff,.ttf,.png,.eot,.svg had perm 755, provocating
'executable-not-elf-or-script' lintian warning for Debian packaging.
Set permission to 644 for those files.
Also remove unnecessary executable permissions on some .py:
-addons/l10n_fr_hr_payroll/report/fiche_paye.py
-addons/l10n_ro/res_partner.py
-addons/l10n_ro/__openerp__.py
-addons/l10n_ro/__init__.py
-addons/l10n_do/__openerp__.py
-addons/l10n_do/__init__.py
Joren Van Onder
Nicolas Martinelli
Juan Carlos Montoya
Denis Ledoux
Nicolas Lempereur
Goffin Simon
Julien Legros
Alexis de Lattre
Tam Vu
Stéphane Bidoul (ACSONE)
Frédéric van der Essen
Martin Trigaux
Martin
Yenthe666
Aaron Bohy
Frédéric Van der Essen
Alexis de Lattre
Mario Arias Badila