To reproduce:
- Create a second company with the same currency as the first,
- Assign the first pricelist with that currency (based on _order) to
the second company
- Install the POS, or create a new pos.config while in the first
company
The above results in:
raise ValidationError("The selected pricelists must belong to no
company or the company of the point of sale")
opw-2192658
closesodoo/odoo#45199
X-original-commit: f6e73f69350b3d0fef5f24e0073f68e52da3a36d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.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
closesodoo/odoo#33578
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
There used to be some acceptance tests but they have not actually been
run since 8.0.
These acceptance tests are very useful for the POS because the POS is a
somewhat unusual module and it happens occasionally that a change in
another module unintentionally breaks the POS.
Another reason these tests are nice to have is because the POS
duplicates a lot of calculations in JS because it's meant to be able to
work offline (eg. calculation of taxes, orderline totals etc.). Subtle
differences (eg. rounding) between the frontend JS calculations and the
backend calculations make up the most common category of bugs in the
POS. These frontend tests will make it easy to write tests for these
scenario's. When phantom_js finishes we look through all the received
pos.order records and see that all of them are paid. If there would be a
difference between frontend and backend calculations the order would not
have the paid status because the payment on the order would be different
from the total. An example test for a previous bug has been included.
This will also come in handy for testing the upcoming pricelist
functionality that will be implemented in the POS.
Joseph Caburnay