Before this commit, "document.execCommand" was first
method used when attempting to print, due to a bug
in Safari for Windows (ndr. which is deprecated as
the last version of Safari for Windows is 5.1.7
from may 2012).

On the mobile App, the "document.execCommand('print')"
call returns "true" even if nothing has actually been
done, which therefore prevents from executing "window.print()".

After this commit, we execute directly "window.print()"
as it's supported by all modern browsers (except Firefox Android,
which doesn't support printing at all).

Notes:
* "document.execCommand" is deprecated and the "print" command isn't even documented
* Safari 5.1.7 doesn't support Promise/Async/Await, and therefore not Odoo 13+.

References:
* https://developer.mozilla.org/en-US/docs/Web/API/Document/execCommand
* https://developer.mozilla.org/en-US/docs/Web/API/Window/print
* https://caniuse.com/?search=await
* https://caniuse.com/?search=promise
* https://apple.stackexchange.com/questions/68836/where-can-i-download-safari-for-windows

opw-2486818

closes odoo/odoo#70155

Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>

Because the `receiptHtml` was taken from a component which was mounted outside of the DOM, it was hardly ever destroyed for some unknown reasons and the `el.outerHTML` could not be taken to create the receipt.

closes odoo/odoo#71087

Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

While using the cash rounding, there were issues when rounding up and down.
The pre filled amount was correct but the rest of the transaction was wrong. (Wrong due, wrong change,...)
This commit re calculate the rounding applied when using up or down payment.

closes odoo/odoo#71219

Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

Before, when using the manage order, if a payment method was used and then removed from the pos.config,
we couldn't load the old order anymore because of unknow reference.
To fix this, we load all methods at the opening of the pos but when we display the payment methods we only show those in the pos.config.

closes odoo/odoo#71263

Task-id: 2541708
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

When scanned product is tracked by lot or SN, the popup that asks
for lot should be shown, just like as when a tracked product is clicked
from the product list.

We accomplish this by introducing a new method that can be used both
by `_clickProduct` and `_barcodeProductAction`, and by making the
`_barcodeProductAction` be independent from `scan_product` method
from `PosModel`. So instead of calling directly `scan_product`, we
indentify the product first based on the barcode, then we call the
newly introduced method to ask for the lot inputs, then we call
`add_product` with proper options including the type of the parsed
barcode.

closes odoo/odoo#71209

Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

When identifying whether to show the decrease quantity popup or not,
the current quantity of the selected orderline is compared to the
new input quantity. This fix properly compares the current quantity
to the new input quantity in number format.

Language such as FR recognizes `,` as the decimal separator. However, it is
possible that the keyboard setting is American so the decimal point in the
numpad will send `.` when pressing it. POS should be able to recognize both.
This fix allows `.` sent from keyboard to be interpreted as decimal separator
even at language where the decimal separator is `,`. This is okay because
number inputs in POS doesn't take into account the thousand separator.

Before 03025520b rounding applied was eg. for these numbers and UP and
DOWN rounding methods to multiple of 10:

```
Numbers | -8 | -2 |  2 |  8 | 12
DOWN    | -2 | -8 | -2 | -8 | -2
UP      |  8 |  2 |  8 |  2 |  8
```

which is correct for positive numbers but UP and DOWN are inversed for
negatives numbers.

After 03025520b this became:

```
Numbers | -8 | -2 |  2 |  8 | 12
DOWN    |  8 |  2 |  8 | -8 | -2
UP      | -2 | -8 | -2 |  2 |  8
```

which is correct for all cases except for positive numbers that are
before HALF of the precision (eg. number 2) for which UP and DOWN are
inversed.

This is happening because 03025520b uses the sign of the rounded value
=> this does not work for 0 so number 2 is broken (and if fixed number
-2 would be broken).

With this commit, the adjustement of sign is done based on original
number, so we get the equivalent of python equivalent methods:

```
Numbers | -8 | -2 |  2 |  8 | 12
DOWN    |  8 |  2 | -2 | -8 | -2
UP      | -2 | -8 |  8 |  2 |  8
```

opw-2451841

closes odoo/odoo#70910

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

These changes have been made to be able to add some behaviors in some specific points of the flow when overridden.

The method that computs what is due and the change of an order is based
on the selected payment line which is wrong, because if you add and
remove a payment line, none will be seleced, that lead to issue in this
case because a change is computed, and it won't match the invoices
because an amount_return is sent to server.

To reproduce you can follow this simply procedure:
    - set rounding half-up to 0.05
    - create a product at 0.98
    - open POS and create an order with the product
    - go to payment screen
    - add cash payment (1€ auto filled)
    - add bank payment (It'll autofill -0.02 not really a problem)
    - remove the bank payment => It'll show 0.02 due (it is caused because of no payment method is selected)
    - Set a customer and check the invoice => unbalanced (0.02 probably because it is set in amount_return of the request)

closes odoo/odoo#70825

Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>