Prior to this PR, `product_configurator_popup.js` did not support
attribute selection of type `multi`. In addition, the
`pos_preparation_display` did not display any attributes.
Now it's possible to select attributes of type `multi` in the Point of
Sale, and the preparation display shows all available attributes.
closesodoo/odoo#136441
Taskid: 3497560
Related: odoo/enterprise#47834
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Prior to this commit the name of the reservation was not displayed under
the booked table. In addition to fixing this issue, this commit adds
the number of people expected on the table.
closesodoo/odoo#136140
Related: odoo/enterprise#47715
Signed-off-by: David Monnom (moda) <moda@odoo.com>
*: 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>
When the user using `point_of_sale` deletes pos restaurant and tries
to load demo products in pos shop then user will face error.
Note: Use db without demo data
steps to produce:
- Install `point_of_sale`.
- Point Of Sale > Configuration > Point Of Sales, delete pos restaurant.
- Point Of Sale > Shop > New Session, click on `our demo products`.
Error: `KeyError: 'name'`
After applying our commit, if the user clicks on `our demo products`
after deleting pos restaurant then the user would be atleast able to see
shop demo products and other demo products which are not part of
pos restaurant.
sentry-4399441443
closesodoo/odoo#135633
X-original-commit: feaf26db77fde9afae23c8b3c3ea2f0f441b4dae
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The onboarding demo data cannot be loaded since f96ea753f3.
Steps to reproduce:
- Start a database without demo data (--without-demo=True)
- Open a POS session for the default shop
- Click to load demo (onboarding) data
An error is raised.
The error is due to a mistake in the XML, the food category logo is not assigned to the right record.
closesodoo/odoo#136392
Task-id: 3519677
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>
In this commit, we add images on demo categories to make the demo more
realistic but also change a bit the design of the category selector.
closesodoo/odoo#134621
Signed-off-by: David Monnom (moda) <moda@odoo.com>
In the ticket screen the user has the option to double click on an
order in order to continue editing it. This functionality is implemented
using custom code for handling the double click. This is cumbersome and
error prone.
In this PR we replace the custom double click logic with the default
`t-on-dblclick` from `owl`.
closesodoo/odoo#135856
Task: 3512282
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
At the moment, the pos displays the selected order in multiple
screens, such as the `ProductScreen`, the `TicketScreen`, the
`SplitBillScreen`, the `self_order` app, but uses completely
different implementations for each. This means that when
a change needs to be made to the one, it generally needs to be made
to the other as well, which is error-prone.
In this commit we create generic `OrderWidget` and `Orderline` components,
that have not dependencies on POS objects and we refactor the `ProductScreen`,
the `TicketScreen` and the `SplitBillScreen` to use these components.
The `OrderSummary` component was removed and it's contents are now in the
`OrderWidget`.
We also introduce a very simple new component called `CenteredIcon` that
can be used whenever we want to show an icon that fills a whole div. In this
commit we use it for showing the cart icon when the order is empty.
In a future commit, the `pos_self_order` will be refactored in order
to use the same `OrderWidget` and `Orderline` compoenents as the POS.
Task: 3470365
In addition, this commit solves the issue from the task 3491303.
closesodoo/odoo#132248
Related: odoo/enterprise#45972
Signed-off-by: Joseph Caburnay (jcb) <jcb@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>
Prior to this commit the displayed order information in the order list
was inconsistent. This commit rearranges the displayed information.
Task-3502304
closesodoo/odoo#134969
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
In the floorplan, when clicking a table in edit mode, this table
changes to an editable table. The method setting the style of this table
was different from the one setting the style of a classic table leading
to placing it to high on the floorplan.
closesodoo/odoo#134810
X-original-commit: 54e51a2f247bff866d842f201841fd4c2c133d21
Signed-off-by: David Monnom (moda) <moda@odoo.com>
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
At the moment, the point_of_sale module has 3 different implementations of
numpads. This is absurd. In this PR we unify them all into a single
numpad component.
One of the reasons why there are multiple numpads is because each requires
a slightly different set of buttons. The new `Numpad` component provides
a simple API which allows the consumer to specify what the buttons should be.
This is done by proving the `buttons` prop, which has the following type:
```js
buttons: {
type: Array,
element: {
type: Object,
shape: {
value: String,
text: { type: String, optional: true },
class: { type: String, optional: true },
disabled: { type: Boolean, optional: true },
},
},
}
```
In this PR we also provide a simple set of helper functions for the tours
and adapt all of the existing tests accordingly.
closesodoo/odoo#132245
Task: 3470346
Related: odoo/enterprise#46427
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit:
===================
In the back-end, there is only one field "date_order" is used, while on the
frontend side, there are two separate fields: "creation_date" and
"validation_date," which causes confusion in the code flow and leads to
redundancies.
After this commit:
==================
Revised the order date flow by eliminating the confusion stemming from the
separate "creation_date" and "validation_date" fields. Both have been
consolidated into the "date_order" field, offering clarity to the order date
process.
task - 3482072
closesodoo/odoo#133293
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Currently when the pos.config is set to "Skip Preview", when printing a
receipt, the receipt or bill screen shows very quickly and disappears.
This is not good UX.
Now, the receipt is printed from the payment screen itself. We don't
need to show the receipt screen at all.
closesodoo/odoo#132550
Taskid: 3441238
Related: odoo/enterprise#46187
Signed-off-by: Joseph Caburnay (jcb) <jcb@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>
*: pos_discount,pos_loyalty,pos_restaurant,pos_self_order
In a previous commit (669b9fcc2f) we added the
backend logic needed for creating combos in `pos`.
In this PR we add the combo functionality to the classic pos ui.
This means that products can now be grouped together and sold as a combo.
ex: Create a product called `Burger Menu` with type='combo'.This product will
have multiple combos associated with it, for ex:
- Drinks - will contain the list of drinks from which the customer can choose
- Main Course - will contain the list of main courses from which the customer
can choose
- Dessert - will contain the list of desserts from which the customer can choose
In the event that one of the products inside one of the combos is to be more
expensive, this product will have a specific `combo_price` which will be added
to the main combo product's price.
We add the relational fields `combo_parent_id` and `combo_line_ids` in the
`pos.order.line` model. In the previous example, `combo_parent_id` will contain
the `id` of the `orderline` of the `Burger Menu` product.
In many cases `combo lines` have to be handled together. For example, deletion
of an orderline containing a product from a combo implies the deletion of all
other orderlines containing products from that combo. This means that multiple
methods from the codebase had to be changed for this reason. Places that needed
changes for this reason:
- `split_bill_screen.js`
- `addProductToCurrentOrder()`
- `remove_orderline()` and `add_orderline()` from the `Order` js model
In this PR we also:
- improve the demo data such that it contains a `pos combo`;
- refactor the `ProductItem` component such that it relies on a stateless
component. This stateless component can now be used anywhere; ( it is now used
in the popup which allows selecting the desired combo products )
- add a new method called `is_pos_groupable` on the `Orderline` js model. Before
we relied on the product unit to see whether or not a product is groupable. We
now needed a new mechanism, which could account for different reasons for
which products are not groupable, such as belonging in a combo;
Note on price calculation:
- The idea is simple, imagine a rectangle divided into two parts. The whole
rectangle is the total order, whereas the two partitions are the orderlines.
- Now, imagine shrinking the rectangle by a certain factor. This shrinked
rectangle represents an order containing a combo -- because normally, a
combo results to smaller price. The two partitions are also shrinked by the
same factor.
- So the calculation will be:
- Nominal total price is calculated. This is the sum of the orderlines'
prices when they are added individually. This represents the whole
rectangle.
- Target price is derived from the combo product's price and selected
components' combo prices. This represents the shrinked rectangle.
- Reduction factor is computed as the ratio between the target price and the
nominal price.
- Each component's unit price is adjusted by multiplying the reduction
factor.
- When the unit prices of the components are computed, we now let the normal
price computation take place.
- A spreadsheet is prepared to show a sample calculation:
https://docs.google.com/spreadsheets/d/1iOdnaILnvKiaf2_z7jTijYiVfB_3mjKWjq6nOB70Un0/edit#gid=0closesodoo/odoo#129483
Task: 3430636
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Co-authored-by: Joseph Caburnay <jcb@odoo.com>
After the introduction of bootstrap, the floorplan edition style
changed. In this PR we want to make the floorplan edition look like
it was in saas-16.4.
closesodoo/odoo#133592
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
luxon and moment are both used in the solution, but these two libraries
facilitate the manipulation of dates. It was decided to replace all uses of
moment with luxon so we can then remove moment.js from the code and lighten
the assets.
task-3391739
closesodoo/odoo#133144
Related: odoo/enterprise#46447
Signed-off-by: Bruno Boi (boi) <boi@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>
* point_of_sale, pos_loyalty, pos_restaurant
before this commit, syntax error exist in point_of_sale,
pos_loyalty and pos_restaurant modules.
* export translation of above modules
* check odoo log file
errors in the log:
* Opening and ending tag mismatch: input line
* XMLSyntaxError: Entity 'nbsp' not defined
* Opening and ending tag mismatch: button line
* Specification mandates value for attribute disabled
after this commit, no error's wont be shown in
the log
closesodoo/odoo#132132
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
*: pos_loyalty,pos_restaurant
The ticket screen contains a widget showing orderlines
and information about them for paid orders. This commit introduces
the use of this widget for open orders. On the ticket screen,
the cashier will be able to have information about the orderlines
for each order without necessarly loading the order in full screen.
The user now have to click on the order on the ticket screen and click
on the new button "Load order" to display it in the main screen.
closesodoo/odoo#128288
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
In this commit, all usages of env._t() are replaced by _t().
In templates files, env._t() didn't work because terms used
in attributes where not extracted into the translation files.
Only string are exported from .xml files to translation files.
So, to make it works, we set a variable that is then used
in attributes.
For example :
<t t-set="string_to_translate">String to translate</t>
<Dialog title="string_to_translate>...</Dialog>
task-3292454
closesodoo/odoo#131390
Related: odoo/enterprise#45631
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
before this commit, on deleting a floor from
pos user interface, there is a typo in the
pop up confirmation message shown
wanna -> want to
after this commit, the typo in the message is
corrected.
closesodoo/odoo#132211
X-original-commit: c2bb0e06044500d2c2fea0fb475d833bc6d457b0
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Sometimes, it is possible to have a product for which its category is
unknown by the pos db of the config. This can happen for example when
using pos_loyalty. If a user makes a "buy x get y" program with the
reward being a product with a category not accepted by the config
(e.g. due to a restrict category of the config), the category id cannot
be found in the db of this pos. This leads to problem in pos_restaurant
as under the button order, there is a reminder of the products that
should be sent either to the preparation display or the preparation
printer linked to this pos. If this preparation display or preparation
printer contains the category of the reward, the problem happens.
The fix is to not show the new category (as it is at first not available
due to the restrict so we comply with the choice of the user).
This might be a temporarly fix while waiting for a better solution.
closesodoo/odoo#131379
X-original-commit: a82b550dcf4311ee35570f5b9dc37bf50a46c17d
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
pos*: point_of_sale, pos_hr, pos_restaurant
In this PR we fix a number of small UI issues in the point of sale app.
Issues fixed:
- Align filter option in the TicketScreen search bar;
- Align items in the opening popup that shows the available
login options in the pos_hr module;
- Align tips column in ticket screen;
- Made it so clicking on the employee icon does not open the
selection popup if there is only one employee configured
( as it will be empty in this case );
closesodoo/odoo#131351
Task: 3458435
Related: odoo/enterprise#45526
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
As all the templates are now imported in the owl app, there is not need
anymore to specify the owl="1" attribute in the templates.
Part of task~3443861
Part-of: odoo/odoo#130467
Improve gettext to directly handle value injection within translations,
removing the need for sprintf.
closesodoo/odoo#123932
Related: odoo/enterprise#45370
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
In this PR we fix a number of small issues related to the pos ui.
In addition to the specific fixes, this PR also simplifies many
of the components, most notably the `category_selector`.
In the interest of providing a cleaner API, this PR introduces
a new folder called `generic_components` whose goal is to contain
stateless components. These stateless components would allow for more
reusability, while simplifying the logic. The `category_selector` is
the first component in this folder.
Descriptions of each of the issues fixed in this PR can be found in the
closesodoo/odoo#131038
Tasks: 3457213
Related: odoo/enterprise#45600
Signed-off-by: Joseph Caburnay (jcb) <jcb@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>
In the commit [1], the patch has been refactored to support the
native keyword `super`. The current commit just adapts the codebase
to that change.
task 3410198
[1]: 19ea1ac08043e22a811630968e44715cc3bfc495
Part-of: odoo/odoo#125716
pos*: point_of_sale,pos_hr,pos_loyalty,pos_restaurant,
pos_sale,
In this commit we refactor some parts of the pos ui with the interest
of providing a simpler and cleaner codebase.
One pattern that is heavily used in the pos ui is that in which
views are changed based on the screen size at the component level.
This means that it becomes very difficult to understand what parts
of a specific template will be seen in mobile or in desktop views.
In most cases, the pos adapts for mobile screens by using the same
main components, but in different configurations. For example, a
component that was visible in desktop mode, might become accesible
through a menu in mobile mode.
In order to improve the situation, the proposed solution is to
separate the logical parts of the ui into `owl templates` and
to inject this templates wherever the need arises.
Thus, instead of constantly using `t-if="ui.isSmall"` in all places
where there is a difference between the mobile and desktop views,
we have a main conditional branch at the root level of the component
representing a certain screen and then build 2 separate views, one for
mobile and one for desktop, each calling the needed templates.
In this commit we implement this pattern for the `payment_screen`.
This will allow us to observe this pattern over a period of time,
before implementing it on the other screens.
In this commit we also:
- add small fixes and improvements relating to
the previous commit, in which the pos was
refactored to bootstrap;
- replace the `<br>` tags in the numpad component
with the bootstrap grid system;
- adapt the `cash_move_popup` to rely more on `t-model`
and less on `t-on-change`
Part-of: odoo/odoo#129544
Co-authored-by: vlst <vlst@odoo.com>
Co-authored-by: Xavier Luyckx (xlu) <xlu@odoo.com>
pos*: point_of_sale,pos_discount,pos_hr,pos_loyalty,
pos_restaurant,pos_sale,pos_sale_product_configurator,pos_six
Prior to this commit, the point_of_sale module relied on custom CSS.
To enhance user experience, increase flexibility, and simplify maintenance,
most of the custom css was replaced in this PR with Bootstrap utility classes.
Task: 3354582
Authored-by: Xavier Luyckx (xlu) <xlu@odoo.com>
Part-of: odoo/odoo#129544
Co-authored-by: vlst <vlst@odoo.com>, Pedram (pebr)
When computing the category count for the ActionpadWidget, it is
possible that a product does not have one. If it doesn't, we do not take
it into account in the category count. This implementation also fixes
the crash when opening an order with a order change with a product
without category.
closesodoo/odoo#129960
X-original-commit: 86c69c2f4f91bfc91871ca0c4f6ea5acff3c975c
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
A recent PR removed some lines in the pos_restaurant tour
( odoo/odoo#124157 ). This commit put them back to avoid runbot error.
closesodoo/odoo#129155
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
pos*: l10n_ae_pos,l10n_co_pos,l10n_fr_pos_cert,l10n_gcc_pos,
l10n_in_pos,l10n_sa_pos,pos_adyen,pos_discount,
pos_epson_printer,pos_hr,pos_hr_restaurant,pos_loyalty,
pos_mercury,pos_restaurant,pos_restaurant_adyen,pos_restaurant_stripe,
pos_sale,pos_sale_loyalty,pos_sale_product_configurator,pos_six,
pos_stripe
In the previous commit, we moved and renamed files such that they
better follow certain guidelines.
In this commit, we adapt imports accordingly.
In order to efficiently accomplish this task, i used the following [script](https://github.com/vlst-odoo/tools/blob/main/fixImports.py)
Task: 3394192
Part-of: odoo/odoo#127056
pos*: l10n_ae_pos,l10n_co_pos,l10n_gcc_pos,l10n_in_pos,
l10n_sa_pos,pos_adyen,pos_discount,pos_epson_printer,
pos_hr,pos_hr_restaurant,pos_loyalty,pos_mercury,
pos_restaurant,pos_restaurant_adyen,pos_restaurant_stripe,pos_sale,
pos_sale_loyalty,pos_sale_product_configurator,pos_six,pos_stripe,
The POS has a large number of add-on modules. As such, it is
important that they all respect strict guidelines when it comes
to file structures.
Before, each module had more or less it's own rules when it came to
this, apart from the fact that code was mostly organised into
`js` and `xml` folders.
In this PR, we move to a much more structured approach,
in which each module follows the following pattern:
src/
|-- app/ <-- the module's own new logic
|-- overrides/
| |-- components
| | |-- overridden_component_a
| | | |-- overridden_component_a.js
| | | |-- overridden_component_a.xml
| | | |-- overridden_component_a.css
| |-- models
| | |-- overridden_model.js
Apart from the structural changes, this PR introduces changes
to file names, such that they respect the default pattern of
snake_case naming.
In this commit, we move the files. In the following one we
make the needed changes in the code, such as adapting imports.
In order to efficiently accomplish this task, i used the following [script](https://github.com/vlst-odoo/tools/blob/main/rename.py)
Task: 3394192
Part-of: odoo/odoo#127056
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>
The goal of this commit is to prepare ground to remove
lazytranslate function _lt() and keep only _t()
for a better understanding of the use of the translation function.
In this commit,
the translate function _t() has been updated to return the translation
if they are loaded. If not, it throws an error.
the lazytranslate function _lt() returns _t() function.
Corollaries :
Steps in test tours are now a function that returns an array of steps
to avoid any interpolation of _t in this ones before translations has
been loaded.
Example :
registry.category("web_tour.tours").add("example", {
test: true,
steps: () => [
{...},
{...},
],
});
task-3292454
closesodoo/odoo#124157
Related: odoo/enterprise#43153
Signed-off-by: Samuel Degueldre (sad) <sad@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>
- Fixes tips ticket printing when there are tips after payment.
- Makes the ReceiptScreen opened after TipScreen, to show the receipt screen even when there is a tip added after payment.
closesodoo/odoo#127548
Task-id: 3394214
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The pos_restaurant first test (test_01_pos_restaurant) has an assertion
that failed due to the fact that the deleteion of an order is
not awaited in the frontend. This led to the tour finishing very fast
after the orm call and the assertion done just after that. We add steps
in this test to see if the orm call has been done propely before ending
the tour.
Runbot Error: 22613, 22614
closesodoo/odoo#126779
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
pos*: point_of_sale, pos_restaurant
When deleting an order, the restaurant override of the deletion function
in `point_of_sale` interferes with the logic in such a way that we end up
writing the order that needs to be deleted 2 times.
This is obviously not the expected bahaviour. In this PR we remove
the `override` from `pos_restaurant`, as it is no longer needed and
we also add a mechanism that ensures that orders cannot be duplicated.
closesodoo/odoo#126442
Task: 3383043
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
pos*: pos_loyalty, pos_restaurant, pos_sale,
pos_adyen, pos_six, pos_stripe
At the moment, the `pos` models don't have access to the `env` variable.
This makes using `env` inside a model rather awkward.
This PR makes it so all the pos models have access directly to `env`.
closesodoo/odoo#124320
Task: 3358456
Related: odoo/enterprise#42209
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>
Previously, when conducting a refund on a table, the system would
switch the active table to the table associated with the refunded
order. This was not the desired behavior, as it resulted in the details
of the order disappearing, requiring the user to navigate back to
the refund process.
Steps to reproduce the issue:
- install PoS restaurant
- pick a table, do an order and pay it
- pick another table, refund
- choose the previous order and refund
-> the order details disappear directly. You have to go back to refund.
opw-3301603
closesodoo/odoo#125908
X-original-commit: 1f560c8954359a15ba84eb695c7eca380722f9fc
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Currently, a product can only be part of one `pos_category`.
This PR changes the relationship between the `product` and the `pos_category` from a `One2many` to a `Many2many`.
closesodoo/odoo#122907
Task: 3138825
Related: odoo/enterprise#41791
Related: odoo/upgrade#4739
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
*: l10n_ae_pos, l10n_co_pos, l10n_fr_pos_cert, l10n_gcc_pos, l10n_in_pos, point_of_sale,
pos_adyen, pos_discount, pos_epson_printer, pos_hr, pos_loyalty, pos_mercury,
pos_restaurant, pos_sale, pos_sale_product_configurator, pos_six, pos_stripe
After the architectural refactor of the PoS App, there are two classes that make sense to merge.
In this refactoring task, we're merging them.
closesodoo/odoo#124477
Task: 3358550
Related: odoo/enterprise#42257
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
David Monnom (moda)