*: point_of_sale
- Makes the default shop and restaurant use the same default payment methods except cash payment methods that are individual.
- Adds a default cash payment method to the default restaurant.
closesodoo/odoo#126953
Task-id: 3378032
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
This PR resolves a bug in the self linked to the demo data.
Steps to reproduce:
Create a new Restaurant session
Open mobile menu for Restaurant
Make an order in the mobile menu for a table
Reload the page where the open restaurant session is.
[BUG] The ball telling if an order is sent to the kitchen or notbecame black.
[EXPECTATION] The ball telling if an order is sent to the kitchen or not is red.
closesodoo/odoo#134777
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
Previously when a table was deleted 2 write calls were sent. This was a
problem because it causes a concurrent update error. One of the write calls
is undesirable and comes from the unWillUnmount from EditableTable component.
This commit removes the unwanted write call.
closesodoo/odoo#135512
X-original-commit: b1c5267845f82e8444d8548cb317d23721c31592
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Loukas Wets (lowe) <lowe@odoo.com>
pos*: point_of_sale, pos_restaurant, pos_self_order
**Purpose:** This change is for better UX of the testers.
**Notable changes:**
1. Historical pos order data which include past sessions and past orders.
2. New open session and open orders.
3. Onboarding data containing all demo datas and the new open session
and open orders.
4. Adding more drinks demo products.
closesodoo/odoo#128699
Task-id: 2484444
Related: odoo/enterprise#44198
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
*:point_of_sale,pos_adyen,pos_online_payment_self_order,pos_restaurant,
pos_sale,pos_self_order,pos_self_order_adyen,pos_self_order_restaurant,
pos_self_order_sale
This PR adds the kiosk to the existing `pos_self_order` module, which
until now has enabled end-users to order their restaurant meals directly
from their smartphones.
We've added the possibility of creating kiosks / totems (devices with
large touch screens) that allow users to order their menu directly
without having to go through a waiter.
Once the order has been placed, the user will be invited to pay either
by adyen, already integrated into this PR, or at the counter.
At the end of the order, the user will receive an order number and his
table number if `service at table` is activated.
Main differences with the Self-order mobile:
- Kiosk shouldn't be accessible publicly
- Kiosk should support payments via card readers
closesodoo/odoo#129562
Design: XLU
Dev: ADGU & MODA
Taskid: 3323163
Related: odoo/upgrade#5024
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
*:pos_hr,pos_hr_restaurant,pos_loyalty,pos_restaurant
Before when serializing a pos.order from the server, we are using
several methods for different use cases.
- table syncing: get_table_draft_orders
- order sharing: get_draft_share_order_ids
- ticket screen: export_for_ui
All of these methods had their own logic.
Now, to improve the maintainability of point_of_sale, order
serialization is only performed via export_for_ui.
Enterprise PR: https://github.com/odoo/enterprise/pull/45151closesodoo/odoo#130695
Taskid: 3449870
Related: odoo/enterprise#45151
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
*: point_of_sale, pos_adyen, pos_hr, pos_mercury, pos_restaurant
Adds online payments in Point of Sale using the payment module.
The pos_online_payment module is meant to be used by shops for paying online instead of using a physical terminal and by restaurants for paying an order either from the paying station or in the self-order process (smartphone used to order and pay online).
The module depends only on point_of_sale (and account_payment to support online payments).
The online payments support for self-order will be added in another commit.
The feature can be used by configuring a special pos.payment.method for one or many pos.config.
Operation:
The frontend session user can enter one or several online payment method lines (with or without other payment methods).
When he validates the order, if the online payment amounts are valid, a popup with a QR code is displayed on the frontend screen and on the customer display. This QR code allows the customer to open the payment page to pay online for the order.
The amount to pay for an order on the payment portal is the remaining unpaid amount or a lower amount if several online payments lines are used. Therefore, at any time, the customer will be able to pay the amount of the order that is unpaid, without requiring a staff operation to update the amount to pay.
When an online payment is done for a POS order, the generated account.payment is linked to the POS order through a pos.payment that is created with the online payment method configured for the pos.config, and the POS order paid process is triggered (it is the responsibility of the server to finalize the validation of POS orders that have at least one online payment, and not the responsibility of the POS session web client). If for any reason, there is no longer any online payment method configured for the pos.config of the order, a new one can be created automatically and exceptionnaly used to link the done payment with the POS order. This guarantees that any online payment saved by the payment module will be linked to the POS order.
The session web client is notified of successful online payments through web socket communication, to make the cashier screen automatically and quickly react to payments.
If several online payments are used for a single POS order, they are processed one after each other.
Working principles:
- The POS session web client is not allowed to save online payments on the server. Only the Odoo server, which handles the payment, can save online payments for a POS order.
- The POS session is only responsible for saving the order (especially other payment methods) and the next online payment amount to pay (in case of several online payments) on the server before the online payments are made by the customer, and for displaying the online payment status and the link (QR code) to open the payment page.
That means that modifications that are made after the order is fully paid are not taken into account by the server.
- Before validating an order, the POS session checks with the server if any online payment has been made for that POS order. If the user wasn't aware of one, the validation process is aborted, notifying him.
- The sensitive online payments data is received by the frontend user with RPC to the server when validating an order, cancelling an online payment or receiving a notification through the POS bus (web socket communication).
This data is used to update the cashier data for the specific order.
- No sensitive information is sent through the POS bus (web socket communication).
Indeed, the bus communication is only protected by the name of the channel, and there is no mecanism to prevent several attempts. Therefore, no sensitive information is sent through it, only a notification to invite the local browser to do a safe RPC to the server to check the new state of the order.
- Online payments for a POS order cannot be modified or removed when they succeeded. Checks ensure to never allow an online payment to make the total paid amount greater than the total amount of the POS order.
- If the frontend user clicks on the "Cancel" button of the online payment popup, the order can potentially still be paid online. Indeed, the order will be removed from the server only if it was added only for the online payment flow, and any order that is not paid can be paid on the online payment portal (if the customer has the web link).
This behavior ensures that in a shop, starting an online payment and then cancelling it doesn't prevent the user to close the POS session. And it ensures to don't delete a draft order that is used for other flows, like in a restaurant or when there are trusted POS configs.
Payment portal features:
- The payment portal pages of a POS order are protected with its access_token.
- If the amount of the order has changed when the customer clicks to pay, an error is fired to notify him and give him the choice to continue or abandon the payment.
- An exit_route argument (an URL) can be passed to allow the customer to exit the payment portal at any time (with a button), which could be used for self-order flow.
- A button to go back to the payment page is displayed when an error occurs during a payment transaction, which allows the customer to retry a payment without needing to scan again the QR code.
- If the customer is not logged in in the payment portal (most frequent case), it is considered as the public user partner for the payment flow to don't give him privileged access to sensitive data like payment tokens.
- The accounting process of online payments for POS orders is made in the same way that the pos.payment.method that have split_transactions to True.
- The POS customer of a POS order has no link with the customer making an online payment for that POS order.
- The payment portal is made using the pos.order id and not the pos_reference because the latter is not guaranteed to be unique.
Some tests have been written, especially one that simulates a whole online payment flow starting from nothing, creating an order, requesting an online payment, faking this online payment by doing web requests to the payment portal, then finally closing the POS session to check that there is no accounting issue.
The design of the payment portal is temporary.
closesodoo/odoo#123237
Task-id: 3276404
Related: odoo/enterprise#41776
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Adds the possibility to book a table online from the website.
The booking is then visible in the POS.
When a new table is created in the PoS, a linked resource is created
in the appointment application, which allows the user to add these
resources to appointment_types, authorising visitors to reserve tables
online.
In pos_config, you need to choose an appointment_type via which the
appointments will be retrieved
A websocket has been integrated to retrieve new bookings instantly
from the PoS, which are displayed directly on the tables.
closesodoo/odoo#124850
Related: odoo/enterprise#42489
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
*: point_of_sale, pos_self_order
Changes:
- Adds a default restaurant with some default usual settings (with tips after payment if the company is in the United States) but no floor in the Point of Sale app. Makes pos_restaurant module auto installed with point_of_sale.
- Makes some restaurant settings enabled by default (only for restaurants).
- Adds loadable default demonstration data for onboarding (only when no real product is available in POS), specific to a restaurant. The default demonstration data for onboarding of point_of_sale and pos_restaurant are loaded together (if pos_restaurant is installed) to make it so an user that clicks to add demo data will have demo data for the default point of sale and also for the default restaurant (and the current restaurant if it is different than the default one). Makes the load demonstration data button visible when there is no product with a positive price available, because without that condition the tips (in restaurant) and discount were preventing the display of the button.
- Hides the Preparation Printers menu item if there is no POS config using the printers.
- Renames some labels.
Fixes:
- Adds checks to always set set_tip_after_payment to False if a point of sale is no longer a restaurant or if the tips are disabled. This is needed because the code of pos_restaurant seems to be written considering that set_tip_after_payment is True only when the point of sale is a restaurant with the tips enabled (which wasn't guaranteed). Without that checks, some tests like ReceiptScreenTour fail. Another solution to make the tests successful without that checks would be to add !this.env.pos.config.module_pos_restaurant in pos_restaurant/static/src/js/Screens/PaymentScreen.js:16. But because other parts of the code only check the value of set_tip_after_payment, I think it is better to opt for the additionnal checks.
- Fixes duplication of displayed product categories when loading demonstration data.
- Fixes products before loading demonstration data that were kept and displayed after (discount for example).
- Fixes categories and therefore communication with the preparation display after loading demo data in a restaurant.
- Adds a check on the server side to prevent demonstration data loading when there is at least one valid product for POS.
- Fixes order count display when "NaN" (in floors and tables view).
- Fixes arguments of orm call for set_not_tip (model and method names were not given in the right order).
closesodoo/odoo#117941
Task-id: 2484291
Related: odoo/enterprise#39450
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before a longpolling every 5 seconds was set up to sync the number of
orders per table in the pos_restaurant, which was not very
userfriendly / efficient.
Now, the longpolling has been replaced by a bus (websocket). As soon as
an order is sent to the server by another PoS, the server dispatches the
information to all other PoS using the corresponding floor plan.
The bus_service was initialized in the pos_store of the point_of_sale,
but is now used only in the pos_restaurant via override.
This was done for obvious future use.
closesodoo/odoo#121875
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
The PoS needed improvments for the mobile use.
This commit is changing the display of some screen and popups
like the NumberPopup. It also changes the logic of the
order count badge on the table. It now displays the number
of orderline (and their quantity) to send to the printers
or preparation display if there is at least one.
closesodoo/odoo#121286
Related: odoo/enterprise#41013
Signed-off-by: Monnom David (moda) <moda@odoo.com>
A new POS config with the name `Shop` is created when a new company is
created with a dedicated fiscal postion and if `point_of_sale` is
installed. A `Bank` payement method is created for the POS, as well as a
`Customer Account` payement method. If a there is a cash journal that is
not already linked to a payement method it would create a cash payement
method for the dedicated POS. If the module `pos_restaurant`is installed
it would also create a POS config with the name `Bar` of type restaurant
with the same specification as for the normal pos config `Shop`.
Since the changes create default configs along with payement methods,
there was some conflicts with the test instances. Therefore the payement
methods where unlink in the set up of the test to resolve the conflicts.
task-3244511
closesodoo/odoo#119221
Related: odoo/enterprise#41003
Signed-off-by: adgu-odoo <adgu@odoo.com>
Enable floor plan for all PoS Restaurant config. To accomplish this, we are
removing the following fields:
- `pos.config.is_table_management`
- `res.config.settings.pos_is_table_management`.
All access to `is_table_management` can be replaced by `module_pos_restaurant`
because originally, `is_table_management` can only be true if
`module_pos_restaurant` is true.
To adapt the tests, we should manually set `module_pos_restaurant` to `False` for
the `pos.config` used in tests outside `pos_restaurant` addon. This is because
when pos_restaurant addon is installed, it sets every new `pos.config` record to
be restaurant by default.
Task-3282975
closesodoo/odoo#120117
Related: odoo/enterprise#40532
Related: odoo/upgrade#4622
Signed-off-by: Monnom David (moda) <moda@odoo.com>
To reproduce (16.1 and >):
1. install pos_restaurant
2. open the bar PoS (NOT a shop)
3. choose a table
4. sell a product & make the payment & new order
5. choose a table (can be the same as before, it does not matter)
6. refund
7. select the previous order > refund
(already a bug, it is not proposed it is empty. But we can force
its selection by going again in the refund tab. Will create a
dedicated task for this issue)
8. go back to the main floor (to force sync the order)
9. go back to the table with the hanging refund order
10. try to pay it
=> server error:
```
bad query: INSERT INTO "pos_order_line" (..., "refunded_orderline_id", ...) VALUES (..., ARRAY[1,'Coca-Cola'], ...) RETURNING "id"
ERROR: invalid input syntax for type integer: "Coca-Cola"
LINE 1: ..., ARRAY[1,'Coca-Cola'],...
```
This happens due to this recent fix:
https://github.com/odoo/odoo/pull/116271
Adding this field in the `search_read` yield the product ID and the name
(ORM default behavior on Many2one fields). As the PoS needs only the ID
we take it from the tuple.
Note: the fix does target originally version 15, but the forward port
code was changed only on version 16.1 and > creating this issue.
After this commit:
Able to refund order without an errors
opw-3292121
closesodoo/odoo#120722
X-original-commit: a2ad09c0fb50a299afa29e01b457ff1699f6d811
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Sens Loan (lse) <lse@odoo.com>
*:pos_epson_printer,pos_epson_printer_restaurant,point_of_sale,
pos_restaurant,pos_hr_restaurant
Before the printers only worked in the pos_restaurant and not in the
point_of_sale. Indeed, the methods managing the printers were located
in the pos_restaurant.
Now all these methods have been moved.
For the community part here are the affected modules:
- The methods in pos_epson_printer_restaurant have been moved to
pos_epson_printer.
- The methods in pos_restaurant have been moved to point_of_sale.
- The module pos_epson_printer_restaurant has been removed as it only
handled printers.
Some of these methods have been adapted/renamed to better suit
the needs.
This branch the first part of the following task: 3224508
closesodoo/odoo#114655
Related: odoo/upgrade#4414
Related: odoo/enterprise#37901
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Currently, there is only 1 plan view that is unreadable on mobile
and sometimes also complicated in some cases.
This commit adds a new "Kanban" view used by default on mobile
and available in desktop too. This commit also changes the edit bar
of the FloorScreen: the design is changed and some features are added
like the multiple selection of the tables or the adding and removing
of floors directly from the frontend. It also changes the navbar
of the PoS, moving the buttons in a navigation menu accessible
thanks to a button.
Task-id: 3212032
Current behavior:
In PoS restaurant, if you refund an order and go back to the floor plan,
before validating the refund, the link between the original order and
the refund is lost.
Steps to reproduce:
- Open PoS restaurant
- Create an order
- Refund the order but do not validate it
- Go back to the floor plan, and go back on the order
- Validate the refund
- Close the session
- Go on the orders, you will see that the refund has no link to the
original order
opw-3202383
closesodoo/odoo#116748
X-original-commit: 3ea9a8a0b3a9085b35314633e56bb7e508df7008
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Currently the below use-cases are hardly supportable, though quite common:
Retail: Sell product in one shop and return it in another one
Restaurant: Managing payment when having multiple checkout desks,
and multiple waiters (only taking orders)
This because currently:
PoS orders are only known by the cashier desk (pos.config) they were created from
One floor map can only be linked to one cashier desk at a time
More over, with the Self-Service coming along the way
(where kiosk orders must be accessible from a cashier desk),
this need must be supported.
For restaurant, floor plans can be linked to multiple cashier desks,
ongoing orders are shared between trusted PoS config
(through floor plans for restaurant and according to
the setting "Trusted PoS config" for the retails),
and past orders can be accessible from any desks within a same DB.
closesodoo/odoo#109216
Related: odoo/upgrade#4393
Related: odoo/enterprise#37955
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
*:point_of_sale,pos_restaurant,web
A new module pos_preparation_display has been added to Odoo enterprise.
This PR is intended to add the requirements necessary for it to work
properly.
The changes are mainly related to the kitchen printer functions, as
the pos_preparation_display module reuses these flows in order to
receivethe orders to be prepared.
closesodoo/odoo#109024
Related: odoo/enterprise#35392
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Currently, it is possible to add a QR to generate an invoice for a pos
order at a later time (see
https://github.com/odoo/odoo/commit/14183883432e9d35c6240e1d7dc8c51d04cb93db).
When scanning the QR, the customer can fill various fields (including
potential l10n_* specific fields) and then generate an invoice.
This commit makes it possible to add a 5-digits code on the ticket. A
customer can go to `pos/ticket` and fills this code, the date and the
order reference written on the ticket. He will then be redirected to the
same flow as when scanning the QR code.
task-3178954
closesodoo/odoo#112285
Related: odoo/enterprise#36859
Signed-off-by: Laurent Smet <las@odoo.com>
Rewrite the whole chart template mechanism, removing the templates
stored in the database. The new format will mainly use CSV.
Speed up install time
---------------------
* About half of the time of installing a localization for the first time is
taken by creating the template records. This new in code format gets
completely rid of this.
* Creating the template records could often not be done in batch because
of parent/children relations.
* The instanciation of the accounts on the company has been entirely
reworked too, by
- optimizing the order of creation of records to avoid UPDATE queries
- using precomputed fields to avoid UPDATE queries
- updating the translation in batch
- deactivating logging in the chatter
- avoiding access rights checks by checking the rights at the start
Overall, when installing a chart template for the first time, it is 4
times faster because half of the time spent on saving the template in
the database is not done at all anymore, and the instanciation on the
company is more than twice as fast.
Reduce technical debt
---------------------
There is no need to synchronize the templates with the real records
anymore. No need to use hooks to copy the data from one to the other.
It is easier to change a template in a stable version, which can often
be necessary due to legal reasons (i.e. a change of tax rates, reporting
tags,...)
Two modules have been removed:
* `l10n_generic_coa`: since there is nothing left datawise in this
module, it can be integrated in `account` for free. It is just code
and CSV.
* `l10n_multilang`: the fields that this module modified to be
translatable are now always translatable:
- there was an issue when updating modules that deleted all the
translations because the fields were not translatable at some point
during the loading of the registry, then they because translatable
again but lost all translations because of the column type change.
- most devs are not able to understand all the languages needed for
all the localization available. Therefore, english has been added in
the sources in most localization to understand better issues while
debugging.
- no need to call post init hooks anymore, doing the sync with the
templates.
- more: see "Translations" section
Because most of the data is now in CSV, it is also easier for product
owners to edit, audit, modify files themselves, removing one layer
during trivial development processes when only data should be changed.
More flexibility for declaration
--------------------------------
The data declaration can now be done easily in python or CSV.
A nice feature is that you can declare everything at once, even for some
more complex chart of accounts:
* if you have to set default taxes on accounts, would need to
- declare the accounts because accounts are required on the taxes
- declare the taxes
- declare the taxes to put on the accounts
This would lead to scatter information in multiple files. Now,
everything can be declared in the same place and the loading of the
chart of accounts will do the 3 steps automatically.
* if you have a relation of child/parent, you would first need to
declare the parents then the children, and the loading would not be
efficient because done one by one. Now, everything is done in batch
automatically without having to think about it.
It is also easier to update fields on records where there was no field
for that on the templates, like
* setting a restriction for journals on accounts
* setting specific values on the company
* modifying journals and linking them easily by using the xml_id instead
of having to compute it manually
Translations
------------
Some countries have multiple languages (i.e. Belgium uses officially
French, Dutch and German, and the CoA also has an official English
version) and we must support the languages in all these countries.
All these translations are known, and hard coded without using out
translation platform (Transifex). We also like to have the English
version (even if an official one doesn't exist) so that support can be
done more easily in databases using chart templates in other languages
(especially using a non roman alphabet).
Because the translations were not on Transifex for these records, it was
really hard to maintain: the translation templates (`.pot` files) were
not easy to extract as the automatic export would give values mixing
both the CoA and the menuitmes, the fields' strings,... But we don't
want to translate the CoA as we already know the value.
Managing the translations in the `.po` files was also annoying:
- it is easy to forget that the translations need an update too
- it requires a special editor, special terminal commands that everyone
is not familiar with
- it is easy to make mistakes in the source string
The new format is the following: `field@en_US` where `field` is the
translatable field (usually `name`) and `en_US` is the locale code.
This allows to have the whole declaration on one line, everything in one
file. It also makes the process easier when debugging: instead of
searching for the translation in the `.po` files, it directly appears
next to the configuration of the account/tax/... .
Update of the code
------------------
The code can be updated using this script
https://github.com/william-andre/transform_coa
Forward ports can be managed too by stashing/resetting/checkout the new
modules or the changes in the modules updated in the same PR.
task-2687567
Part-of: odoo/odoo#110016
By making the search_read inside 'get_table_draft_orders' non-hardcoded,
its domain can now be modified by inheriting
_get_domain_from_draft_orders from other modules.
closesodoo/odoo#111609
X-original-commit: 64156e5ed6a9825bdbe2277783f250b471636004
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Previously, reward_id was an array of two elements containing
the ID and name of the reward. But in the frontend,
reward_id is supposed to be an int with the ID
Adaptation of the _prepare_order_line function in the following modules:
- point_of_sale
- pos_restaurant
- pos_loyalty
Now the data is correctly sent to the frontend and the error
is no longer present.
closesodoo/odoo#111048
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Right now when you create an order (order A) in a POS with tables the
`date_order` is being set correctly (in UTC, so is shown in the back-end
with the user's timezone), but after you return to the Floor Screen or go to
another order (order B) and then go back to the order A and you add
another product and the order is saved (not paid) when you check that
order in the back-end now the `date_order` it says another value not the
one of the user's.
This is happening because when the JS received the back-end information
to open the order for the second time the date come in the User's
timezone and the server's timezone, and that info was saved but taking
it like UTC.
Now instead of storing inconsistent information in the DB (server side), we
are going to modify the information that is shown in the POS (client side),
so that both sides show the same date.
This will only apply in the POS where tables are being used since the
orders are only synchronized (back-end) when the option `is_table_management`
is set in the POS (`pos.config`).
closesodoo/odoo#110832
X-original-commit: 168d0e12120ced7b1093d39b10cd79c85c56aad0
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
currently the table_id, customer_count fields are editable from the pos order form in the backend and all the other fields are readonly
closesodoo/odoo#107135
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Splitting the method `_get_order_lines` will allow making it
inheritable, this way more order line fields can be added and expand
them easily and avoid having to overwrite it.
closesodoo/odoo#105858
X-original-commit: 457624160f03c28e9b90d14fb4c56fe2f7fabeed
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Current behavior:
When you open the order list, the orders are displayed in UTC.
Steps to reproduce:
- Be sure you are in a timezone different than UTC
- Start a PoS restaurant session
- Go on a table and make and order
- Go on the order list
- Go back on the table, then go back on the order list
- The time showed for the order is not correct (it's in UTC)
This bug was happening because `moment(order.validation_date)` consider
that the date is already in the local timezone, so it doesn't apply the
timezone offset. So we have to apply the offset manually before sending
it to the frontend.
opw-3002417
closesodoo/odoo#105417
X-original-commit: bd366a6d11fd8864b4c2fd2819463449d6da5278
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Before this commit: if you use the lot/serial number for the products, it
won't load correctly through the UI.
closesodoo/odoo#103940
Issue: https://github.com/odoo/odoo/issues/100888
X-original-commit: 0e2ea5ff786185a72916e5582fdbf45271819b8c
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Before this commit: if more than one user work on a PoS restaurant, the
synced validated orders wouldn't remove from other user devices.
Steps to reproduce the issue:
1. Create a PoS resturant
2. Login to the PoS with two different browser
3. Create some orders with some products in one of the browsers
4. Complete the orders in another browser
=> Orders will not remove from the first browser
The solution is to retrieve the latest orders of every table when going to
the TicketScreen
opw-2925193
closesodoo/odoo#100353
Related: odoo/enterprise#32871
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
With this change, we are now assuming each field that starts with
'pos_' to be a 'pos.config' field that has value that will be saved
to the 'pos_config_id' record. We made that modification because by keeping
some related fields not written at the same time can trigger contraints at the
wrong moments that would lead to validation errors when not supposed to be.
Part-of: odoo/odoo#97032
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.
closesodoo/odoo#84719
Task-id: 2753430
Related: odoo/upgrade#3260
Related: odoo/enterprise#24425
Signed-off-by: Masereel Pierre <pim@odoo.com>
Moved the cross behaviors and logics in a new link module. This avoid having to
create hook methods in the `point_of_sale` that needs to be overridden.
closesodoo/odoo#92256
Signed-off-by: Masereel Pierre <pim@odoo.com>
Before this commit: In the PoS Restaurant, if the employee is not
installed, the orders wouldn't contain employee_id, and UI couldn't get
table draft orders.
Steps to reproduce the first issue:
- Install the' Point of Sale' module
- Make sure Employees (hr) isn't installed
- Create a PoS with "Is a Bar/Restaurant" enabled
- Open a PoS session in the incognito window
- Add the product to the orders for different tables
- Close the incognito window and open it again
It couldn't get table draft orders from the back-end.
Solution
It must check that "employee_id" exist in the dictionary.
opw-2856653
closesodoo/odoo#92157
X-original-commit: 822d444f74edf8dd9bae7a01d3646e0888128901
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Current behavior:
In PoS restaurant cashier were not saved correctly in db if you
switched table before making the payment of the order.
Steps to reproduce:
- Install PoS
- Activate restaurant on one of your PoS
- Activate Authorized employee
- Start a PoS session, and select a cashier
- Create an order on a table
- Leave the table and comeback to it
- Make the payment for the order
- Go in the PoS orders, the cashier wasn't saved
opw-2794574
closesodoo/odoo#91447
X-original-commit: 2c6ea058f9f8cfaf75529ff4028913a59f021ab8
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Cleaning of the principal methods used in the pos_restaurant flow. This make the code a lot more readable and maintainable as we strive for the single responsibility principle.
A few notable changes:
- [REF] `point_of_sale.assets` in `pos_restaurant` now uses glob syntax (`**`) for the js files, no need to add them in the manifest anymore.
- [MOV] Moved some methods to `pos_restaurant` (because it was only used there) from the `point_of_sale`
- [REF] Only the created, removed and updated orders of a table are being sent to the server once we reach the Floor Screen. Before, all the orders of a table were being sent to the server as the newest state. This led to some synchronization problem when two users wanted to modify each a different order of the same table, the user leaving the table last had **all** his orders states (even the ones he didn't modify) pushed to the server.
- [IMP] After a table transfer while being in offline mode, the transferred order is saved locally (if not yet synchronized) and going back to the previous table after getting the connection back will no longer show the transferred order after the orders fetching from the server.
- [FIX] When an order is selected (normal Point of Sale and in a table in `pos_restaurant`), the selected order is not changed in the Ticket Screen when deleting an order unless the deleted order is the current selected order.
- [FIX] Same as above but while settling all the tips from the `Ticket Screen`
- [FIX] Errors are now properly handled in the `Floor Screen` depending on the context.
- [REF] Kitchen order printing flow has been revamped and improved. This also fixes a bug where we would print a cancelled receipt changes for a skipped order line when adding a product which was already printed before (add 1 product => print => add same product + skip => print would give a cancelled changes for this order line).
closesodoo/odoo#85956
Related: odoo/enterprise#25051
Related: odoo/upgrade#3375
Signed-off-by: Masereel Pierre <pim@odoo.com>
Current behavior:
When using variant in PoS the price was not always correct
Steps to reproduce:
1. Set up items with modifiers (Modifier type must be of type variant creation mode : never, where adding a modifier leads to a different price than with the base item e.g. base item is 10 USD, modifier is 5 USD, total price is 15 USD;
2. Activate Product configurator and make sure it's a Bar/Restaurant in the PoS settings
3. Select the items with the modifier;
4. Leave the table and come back to the table
5. Change the quantity of this product
6. The price is back to the base price without the modifier
opw-2696529
closesodoo/odoo#83444
X-original-commit: d959dfada11a72d6bc275b35f5eeb06b045a0dea
Signed-off-by: Masereel Pierre <pim@odoo.com>
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
This commit accomplishes multiple objectives:
1. Loading of model data for the POS UI is now done in single
request (with some exemptions).
2. Backbone.js is removed and is replaced by reactivity.js
authored by the js framework team.
3. Better organization of assets in the `__manifest__.py`
Data Loading
------------
One request per model -- that's always been how the data is loaded
in POS UI. Now, we move the aggregation of data to the backend which
simplified the data loading. In the frontend, data loading is
initiated in `load_server_data` which makes the single rpc call
to the `load_pos_data` defined in `pos.session` model.
There remains some rpc calls during loading but the number is
greatly reduced.
This change result to faster loading of the POS UI. However,
there is no more progress bar during the loading.
Notable entry points:
- .js: `PosGlobalState.load_server_data`
- .py: `pos.session.load_pos_data`
It is possible to make customizations in the loading, but is done in
several steps:
1. Override `_pos_ui_models_to_load` to include the new model to load.
2. Define `_loader_params_<model_name>` to define the `search_params` and
optional `context`.
3. Define `_get_pos_ui_<model_name>` to return the data that will be
included in the full `loaded_data`. Perform the organization in this method
whenever necessary.
4. Override `_pos_data_process` for further post processing. The final
form of `loaded_data` in this method will be sent to the frontend.
Removal of Backbone.js
----------------------
POS is no longer dependent from `Backbone.js`, but it's replaced by a
new dependency -- `reactivity.js`. It's invented by the js framework
team which will be available in owl v2.
The consequences of this change are the following:
1. The old `PosModel` is renamed to `PosGlobalState`.
2. The name of the other models are kept (except Paymentline which
is renamed to Payment).
3. The name `PosModel` is now used as the base model of the data models.
This is symmetric to our use of `PosComponent`.
4. The instance of `PosGlobalState` is made reactive in `Chrome` (the
root component). As a result, whatever mutation made in that instance,
`Chrome` will rerender. But rendering is batched so multiple mutations
in a single sychronous function call will only result to a single
render call.
5. `PosModel`s can be extended in the `Registries` the same way as we
extend the `PosComponent`s.
```js
// E.g.
Registries.Component.extend(Chrome, PosResChrome);
Registries.Model.extend(Order, PosResOrder);
```
Reorganization of assets declaration
------------------------------------
This is a simple change that replaced the explicit enumeration
of loaded .js and .xml files. Also, we now have regions in the
manifest separating:
1. Augmentations of dependencies
2. Assets for `point_of_sale.index`
3. Assets for the qunit test (soon will be improved)
Other notable changes
---------------------
- Automatic call to `Order.save_to_db` is batched.
- Instances of `devices.DeviceProxy` (`proxy`), `devices.JobQueue`
(`proxy_queue`) and `BarcodeReader` (`barcode_reader`) are moved
to `point_of_sale.env`. Together with `posbus` and `posMutex`
(previously `flush_mutex`).
- `ActivePrograms` is now passed a props.
- `cashier` is no longer saved to `localStorage`.
- `pos_cache` is overhauled.
- `cache` is taken out from `PosDB` to prevent infinite rendering
loop whenever `cache` is mutated. It's now called `CACHE` in
the `db.js` file.
- reactive version of `posmodel` is exposed globally when in debug mode.
This means that calling when calling a mutator, the UI will react.
- Added control buttons in the `ProductScreen` is sorted during `Chrome`
setup. As a result, we don't need to worry on the loading order of the
control buttons components.
- Model can be simply instantiated using `BaseModel.create(obj)`. This
takes into account the extensions.
- `pos_coupon`: rewards are now updated whenever set_order is called.
- Component unit tests were removed. It wasn't useful and it just blocks
the development. We'll be introducing better unit testing later.
closesodoo/odoo#82461
Related: odoo/enterprise#23344
Signed-off-by: Masereel Pierre <pim@odoo.com>
Co-authored-by: Jacky (trj) <trj@odoo.com>
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Current behavior :
When you add a promotion campagn to a PoS the promotion is applied
on every line of every order everytime you load the order. This cause situations
where you have multiple discount for a single product.
Steps to reproduce:
- create a standrard promotion program (automatically applied, 10%)
- set that promotion on the PoS (bar)
- open a session, chooses a table and make an order --> promotion correctly applied
- get out of the table and go back to the same table --> 2 additional lines are created because of the promotion
opw-2699544
closesodoo/odoo#81096
X-original-commit: 72d6431eb26654b697fc0379f4b6d7e305bb79fc
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
To avoid the use of certificates when using direct devices
POS was redirected in HTTP
With new Chrome or Edge security measures this is no longer possible.
We add here the possibility to choose to redirect
the POS in https by adding a specific key in the parameters
closesodoo/odoo#78247
X-original-commit: 9cecb3bdbf5679b6d1d18dc2a250c86118bca6ce
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
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.
closesodoo/odoo#71598
Task-id: 2556994
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Theo VINCENT (thvi)