We should open the cashdrawer when paying with a non cash payment
method if change should be returned to the customer.
Use case: The customer wants to pay 10€ more with his card to get 10€
in cash in return.
closesodoo/odoo#65331
Taskid: 2449312
X-original-commit: c324c024d4c5e013b2405b509e91337bd3dc4dc7
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
with this commit we are updating sequence of onboarding tours
task-2444153
closesodoo/odoo#65244
X-original-commit: a928beccb09f4db4234356e5e4f7bdf090ecc964
Related: odoo/enterprise#16026
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Create a product with variants attributes that NEVER create variants.
Configure Variants to add some extra-prices to some variants.
In POS settings activate "Product Configurator" and
"Advanced Pricelists", add the public pricelist and one that applies 5% to
the product.
Open a session and select the product created (say price = 1$)
Select the attributes, the extra-price is added to the product (say the
total price now is 2$).
Change pricelist from public to 5% and the order line will show our
product = 0.95, not taking the extra-prices into account (so not 1.9,
i.e. 5% of the 2$ that were formerly displayed)
opw-2439445
closesodoo/odoo#65222
X-original-commit: 323d2937f1470a85ba9ee5e46595baef426ee3f3
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
For now, when you are selling products in the point of sales, the stock
is affected once the order is validated or the session closed. But in
some case, you don't have the product in your store, and you have to
plan a delivery for the order.
To be able to plan a delivery, you can now choose the warehouse in POS
Config and the routes of your warehouse will be applied. You can also
set a specific rule on your POS Config if you've enabled the
multi-step-routes in the inventory module
closesodoo/odoo#58506
Task-id: 2082104
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Adjustment of a previous commit b1dff85a85
It is possible for the argument to be something else than `undefined` or an array. We're adding a check to prevent an error to occur in that case.
closesodoo/odoo#65098
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
STEPS:
* configure rounding:
- cash_rounding=True
- only_round_cash_method=True
- round method: 1.0 Down
* open a session
* add products with subtotal in decimals (such as 6.35)
* select Bank payment method and process the order
BEFORE: error "You have to round your payments lines"
AFTER: order is processed and marked as paid
---
https://github.com/odoo/odoo/commit/42425996e36d9cb1fc1391402cf6d00df4aea019
opw-2426027
closesodoo/odoo#64351
X-original-commit: db0b65e547defe3d49c1a31c4671f546aa5156e8
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Hi i detected an issue on POS, to reproduce just get into a customer on the POS UI, change something else than the name, then try to save changes, this trigger the if in line 47, making the user to mandatory edit the name field then save again and it works.
The only change on the file is on line 47 where I check if the name is already on the prop so that it works as intended.
Its a mild UX issue with a very easy fix. hope you can upload it soon to the repo so that users on Odoo SaaS or users with no code skills dont have this Issue anymore-
Best regards
closesodoo/odoo#64091
X-original-commit: 94a735ec6a9caa334eca6c4d7a4ca89bf3b5eaf9
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
To reproduce:
1. Start an odoo instance without demo with point_of_sale module.
2. Install a generic fiscal local if not automatically installed.
3. Create a product.
4. Open a pos session.
5. BUG: no search bar
This is because the search bar is rendered inside ProductsWidgetControlPanel
which is only rendered when there are categories. Instead, we render it
always but we pass the hasNoCategory information to selectively render
it's part. This now always show the search bar.
closesodoo/odoo#63551
Opw: 2418858
X-original-commit: bf69c811736a81cd95d4bffc06b23c539e4671e6
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When you have a localisation like the french one that does not allow
you to decrease the value of a line, you cannot make returns because the
popup that shows you new value to encode, does not let you enter
negative numbers.
To allow those negative values, we let the modification of the line if
we are on the last line, and the quantity is equal to 1 which is the
default value of the line. It is the same behavior as in 13.0.
OPW-2411356
closesodoo/odoo#63538
X-original-commit: b6b5e7c148f2b7b44830022325aa9010a4c683ba
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
In some languages, if the thousands/decimals separators are different
from ','/'.' , when scanning a barcode that contains a decimal quantity,
the conversion won't be correct.
To reproduce the error:
1. Go to Settings > Inventory
2. Enable "Units of Measure"
3. Go to Point of Sale > Products > Products
4. Create a Product P
- Set a barcode, e.g. 2112345000008
- Set UoM to 'kg'
5. Go to Settings > Translations > Languages
6. Add and switch to French (BE)
7. Run one POS
8. Use the debugging window to simulate a scan
- Enter the code, e.g. 2112345087550
(It means 8.755kg of product P)
- Click on "Scan EAN-13"
=> Here is the error: it actually adds 8755kg of P-product. This comes
from the quantity conversion. The barcode provides the qty as a number with
basic decimal notation (.) but later, it is converted using the user's
language configuration.
OPW-2412561
closesodoo/odoo#63491
X-original-commit: 6abd50ae8e1b19339163c717705826544e222e13
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: adwid <adwid@users.noreply.github.com>
When you are configuring the picking type used in the point of sale to
not use existing lots and not create lots, the POS still ask you to
encode a lot for product tracked, and the picking created don't use
existing lots in stock because no reservation is made when a picking is
valaidated from point of sale.
As we want to reserve only in this specific case, we are now checking
the options on the picking type to reserve or not product tracked.
We are also not asking anymore for lot or serial number if picking type
is configured that way.
OPW-2377008
closesodoo/odoo#62857
X-original-commit: f9dd1d88d0d24914028464cc12b69ff0878346f8
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Steps to reproduce the bug:
- Connect to Odoo on Safari
- Go in the POS
- Make an order O
- Pay O
- Print the receipt of O
Bug:
Nothing was displayed on the receipt
opw:2391810
closesodoo/odoo#62785
X-original-commit: 50ebca958ab5ab0ea6ab1ec2a54ce8fad488b17a
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Prior to 28762b79e3, `_enableButtons`
method is mainly called after saving changes in the record,
now, it is also called when discarding such that its argument can
become `undefined`. This causes error in pos.config form because it
uses a custom form which hooked to the said method in order to
reload the window when a module_ or group_ field is modified.
This commit prevents this error by having a fallback empty array
when `changedFields` is `undefined`.
closesodoo/odoo#62366
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
It was impossible to validate the cash control popup if the value was 0.
Now it's possible to validate any amount, including 0.
closesodoo/odoo#62256
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
- Create a sale tax T1, 0% included in price
- Create a sale tax T2, 15%
- Create a product PROD1 with a sale price of 10 and T1
- Create a fiscal position FPOS and map T1 to T2
- Go to POS
- Select PROD1:
- Without FPOS the price should be 10 and tax 0
- With FPOS, price should be 10 and tax 1.5
POS calculate the tax twice, makeing the price 11,50 and an extra tax of
15% to 13,23.
This is a fine tuning of 1baa774bc7a1d6cabcb3d61ff19ec2d6010fbd6a
to distinguish between included-excluded tax after mapping and avoid the
double computation.
opw-2374247
closesodoo/odoo#61605
X-original-commit: 65c5b54c19e66674d3df35b651059632c452a6c7
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
This tasks allow to see serial numbers or lot numbers for each products on the order.
It also add the same information on an invoice generated by the POS if the option is ticked in the pos config.
closesodoo/odoo#42410
Task-id: 2154835
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
TLDR: float_round in backend works differently with POS roundings in case of
negative amounts (refunds)
STEPS:
* setup rounding for POS, e.g. 0.1 DOWN
* make refund via POS for an amount with cents, e.g. -129.33
* proceed to POS payment
* BEFORE: is shows -129.40
* AFTER: is shows -129.30
WHY:
* This follows rule ``round(-x) = -round(x)`` -- this way we don't have
difference in absolute values for order and refund.
* See also https://github.com/odoo/odoo/commit/ea2c80cad018da6390ea9d116733de691907e1e4
---
opw-2357917
closesodoo/odoo#61551
X-original-commit: 11541944373de3f35c611cf012a0f65d471d12a5
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When you enable the cash rounding in POS, all your payment methods are
rounded in the POS.
In some countries, only the cash methods must be rounded, so we enable
here the possibility to activate the rounding only on the cash methods.
OPW-2373516 and OPW-2366101
closesodoo/odoo#61312
X-original-commit: 9b03fd67f856ec8e5b37652a5ed551ec159973e5
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
- Go to Point of Sale > Configuration > Attributes and create an Attribute:
* Attribute Name: Attribute X
* Variants Creation Mode: Never
* Attribute Values: Value Y, Value Z
- Create a Product (i.e. Product X) available in POS with the created Attribute and Values
- Configure a POS and enable the following options:
* Is a Bar/Restaurant
* Product Configurator
- Open POS Session and select a table (i.e. Table 1)
- Select Product X and a value for Attribute X
- In the order summary, the value of the attribute appears after product name
- Go to Floor plan
- Go back to Table 1
The values of all attributes don't appear anymore in order summary
In POS front-end, when adding a product, the name of all chosen attributes values
are registered in a variable named "description".
The full product name displayed in the order summary is generated from display_name
of the product and this "description" variable.
When moving to floor plan, ongoing orders are saved in DB and reloaded when moving
back to a table.
As "description" is not saved, regenerating full product name from display_name of
product and "description" is not possible.
However the generated full product name is saved in DB and can be retrieved.
opw-2371965
closesodoo/odoo#61266
X-original-commit: df3061f6e8061cf039bf083f649b7585c8c31df4
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
User is not allowed to save an empty name for the customer details.
If tried, an error message is shown. This feature has been accidentally
dropped after the pos-owl-refactoring. We are restoring this behavior
in this commit.
closesodoo/odoo#60813
X-original-commit: 025d2c9685af74f7ef00530966cb5fb306a31085
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Joseph Caburnay (jcb) <caburj@users.noreply.github.com>
TLDR: zero is not always zero in js
STEPS:
* On your POS, add a Cash rounding > Rounding precision 0.10 > Rounding method
DOWN
* Set a product with a Unit of Measure with 3 decimals (kg for instance)
* In POS:
- Make an order for 0.514 kg at 429.99€ + 0.510 kg at 429.99 + 0.60€
- The total of the order is 440.90 (exact total would be 440.90976)
BEFORE: The total to pay is 440.80
AFTER: The total to pay is 440.90
WHY:
* var total = round_pr(this.get_total_with_tax(), this.pos.cash_rounding[0].rounding);
// 440.90000000000003
* var rounding_applied = total - this.get_total_with_tax();
// 5.684341886080802e-14
---
opw-2357917
closesodoo/odoo#60754
X-original-commit: 262a9dc935d74b30ffeaff6d6d88aac150793d6e
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
In a POS session, in a language that does not use dot (.) as decimal separator (i.e. French),
when adding a Product, it can happen that the decimal part of the price is not converted
correctly after applying "field_utils.parse.float". (i.e. 2.69 becomes 269)
The issue happens in "set_unit_price" function.
To prevent this to happen, "field_utils.parse.float" will only be applied if the price given
as parameter is not a number.
opw-2357848
closesodoo/odoo#60344
X-original-commit: 7687732a8a2e1afe87272fc31ccd4437ed9a8db1
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
When you hava a fiscal position that that map one tax included into the
price to another, the new amount is wrong.
I we have a fiscal position that map a tax of 10% included to 20%
included, and a product at 110$ having 10% included. When we map the tax
from 10% to 20%, the new price is 100$ but should be 120$.
This is because for now, the price is fixed to get the amount without
tax, which perfectly works when destination tax is tax excluded. But
when you call compute_all from a price with a tax included (20%) it keep
the price and compute the tax amount out of this price.
So to fix this issue, whent the origin tax and destination tax are
included, we are computing the base amount (like before) and then we
compute the new tax amount wihtout trying to find the tax amount out of
the price.
This will lead to have the same behavior between accounting and POS
closesodoo/odoo#60312
X-original-commit: f8737b4676ea86abc0f39e448849453f28d4b10f
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Move the cashbox opening control from the left panel of the product screen widget to a popup that is raised at the opening of the session if its state is: opening_control.
task-id: 2321973
Since odoo/odoo@c6397ab3b3, the printer.js
file has been refactored, and if the connection to the IoTBox failed,
the error popup could not be displayed because Gui was undefined.
Steps to reproduce on the runbot:
- Configure your POS session with an IoTBox with receipt printer and
cashdrawer
- Open your POS session
- Skip the connection to the IoTBox
- Proceed to payment
- Open the cashbox
- Error: Gui is not defined
This commit fixes the behavior by displaying the error properly.
In line with this fix, we are also putting the printing assets back in
the point_of_sale.assets because pos printing in the backend is no
longer needed.
closesodoo/odoo#60087
X-original-commit: 063e617a832d582d460dee0fcb54d837f3cafb1c
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
- Activate debug mode
- Go to Settings > Translations > Languages
- Activate and switch to a language that does not use dot (.) as decimal separator (i.e. French)
- Go to a POS session
- Select a Product, edit the price with a decimal via the Numpad widget
The decimal is not taken into account.
This is due to the fact that the entered input ('.') is not considered as the decimal point
in this language (i.e. ',') and is skipped.
The same issue happens for quantity and discount.
The dot in the Numpad widget has been replaced by the decimal separator of the language.
Also "field_utils.parse.float" has to be used instead of "parseFloat" because "parseFloat" only
recognizes a dot as separator. (i.e. "parseFloat" returns 12.00 for "12,99")
Howerver "parseFloat" is still useful for checking values as "field_utils.parse.float" returns
an error if its parameter is not a string or if the parsed result is not a number.
opw-2357848
closesodoo/odoo#59971
X-original-commit: a1543d2a283000e2955df5f8131bae5e25e110c0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In this commit, we restore the following behavior from v13: when search
resulted to a single product and 'Enter' key is pressed, the product is
added to the order and the search field is cleared. This works for both
manual keyboard input and barcode input.
closesodoo/odoo#59770
X-original-commit: 225e3898f25ddac061be99c43501c99d4bd3226b
Signed-off-by: Joseph Caburnay (jcb) <caburj@users.noreply.github.com>
When searching in the order management screen, we only include
results from orders saved in the server, which excludes the
orders currently saved locally. In this commit, we allow the
search to include those locally-saved orders.
closesodoo/odoo#59539
X-original-commit: 0fd87bca3041e680deb628e1952e995e4a2dba54
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Create few validated orders. Then create other orders such that the
validated orders will be found at page 3. Search for an order
from the validated orders. BUG: You will see these searched orders
in page 3.
This commit fixes this issue by putting the search results in
page 1.
X-original-commit: 0a400313136ff7a7359d6105200522e859ce865d
And other reported English mistakes in source string
Courtesy of Transifex translators
And remove leftover from gengo
closesodoo/odoo#59022
X-original-commit: 26efc84c5cac47a2cc83d7b084f8b71528fec6c7
Related: odoo/enterprise#13781
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
- Set the company country to India
- Open th POS, make a sale
- Print the receipt
The label for the VAT is 'VAT' while it should be 'GSTIN'.
The `VAT:` label is hardcoded in the receipt template. It is expected to
be adapted to the localization thanks to the translation. However, in
this case it doesn't work: since we keep the English language, there is
no translation applied.
We use the country `vat_label` and fall back on the `VAT` string.
opw-2343652
closesodoo/odoo#58864
X-original-commit: bfe3a127f5535e11cc87ebd0fff4a5cfe5039a23
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Have a lot of res_partners (more than 100,000)
- Search for a customer
Bug:
The app freezes while searching
opw:2302765
closesodoo/odoo#58469
X-original-commit: 7c7269fa6152795ffaf6a0c8e9c2261d7ca8aaae
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
Replace save buttons in each module field in pos.config with a message.
Saving the pos.config form when a module_ or group_ field is modified
will reload the page.
closesodoo/odoo#51535
Related: odoo/enterprise#10669
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The customer display could not be loaded when no order was set.
(e.g. While showing the floor plan in pos_restaurant)
closesodoo/odoo#57531
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Change the default rouning digits of all UoMs to be two, also change the
decimal.precision of UoM to be two. Adapt all the tests.
Also to avoid hardcoded digits in `should_consume_qty` widget.
PR #56000
X-original-commit: 460ec0402a2352a5b179d81935f7230f6bc97cb7
Initial rendering of order management screen shows the list of orders
based on the previous render. This is done so that during fetching of
new orders from the server, a list of orders are already shown.
This optimization causes a random runbot error when transferring an
order from one table to the other. The moment the order management
screen is open, it will render orders with the old table, but right
after fetching of orders, the listed orders are immediately updated.
To rectify the random error, we modify the test so that instead of
immediately clicking the transferred order, we wait for its new table
to show before selecting it.
closesodoo/odoo#57104
X-original-commit: 713dd3777ca0ce9d121d5162a3d63de3237509f4
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Joseph Caburnay (jcb) <caburj@users.noreply.github.com>
Have a default db in US (date format mm/dd/yyy)
Change the user lang in UK (date format dd/mm/yyyy)
Go to POS, make a sale.
On the receipt screen, the receipt footer will display the date with the
US date format.
opw-2325382
closesodoo/odoo#57060
X-original-commit: 65e15d6baed602ee026825c7331d565688c4aecd
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
The only reason the customer facing display was a field was that the
customers were able to modify it. As this feature is has been removed,
we can turn it into a Qweb template.
We also remove customer_facing_display.scss as it wasn't used anymore
When we make a request to /hw_proxy/sanner there are a timeout of 7,5 sec
After this timeout we wait for 5 sec before send another request.
And we clean the queue of barcode in IoT Box after 5 sec.
So if a cashier scan a product between this "gap" the product is not added to the POS
With this commit we remove the delay before send another request.
closesodoo/odoo#57019
X-original-commit: 13367ebd673c6941c8e06d99f2b66ca535ab4b3b
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
HTTPS had been disabled on SaaS to allow the use of the IoT Box that
had no valid SSL certificate. As of V13.0, IoT Boxes connected to
Enterprise DBs have a valid certificate. POS can then use HTTPS.
Nginx is configured to redirect all requests to `/pos/web` to HTTP,
so we change the POS URL to `/pos/ui`, except when using a Six
payment terminal as it only works in HTTP.
closesodoo/odoo#56933
Taskid: 2191878
X-original-commit: 8aee4992778fee5e2f146c4cff8b35e83c7f56b3
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
Antoine Prieels