There were two cases that caused the issue:
Consider a cash rounding with Precision 5 and only cash.

If you have an order that the total amount is 40 and pay 38 by
bank and 0 with cash (cash rounding), it will raise an error.

If you have an order that the total amount is 41 and pay 38 by
the bank and 5 with cash, it will raise another error.

opw-3302114

closes odoo/odoo#121626

Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>

Current behavior:
When a discount is applied on a product because of a pricelist. The base
price is displayed without applying the default pricelist on it.

Steps to reproduce:
- Create product A with price of 10€
- Create pricelsit PL1 that change price of product A to 7€(fixed price)
- Create pricelist PL2 based on PL1 that use a formula to apply 10% on
  all products.
- Change PoS default pricelist to PL1 and make PL1 and PL2 available on
  the PoS.
- Open a PoS session and add product A to the order. Price should be 7€.
- Apply PL2 on the order.
- The product line shows that the price was 10€ has been discounted to
  6.30€. The base price should be 7€.

opw-3200027

closes odoo/odoo#116911

X-original-commit: a515ce4be38b5074cf88b6c084c8cc418e5cc7d6
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>

Current behavior:
When a fiscal position was applied in the PoS, it was considered as a
discount and was shown in the receipt and on the product screen.

Steps to reproduce:
- Create a product with a price of 10€ with 15% tax included in the
  price
- Create a fiscal position that map the 15% tax to 0% tax
- Open a PoS session
- Add the product to the order
- Apply the fiscal position
- The price of the product is now 8.70€ but the order show it as a
  discount of 1.30€ (e.g 10€ -> 8.70€).

opw-3154499

closes odoo/odoo#116053

X-original-commit: bbccf240f0dae32694ca2ff69fc180ab12bd932b
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>

Current behavior:
When you make a purchase that should be rounded down, for example 1.97
rounded down to 1.95. On the payment screen if you select a payment
method and pay with a greater amount than the base amount. The total due
would be rounded incorrectly to 2.00 instead of 1.95.

Steps to reproduce:
- Create a product with a price of 1.97
- Set a rouding down method of 0.05
- Open a pos session
- Add the product to the order
- Select a payment method, for example cash and enter an amount greater
  than the base amount, for example 5.00
- The total due will be 2.00 instead of 1.95

opw-3175726

closes odoo/odoo#113428

Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>

Current behavior:
When there is an opening difference, the closing popup does not show it.

Steps to reproduce:
- Create a new POS session
- Add some cash to the register (100€)
- Close the session with the same amount
- Open the session again
- Change the cash amount in the register (80€)
- When closing the session the popup should show the -20€ difference

opw-3101297

closes odoo/odoo#113012

X-original-commit: fef0a13114e4eebb294c8c8008ab0a7c9dfab864
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>

To Reproduce
============
- set cash rounding method to half-up with a value (1 for example)
- create a product available on pos with price (1.61$ in my example)
- on pos select this product and proceed to payment with cash
- with 2$ cash the total will be 1$ and change 1$ which is wrong

Problem
=======
- the function responsible on applying the rounding method doesn't take into
account the rounding method `"HALF-UP"`

Solution
========
- update the function to apply `"HALF-UP"` correctly

opw-3143698

closes odoo/odoo#111469

Signed-off-by: abla001 <abla@odoo.com>

This commit fix the test when different localisation are used to make sure that the public pricelist is used.
Before, when pos_pricelist test was done and some localisation were installed, it could lead to test failure because the default pricelist wasn't correct on the partners.

closes odoo/odoo#109691

X-original-commit: 53e942fd
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

Current behavior:
When a refund order is created, the amount is not rounded the same way
as the orginial order.

Steps to reproduce:
- Create a rouding method with 0.05 as rounding value, with the DOWN
  rounding method
- Create an order with a product of price 1.98
- Validate the order, the price should be 1.95
- Create a refund order for the previous order
- Validate the refund order, the price should be -1.95 but it's -2.00

Solution:
Always act like the order has a positive amount, and apply the rounding
the normal way. Then apply the sign of the original order.
If the remaining amount has a different sign than the original total,
we should invert the rounding method to apply a rounding in the same
"direction" as the original order.

For example :
- Original order is -1.98
- Rounding is applied and the total is -2.00
- After the payment, the remaining is -1.98 - -2.00 = 0.02
- Wich will be rounded to 0.05 wich is not correct, it should be rounded
  to 0.00. So we invert the rounding method to apply a rounding in the
  same "direction" as the original order. If we don't do this the total
  due would have been -1.95 instead of -2.00. And the change would have
  been 0.05 instead of 0.00.

opw-3106656

closes odoo/odoo#108859

Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>

Current behavior:
If the PoS has no cash method configured, and you try to make a
payment with a greater amount than the due amount, you will get an
error message. Because you cannot give money back to the customer as you
have no cash method configured.

Steps to reproduce:
- Remove Cash payment method from the PoS
- Open a PoS session
- Create an order with some products
- Pay the order with a greater amount than the due amount
- Validate the order, you will get an error message

Solution:
If the Pos has no cash method configured, and the user try to make a
payment with a greater amount than the due amount, we will automatically
set the amount to pay to the due amount and show a message to the user.

opw-3061612

closes odoo/odoo#107365

X-original-commit: ff6bb9d362aefc64770c09b3ddd741106d301af3
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>

After this commit, the settings of coupons, promotions,
gift cards and loyalty cards are now managed under a
single one field in PoS Settings configuration. Moreover,
this settings field is "global" and shared between the
eCommerce and Sales app.

task-2959620

closes odoo/odoo#99060

Related: odoo/upgrade#3842
Signed-off-by: Masereel Pierre <pim@odoo.com>

closes odoo/odoo#94125

Related: odoo/enterprise#28648
Related: odoo/upgrade#3695
Related: odoo/documentation#2557
Signed-off-by: Laurent Smet <las@odoo.com>

Small visual changes that should improve the user experience.
The loading demo data popup has been moved to the backend.
Created an Alert Popup that is less aggressive than an Error Popup

closes odoo/odoo#83780

Task-id: 2485062
Related: odoo/enterprise#26104
Signed-off-by: Masereel Pierre <pim@odoo.com>

Task: 2856281

- Remove user_type_id, account.account.type model, internal_type
- Add account_type that is a simple selection field
- Move internal_group and include_initial_balance to account.account
- Because of these changes, type_control_ids on account.journal is also removed

closes odoo/odoo#93212

Related: odoo/documentation#2223
Related: odoo/upgrade#3595
Related: odoo/enterprise#28205
Signed-off-by: Cedric Snauwaert <csn@odoo.com>

Before this commit: If a fixed tax is used for a product with the price
of zero, the tax line sign would be positive and lead to an unbalanced
move. The solution is to use its sign in its context for correct
calculation.
Also, in the PoS front-end, when you want to return a zero amount
product with a fixed tax, its sign would be positive, which is
incorrect.

Steps to reproduce the first issue:

	- Install 'Point of Sale' module
	- Create a new 'Tax' X with a fixed price (e.g.: 1 $)
	- Create a new 'Product' with zero Sales Price
	- Create a PoS session
	- Add the product to the order
	- Close the session

	It creates a line for the "Difference at closing PoS session," and
doesn't prevent closing. But the problem is that the tax capture as
debit is incorrect. The tax for the invoice must be credit.

Steps to reproduce the second issue:

	- Install 'Point of Sale' module
	- Create a new 'Tax' X with a fixed price (e.g.: 1 $)
	- Create a new 'Product' with zero Sales Price
	- Create a PoS session
	- Add the product to the order
	- Change the quantity to -1 (refund)

	The final amount is positive, while it should be negative.

Solution

	The sign must be sent in the context, and for the PoS front-end, it
should consider zero amount cases.

opw-2833590

closes odoo/odoo#95067

X-original-commit: c5fb4f778db95fb33845b9a5e0c2190d4d9037ee
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>

This change removes the `barcode_nomenclature_id` in the `pos.config`.
Each pos session now starts based on the company's barcode nomenclature.

closes odoo/odoo#93072

Task-id: 2849415
Related: odoo/upgrade#3575
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>

Purpose:

- Move PoS settings in general settings to be consistent with the rest
  of Odoo (PoS being the only app where settings are split in two locations)
- Clean settings by enabling obvious settings or dropping unnecessary ones.

closes odoo/odoo#84719

Task-id: 2753430
Related: odoo/upgrade#3260
Related: odoo/enterprise#24425
Signed-off-by: Masereel Pierre <pim@odoo.com>

Check COA parameter in the open_session_cb was actually never used

opw-2691615

closes odoo/odoo#80410

Related: odoo/enterprise#22522
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

We are referring to TicketScreen and OrderManagementScreen.
The two screens almost serves the same purpose. There is not much reason
to keep them separate. We combine the two in this commit. Basically,
we remove OrderManagementScreen and its components. Some are kept and
moved to the TicketScreen.

Task-id: 2481404
Part-of: odoo/odoo#75322

See simple test cases in the following spreadsheet:
https://docs.google.com/spreadsheets/d/1mt2jRSDU7OONPBFjwyTcnhRjITQI8rGMLLQA5K3fAjo/edit?usp=sharing

Part-of: odoo/odoo#74870

In some use cases, the seller in point of sale needs to add a note on an
order line that has to be displayed on the receipt. So we've added a
field on the order line to set a note.

The note is also set on the invoice if the order is invoiced.

closes odoo/odoo#71598

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

Part of task 2124952

By using AccountTestInvoicingHttpCommon, we have a setup independant
from the demo datas. This also prevents running tests with incompatible
localization: the tests for l10n with another currency than USD failed
because of the demo datas preventing the change of currency.

Tours with `step_delay` potentially hide errors because of missing tour steps.
This is mainly caused by unfinished renders within the `step_delay` between
two steps. It is possible that the render after the 1st trigger is not yet
finished but the 2nd step trigger already existed in the screen. Because the
render result of 1st step is late and the 2nd step is already triggered, the
3rd step will fail. Note that the 3rd step will occassionally fail because
render of the 1st step is most of the time faster than step_delay but
there is no guarantee that the render is always faster because of occassional
cpu slow downs.

Runbot will eventually catch these tour errors which it did with the ticket
screen tour.

In this commit, we removed the `step_delay` in the pos tours. We also
supplemented the missing step in the ticket screen tour which was the cause
of random runbot error when there was `step_delay`.

We also figured that value property of input element is not observed by the
tour service's mutation observer, which result to an indeterministic error
in a step in tip screen. To fix this, we introduce an attribute to the input
element which is used in the step trigger.

closes odoo/odoo#56961

X-original-commit: 2ef73bb6
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Joseph Caburnay (jcb) <caburj@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.

closes odoo/odoo#56933

Taskid: 2191878
X-original-commit: 8aee4992
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>

closes odoo/odoo#56062

Related: odoo/enterprise#12487
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

Aside from new look, we also move the email option from payment
screen to receipt screen. This allows emailing the receipt to a
customer that is not in the contact list.

We also removed invoicing in the receipt screen during failed invoicing
from payment screen as it is removed in here: bc48e003

closes odoo/odoo#55868

Related: odoo/enterprise#12395
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

The following changes are made in this task:

1. Remove order tabs and replace with ticket list.
2. Top bar color change.
3. Search bar in the product screen is moved in the top bar.
4. List of sub-categories are now in the same line as the category
breadcrumbs.

closes odoo/odoo#55100

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

Configure products with create_variants = 'never' from the POS

closes odoo/odoo#54956

Taskid: 208205
Related: odoo/upgrade#1522
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

We now allow invoicing of finalized orders in an open session in this first
iteration of order management in the pos frontend. Additionally, receipt
reprinting is also introduced. With this feature, we can now reprint the
receipt of old orders.

closes odoo/odoo#51141

Task-id: 1981354
Related: odoo/enterprise#11690
Related: odoo/upgrade#1472
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

To reproduce, open a pos session. Finalize an order with invoicing.
Error message is shown.

Invoicing in pos calls doAction of the action manager. The first time
doAction is called, it triggers a chain of events and a side effect
of that chain is to instantiate two mail owl components which isn't
possible because not all mail assets are loaded. A very quick fix is
to bypass that mentioned chain of events by setting isStarted flag to be
true. Aside from bypassing the instantiation of mail components, there
are procedures that were skipped as well which includes:

1. setting the bus to listen to scroll events
2. setting odoo.isReady to true
3. adding a class to the action manager element

All of the above is not important in pos and can be skipped so this
quick fix is valid. However, this fix doesn't actually solve the real
problem which is the fact the pos is loading unnecessary assets.

This commit implements the quick fix. Cleaning up pos assets will be
done in the future.

closes odoo/odoo#54478

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

closes odoo/odoo#51624

Related: odoo/enterprise#11148
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

Do not make direct CRUD to ir.property records, use appropriate
methods for that

Should only interact with them via python code in a controlled
environment, no direct call with RPC

There is no unique constraint on the properties to avoid having two
properties for the same field, company and res_id.

Having two properties for the same field, company and res_id, leads to
inconsistencies through the code, as reading a company-dependent field
nondeterministically returns one of the available property value.

So now, before creating a property, we have to check that there is not
already a value for the field, company and res_id and write or create
depending on if it is already exists.

The properties of specific records already satisfy the constraint thanks
to the implementation of company-dependent fields that use the method
`set_multi`.  We added a method `set_default` to set generic properties,
and its implementation does the right thing.  It also simplifies the
code to set such properties, by the way.

closes odoo/odoo#40473

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>

This commit makes the email button to behave consistently with the
invoice button. Basically, if there is no selected customer when
invoicing, the UI should direct the user to select a customer. This
behaviour is implemented with the email button with special check on the
validity of the customer email.

closes odoo/odoo#36681

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

`product.template.attribute.value` now retain to which
`product.template.attribute.line` they belong to. This allows the inverse
relation (o2m) to work out of the box instead of relying on a compute.

This is easier to maintain, faster, better for data integrity, and a necessary
step towards allowing multiple lines with the same attribute.

Part of task-1912579

closes odoo/odoo#35866

Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

PURPOSE
=========

When working in restaurants, there are often more than one waiter working on the same floor.
But Odoo doesn't support that.
There can only be one person working on one session for the same tables.
The purpose of this task to allow several people to work on the same session (while synchronizing sessions).

SPECIFICATIONS
===============

- MultiUser is active by default.
- Allow multiple waiters to login on one PoS Config.
- All waiters login to the same session, the waiter that does the paiment is the responsible for the order (same as now).
- Synchonize the information across the multiple instances running on same floors.

Syncronisation will take place at switch of table.
(close tables automaticly if no activity, to force sync)

- Syncro cannot be done if no internet : how do we manage it ? We should inform the user the internet connection has been lost and that synchro cannot be done. What impacts? To check

Useful links
https://github.com/it-projects-llc/pos-addons
https://apps.odoo.com/apps/modules/11.0/pos_bus_restaurant/



Related PR:
odoo#32789

TASK-ID: 1891130

closes odoo/odoo#33973

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

We've adapted the tests to work with the new implementation
of payments and session closure. And we've added some new
ones to have a better coverage on point_of_sale module.

TASK-ID: 1862388

closes odoo/odoo#33578

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