In this commit we add the ability to toggle between showing and not
showing product and category images in the pos ui.
Because this change is done in stable, we store the user's selection in
`ir.config.parameter`.
In the forward port, this will be removed and the settings will be
stored in `pos.config`
Task 3704416
closesodoo/odoo#151823
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
In this commit we implement barcode scanning functionality
in the `pos_self_order` module.
This is useful for kiosk devices in shops.
closesodoo/odoo#148480
Task: 3637834
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
In this commit we add a line on the receipt with the text
"Odoo Point of Sale" or "Odoo Restaurant". ( depending on the case)
This is done for marketing reasons.
closesodoo/odoo#148094
Task: 3635645
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
In this pr we remove the blank choice in the self-ordering mode select.
It's unnecessary and throws a validation error on saving settings.
Task 3599144
closesodoo/odoo#142351
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
In the commit 7675905 a t-for loop was introduced in the `ActionpadWidget`
override from `pos_restaurant` where the t-key value was undefined.
This commit fixes the issue by giving a proper value to the t-key.
closesodoo/odoo#145919
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
In this commit we update the lists of modules from `_eslintignore` and
`jsonconfig.json` such that they now contain all pos modules.
In addition, we also create script in the `tools` directory of pos that
returns a list of all the pos modules. This list is often very useful.
closesodoo/odoo#142366
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
In the pos one cannot make a payment that is larger than the
required amount if there is no cash payment option.
In order to check this there is a condition in the `payment_screen`.
The problem is that this condition fails to spot certain cases.
Steps to reproduce:
- open a pos that has only one payment method and this method is `bank`;
- buy an item for 10 $;
- try to pay 11 $;
- notice error popup; ( this is the expected behaviour )
- now try to create another payment line for any amount ( ex 9999 $ )
- as this is a different payment line the error popup will not appear;
--> this is wrong
In this commit we change the condition such that it detects this type of
error too.
closesodoo/odoo#141778
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
After the refactor of pos tours all classes in the tours are
removed. The problem is that some instances of `this` were still
kept. This is obviously wrong. In this commit we fix the issue.
closesodoo/odoo#141404
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
In this PR we make the tracking number on the pos receipt
slightly larger.
closesodoo/odoo#141241
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
In this commit we adjust the pos module such that, in the
corresponding enterprise commit, we can more easily add the
tax letters corresponding to each orderline in the receipt.
closesodoo/odoo#140974
Related: odoo/enterprise#50134
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
In this commit we hide the printing errors in `pos_self_order`.
At the moment, they are show to the user, but that is not
desirable behavior in a kiosk environment.
Such printing errors might, for example, be encountered when the printer
is out of paper.
closesodoo/odoo#140271
Signed-off-by: David Monnom (moda) <moda@odoo.com>
1. Install l10n_pos_in
2. Make an order
3. Observer traceback in receipt screen
Similar problem in restaurant ( in bill screen )
closesodoo/odoo#140123
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
pos*: l10n_es_pos, point_of_sale, pos_hr, pos_loyalty, pos_online_payment,
pos_online_payment_self_order, pos_restaurant, pos_sale, pos_self_order
In this commit we refactor all the pos tours.
Changes:
- Removed the `startSteps`, `getSteps` functions as they were
no longer serving a purpose. We now simply put the tours steps
in the array returned by the function given to `steps`. We
apply `flat()` to this array in order to be able to provide both
single steps and arrays containing multiple steps;
- removed the classes from the tours. Now each helper function
is simply exported from it's file and is consumed as `import * as myHelpers`;
- removed the `do`, `check`, `exec` subpaths as they were not providing
a clearer api. The functions themselves already have descriptive names.
( writing `ProductScreen.do.clickHomeCategory()` is not clearer than
`ProductScreen.clickHomeCategory()` )
- formatted all files.
closesodoo/odoo#139317
Task: 3565443
Related: odoo/enterprise#49313
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
In this commit we simplify the POS kanban view by replacing some
of the text shown to the user with more relevant versions.
Task 3562493
closesodoo/odoo#139246
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
After the recent changes (commit d149b8a) in the `OrderReceipt`, we have to adapt the
`l10n_sa_pos` module.
In this commit we add the necessary code.
closesodoo/odoo#139208
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
*point_of_sale, pos_self_order, pos_self_order_epson_printer
In this commit we introduce the functionality that allows
the pos_self_order module to generate receipts.
At the moment, this is possible by using Epson Printers via HTTP.
This is done through the use of the newly added bridge module
`pos_self_order_epson_printer`.
In order to generate the data required for the receipt we add more data
on the first load of the kiosk ( such as company information ) and
also in the `_export_for_self_order` method.
Printing is done through the `printer` service from POS.
closesodoo/odoo#137397
Task: 3487638
Related: odoo/enterprise#48304
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
pos*: l10n_co_pos, l10n_fr_pos_cert, l10n_gcc_pos,
l10n_in_pos, l10n_sa_pos, point_of_sale,
pos_epson_printer, pos_loyalty, pos_mercury,
pos_online_payment, pos_restaurant, pos_sale
There is a need to print pos receipts in new environments,
such as the kiosk. In this commit we simplify the steps to
generate the receipt data and introduce a portable mechanism
for printing.
Changes:
- removed the `getOrderReceiptEnv` method; this method
was returning a lot of data that the receipt was not
actually using; we now simply use the data from
`Order.export_for_printing`. This means that it will be much
easier to recreate this data in other environments, such
as in the kiosk.
- removed the error prone `generate_wrapped_product_name` method.
It's aim was to split the orderline name, but this task is much
better accomplished by declarative css.
- removed the `Orderline.export_for_printing` method; instead,
we simply use the existing `Orderline.getDisplayData`;
- removed the `AbstractReceiptScreen` component and replaced
it's functionality with the new `printer` service;
- using this service means that we were free to remove
the `pos-receipt-print` div from the root of the pos app;
- made the receipt be a standalone component. It thus benefits
from all the advantages of components, such as prop validation
and usage of slots;
- replaced the `OrderLinesReceipt` template with the generic
`OrderWidget` component'; this greatly simplifies the code;
- created the `renderer` service. It's goal is to do for components
what `renderToElement` does for templates; we use this service to
render the receipt component for printing;
- removed jquery from the EpsonPrinter class, such that it can be
imported into projects that do not rely on jquery;
- created the `ReceiptHeader` component. This unifies the header
between all the different receipts; ( before, each receipt was
implementing it's own header )
Task: 3547597
Part-of: odoo/odoo#137397
pos*: point_of_sale, pos_online_pay
In this pr we remove the custom generation of qr codes and
adapt the codebase to rely on the `/report/barcode` api.
Task: 3550015
Part-of: odoo/odoo#137397
The `MoneyDetailsPopup` allows users to specify the exact
amount of each coin or bill present at the closing of the session.
This popup does not however have a easy to use interface, as there is
no button to increment/decrement the number of bills of a certain type.
In this commit we create a new component called `NumericInput`.
This is an input surrounded by increment/decrement buttons.
We use this component in the `MoneyDetailsPopup`.
We create the component `TModelInput` in which we extract the functionality
used by both the new `NumericInput` component and the existing `Input` component.
We also refactor the `Input` component such that it now extends this new `TModelInput`
class.
closesodoo/odoo#138851
Task: 3555403
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
In Spain it's mandatory that POS systems generate a so called
"Factura simplificada". This is similar to a regular ticket
but has to comply with some special requirements.
Without this, POS isn't usable in Spain.
In this PR we introduce a spanish localisation for the pos
that handles the specific regulatory needs.
closesodoo/odoo#136008
Task: 3131769
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
After the the POS refactoring, there are no more errors
of type `legacy`, so the function `identifyError`, whose objective
was to identify the `legacy` errrors, is now completely useless.
We thus remove it.
closesodoo/odoo#136833
Task: 3524670
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
The AlertPopup component is identical to the ErrorPopup component,
aside from the fact that the ErrorPopup also plays a sound. We
thus add a new prop to the ErrorPopup that allows the consumer
to decide to have the sound played or not and replace all occurences of the
AlertPopup with ErrorPopup.
closesodoo/odoo#136700
Task: 3522638
Related: odoo/enterprise#47987
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
We introduce a new module that enables restaurants to show
their customers a display with all the current orders, filtered by
their preparation state.
In order to know the preparation state of the orders, we rely on the
information provided by the pos_preparation_display module.
In this commit we create a new function on the `pos.order` model
that returns a tracking number for a certain order.
This tracking number will be used by the `pos_order_status_customer_screen`.
Task: 3514516
We also create a generic OdooLogo component that
renders the odoo logo in svg format.
This component has the prop `monochrome` that dictates which
type of odoo logo will be rendered.
closesodoo/odoo#136065
Task: 3520164
Related: odoo/enterprise#47668
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>
The customer display loads very slowly in the RemoteDisplay mode.
This is in big part because of the large size of the bg image.
This image is loaded on every single update of the customer display.
This PR makes it so the bg image is loaded directly from the server,
in order for it to be cached on the customer display, thus improving
considerately the response time.
closesodoo/odoo#124998
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
After a customer has paid via an Adyen terminal, the Adyen server sends
a request containing the payment confirmation to the webhook on the odoo
server.
At the moment, the pos frontend continuously polls the backend in order
to find out whether or not the confirmation from Adyen arrived.
This pattern is wasteful and over complicated.
In this PR I replace the polling logic with websockets communication.
closesodoo/odoo#125593
Task: 3342693
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The "ClosingPopup" relies on an error-prone pattern of calling
a "handle" function on each input change.
In this commit we refactor it's logic such that the calculation
is done reactively.
This leads to much simpler code.
In addition, we remove multiple pieces of dead code.
closesodoo/odoo#131171
Task: 3499250
Related: odoo/enterprise#47323
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The MoneyDetailsPopup accepts the prop `total`. This popup is used to
keep track of the bills selected by the user and it's total should
thus simply be computed from the given bills information.
Passing the `total` prop and using it as `state` serves no purpose
and leads to bugs, such as the one addressed in this task.
Steps to reproduce:
1. Click on "Close Session".
2. Input a value in the "counted" field
3. Open the "MoneyDetailsPopup"
4. Observe the fact that the "Total" value is the one from the "counted"
field, instead of "0".
This is caused because the `ClosePosPopup` has to also independently keep
track of this `total`, in order to be able to pass it to the
`MoneyDetailsPopup` on future calls.
In order to fix this problem from the root cause, we completely remove
the prop `total` and instead allow the popup to compute it from it's
information about the selected bills. This simplifies the code, preventing
future similar bugs.
Task: 3499242
Part-of: odoo/odoo#131171
This PR introduces the generic `Input` component.
This component is meant to provide a "batteries included" api for working
with inputs. It is well suited to work as a `search bar` or as a `monetary input`.
It has no dependency on the pos app. It can then be used anywhere.
The `Input` component handles:
- `debouncing`;
- toggling between mobile and desktop views;
- `autofocus`;
- validation;
Example usage:
- As a search bar:
```xml
<Input
class="'ms-auto'"
isSmall="ui.isSmall"
placeholder="'Search products...'"
icon="{type: 'fa', value: 'fa-search'}"
callback.bind="(value) => pos.searchProductWord = value"
debounceMillis="99"
/>
```
- As a monetary input:
```xml
<Input
icon="{type: 'string', value: pos.currency.symbol}"
iconOnLeftSide="pos.currency.position === 'before'"
isValid.bind="env.utils.isValidFloat"
callback.bind="(value) => state.amount = value"
autofocus="true"
getRef="(ref) => this.inputRef = ref"
/>
```
In this pr we refactor the
- `ProductsWidget`,
- `CashMovePopup`,
- `ClosePosPopup`,
- `CashOpeningPopup`
components to use the
new `Input` component.
With the previous commit in which we introduced the `CategorySelector`
component and with the use of this new `Input`, the component
`ProductsWidgetControlPanel` was no longer needed and thus removed.
The use of the `Input` component allowed us to also remove the
error prone `useValidateCashInput` hook.
Task: 3459850
Part-of: odoo/odoo#131171
When selecting an attribute value in POS, what we store is the `description`,
which is a string that represents the selected attribute values.
Ex: selecting `Size: M` and `Material: Leather` will result in the description:
`(L, Leather)`.
This choice does not lead to a logical API for dealing with product attibutes.
In this pr, we add a new field that stores the selected `ids` of
`"product.template.attribute.value"` and remove the
`selected_attributes` `Json` field from the `pos_self_order`
override of the `pos.order.line` model.
The `attributeHelper` function from the `tour_utils.js` file
from `pos_self_order` is improved such that it can now handle
both checking if a certain attribute is selected and actually
selecting an attribute.
closesodoo/odoo#126398
Task: 3378533
Related: odoo/upgrade#4992
Signed-off-by: Joseph Caburnay (jcb) <jcb@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>
The products are not correctly loaded in the POS because of a bug
regarding the `Restrict Categories` feature.
Steps to reproduce:
1. Create a `pos config` with `Restrict Categories` set to: `categ1` and `categ2`
2. Disable `Restrict Categories`
3. Open the POS and notice that although all the categories are present in the
category selector, only the products from `categ1` and `categ2` are loaded.
closesodoo/odoo#134645
Task: 3497308
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Products can be created directly from the `pos.combo` view.
Before this PR, such products would not be automatically available in
the POS app.
This PR makes it so products linked to combos are available in POS by
default.
We also introduce an additional check that makes it so products associated
to combos cannot be disabled in the pos.
In this commit we also make it so the `Office Combo` product from the pos
demo data is in the `Desks` `pos_category`.
closesodoo/odoo#133359
Task: 3481899
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Using the POS app, one can buy a combo consisting of multiple products.
In this PR we implement this functionality in the `pos_self_order`.
A user can now navigate to a combo product, select each combo choice
and order the desired combo directly from the `pos_self_order` app.
In this commit we also change the values displayed in the orderlines
of the `pos_self_order`, such that they better reflect the values
that would be shown by the POS for the same respective orderlines.
Ex: when buying 5 units of an item that has unit price 138.58, the
POS ( and also the invoicing app, etc ) would display a total price
of 692.88. The self order now does the same, but before it was showing
692.90 for the same situation.
closesodoo/odoo#134169
Task: 3437447
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>
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>
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>
Impacted Version : Master only
Issue: Traceback when clicking on the `New` button
in the `POS Product category` view.
Steps to reproduce :
Step 1: Open POS
Step 2: Go to Configuration
Step 3: Open product category
Step 4: Click on New -> traceback appears
The cause of the issue is trying to access properties
on a record that is not yet created.
The solution is simple: we adapt the code such that it
can handle the case where the record is not yet created
closesodoo/odoo#130398
Task: 3450117
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
In this PR we introduce the ability to create product combos.
Now any product can be turned into a combo meal by defining
the different combo choices it contains.
In this PR, we add the backend logic and the backoffice views
needed for this feature. Afterwards, different modules will be
able to use the platform provided by this PR in order to integrate
`product combos` in their flows. Such modules are the `point_of_sale`
and `pos_self_order`.
closesodoo/odoo#128857
Task: 3430635
Signed-off-by: Joseph Caburnay (jcb) <jcb@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
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,l10n_ae_pos, l10n_gcc_pos
Currently, the pos receipt shows the total amount of taxes paid.
Different localisations require more information regarding the taxes
to be shown on the receipt.
In this PR we improve the receipt by adding specific information
for each of the applied taxes and a mechanism that would allow
each localization to more easily display the proper tax information.
This change makes it so the pos is in accordance with the United Arab Emirates
regulations by default. This means that we are removing the `l10n_ae_pos`
module, as we no longer need it.
closesodoo/odoo#125418
Task: 3305403
Related: odoo/upgrade#4858
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
At the moment, the partner editor in pos does not use the owl
reactivity system, using instead an onchange function on each
input and manually keeping track of state.
This approach is overcomplicated and leads to bugs.
The necessity of this task first appeared because of one such bug,
namely: the `state` input options not changing in order to reflect
the selected `country`.
Instead of finding a patch for this problem, we decided in this PR
to replace the old logic, making use of `useState` and `t-model`.
closesodoo/odoo#126021
Task: 3323874
Related: odoo/enterprise#43372
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>
In the pos one might often need to see the orders of a specific customer.
In order to accomplish this, a pos user would need to search for the
customer's name in the orders screen.
In order to simplify the flow, this PR introduces a new button on the
customer's page that can be used to navigate directly to the orders page
with the customer's name prefilled in the search bar.
closesodoo/odoo#125222
Task: 3298155
Signed-off-by: Joseph Caburnay (jcb) <jcb@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>
Currently, deleting contacts (partners) while a pos session is
open is not allowed.
(Even if the respective partner isn't part of any POS sessions)
This creates a bad experience in Contacts, with too many
unnecessary User Errors.
This PR fixes this issue, by allowing the deletion of contacts
even when a pos session is open, by introducing logic that
handles the cases where a contact might be deleted during an i
active pos session.
closesodoo/odoo#124152
Task: 3349851
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>
When a `pos` is configured as `self order`, the dashboard buttons become misaligned.
This PR brings back the buttons into alignment.
Task 3357989
closesodoo/odoo#124255
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The link to the `Floor Plans` configuration is only visible in debug mode.
This makes for a bad user experience.
This PR makes it so the link is always visible to `pos users`, regardless of whether
or not the user is in debug mode.
Task: 3357989
Part-of: odoo/odoo#124255
*: l10n_fr_pos_cert, pos_discount, pos_loyalty, pos_sale, pos_self_order
The `Orderline` model contains the fields: `price_manually_set` and `price_automatically_set`.
They are meant to signify what type of price the orderline has: `automatic`, `manual` or `original`.
It's very confusing to manage the two fields when in fact they only describe three types of setting the orderline price.
This PR replaces the 2 fields with a single one: `price_type`, which will take one of the 3 possible values.
closesodoo/odoo#124858
Task: 3358265
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
The `Preparation Display` is only available in the `enterprise` version, but it's setting does not reflect that
This means that in community, one sees the option to enable the `Preparation Display`, without any sort of feedback as to why the optiondoes not actually work.
This PR adds the `enterprise` flag next to the name of the option. Now, when a user of the `community` version tries to enable the option, they are greeted with a popup that explains the situation.
closesodoo/odoo#124178
Task: 3349726
X-original-commit: b57b64158ab3c64f581ed643b0617ffac98bceee
Signed-off-by: Monnom David (moda) <moda@odoo.com>
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
The process of emailing _gift cards_ bought from the Point of Sale is rather confusing.
This PR makes the experience more intuitive.
closesodoo/odoo#123222
Task: 2711714
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Currently, the `Counted` value in the closing popup is improperly formatted.
Steps to reproduce:
1. Open a new session and create an order';
2. Pay 5.06 dollars with `Bank` and the rest with `Cash`;
3. Close the session;
4. Observe the value `5.0600000000000005` instead of the expected `5.06` in the `Counted` field for the `Bank Payment Method`
This PR addresses the issue by correctly formatting the value.
closes odoo/odoo#123234
Taskid: #3332861
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
This PR aims to fix some small styling issues from the pos_self_order app.
closesodoo/odoo#122502
Signed-off-by: Guilliams Adrien (adgu) <adgu@odoo.com>
This PR adds the arrow icons to buttons in the QR Code menu settings in the interest of making the styling more uniform with the rest of the page.
closesodoo/odoo#122488
Closes: 3339325
Signed-off-by: Guilliams Adrien (adgu) <adgu@odoo.com>
The buttons for the QR Code Menu setting are quite unappealing. This PR changes their style.
Closes 3338270
closesodoo/odoo#122301
Signed-off-by: Monnom David (moda) <moda@odoo.com>
Currently from the pos_self_order app a customer can only view the menu.
This PR adds the option to order items.
A customer of the restaurant will now be able to scan a qr code on their table, and navigate to a website where they will be able to order items from the pos.
The customer can select product variants and add a specific notes for each of the ordered products.
This version does not support online payment. This means that the customer will still have to pay by the usual methods.
The pos can be configured such that a customer can add items to an existing order. For example, ordering a second coffee will result in an update of the existing pos order containing the first coffee. Alternatively, the pos can be configured such that each order made from the web app results in a new pos order. Orders made from the self order app will be placed in the same pos session as regular orders. Once a customer orders from the self order app, a new order will appear in the pos app. Thus, a waiter will be able to quickly see all the orders placed by customers from the self order app. He/She will then be able to send the order to the preparation display. This step has to be done manually.
In the interest of security, each table now has an associated access token. It is included in url that the customer gets from the qr code. When sending the order, the self order app also sends back to the server this access token. The server will only process the order if it receives a valid access token. When placing an order, the server will respond with the pos_reference and access_token of the created order. The web app will keep this data and will send it back to the
server as a proof of ownership in the event that it intends to get the latest state of the order or to update it. The server will only reveal information about an existing order when the request contains a valid pair of pos_reference and access_token.
closesodoo/odoo#121029
Task: 3058586
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
New module that would allow restaurant customers to see the menu on their own devices by scanning a qr code and navigating to the provided link.
Task id 3232765
closesodoo/odoo#114022
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
vlst-odoo