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 Sales Details report wizard gives the possibility
to print the details of the POS orders between two dates.
The fields in the wizard are of type `date`,
while the orders dates are of type `datetime`.
`00:00:00` and `23:59:59` were naively added
to the `date_start` and `date_end` (respectively) to
handle the case.
But, this doesn't take care of the user time zone:
When a user choose between February 24th and February 25th,
it's within his time zone, and therefore, for the search,
where the datetime are in UTC, adding `00:00:00` isn't enough,
the dates have to be converted from the user time zone
to UTC.
opw-6698831
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
The POSBox attempts to maintain whatever Wi-Fi connection it has as best
it can. When it loses it's current Wi-Fi connection it will attempt
to recreate it every 30 seconds. This works well, but a side-effect of
this is that it'll also print a 'Could not connect to LAN' ticket every
time it fails. If you where to leave the POSBox with Wi-Fi on for an
extended period of time you could return to a lot of 'Could not connect
to LAN' tickets.
This makes it so that the 'Could not connect to LAN' ticket only gets
printed once upon connection loss. Although it would be simpler to just
not print this ticket at all when losing connection, it is very useful
to know when the POSBox has lost connection. Otherwise when it loses
connection it would stop working and noone would know why.
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 creating a tax movement, the sign of the amount tax must be
the tax_sign in the normal case or ref_tax_sign in the refund case.
Inspired from the function create defined in model "account.move.line"
opw:658378
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.
People sometimes have an open POS client (/pos/web) which is associated
to a closed POS session. This causes multiple issues. The most important
problem occurs when a user closes the session and opens a new session
without refreshing the POS client. When doing this new POS orders will
become part of the old, already closed session and no new accounting
entries will be generated.
In order to fix this we make sure to check that the session that's
associated with the order that we get from the client is still open. If
it isn't we'll try to find a new, compatible session and add the order
there. If we cannot find a compatible session we'll create a new one
based on the old, closed one. When creating this new session we bypass
the opening_control phase which normally takes care of opening cash
control.
opw-652356
Sometimes it's useful to ssh into a posbox to quickly troubleshoot an
issue. Talking customers through port forwarding is very difficult
however. We use ngrok to solve this issue.
This implements an interface that allows a user to enter an ngrok
authentication token. After this, ngrok can be started and we should be
able to remotely connect.
Note that ngrok does NOT run by default on the posbox. It can only be
started manually by the user.
Every time the posbox boots it would say something like:
This raspberry pi is not configured, please run raspi-config
Which is a leftover from the original raspbian image. Raspi-config is
removed on the posbox because we don't need it.
This allows people to connect the posbox to networks using a wireless
network adapter.
When plugging in a USB Wi-Fi adapter and no network cable, the posbox
will boot and host its own Access Point called "Posbox". Users can
connect their device to this network and can then connect to the posbox
the usual way.
An interface for has been provided that also allows users to instruct
the posbox to connect to a different Wi-Fi network. This is useful when
the client is not running Odoo locally.
It is also possible to make this configuration persistent. With a
persistent Wi-Fi network configuration, the posbox will always try to
connect to the specified network after a reboot.
Attempts have been made to make the Wi-Fi connection as robust as
possible. Upon connection loss, the posbox will automatically attempt to
reconnect.
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