*: l10n_co_pos, l10n_fr_pos_cert, l10n_gcc_pos, l10n_in_pos,
l10n_sa_pos, pos_adyen, pos_discount, pos_epson_printer,
pos_epson_printer_restaurant, pos_hr, pos_loyalty, pos_mercury,
pos_restaurant, pos_restaurant_adyen, pos_restaurant_stripe, pos_sale,
pos_sale_product_configurator, pos_six, pos_stripe
We are about to refactor most of the Javasript code base of the point of
sale and related modules. In doing so, we will move a lot of files and
modernize the entire code-base. In order to avoid diffcult rebases,
their conversion to odoo-modules is done as a first step to avoid
getting lots of conflicts on files that were unindented, which marks the
entire file as being in conflict. Conflicts will occur during forward
ports but they will be easier to manage as the changes will be much
smaller in scope, and the author will have the context of the change
that causes the conflict in mind when dealing with it.
closesodoo/odoo#107621
Related: odoo/enterprise#34910
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Unused catch block arguments are now forbidden even when prefixed with an
underscore: if the argument on the catch block is not needed, the use of the
optional catch binding is enforced.
Part-of: odoo/odoo#105433
Before this commit: if the "Limited Partners Loading" were enabled, the
partner wouldn't set when using the "Quotation/Order" functionality
for unsynced partners.
Steps to reproduce the issue on the runbot:
Enable developer mode.
Go to the Point of Sale.
Open the config of any pos.
Enable "Limited Partners Loading" and set "Number of Partners
Loaded" to a low number (like 5 or 10)
Disable "Load all remaining partners in the background."
Open a new PoS session for the configured PoS
Use the "Quotation/Order" functionality.
Select any order, for example, S00043.
The customer is not set for the current pos order.
Solution
The solution is to load the partner.
Also, there was an issue when using the limited number of partner loading
when it tried to load the cached and paid orders' partners. I added a function
to load missing partners.
opw-2883686
closesodoo/odoo#97442
X-original-commit: 4d7c05346e0c253c8b11736b9ee9f8426a87f2af
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Because MobileSaleOrderManagementScreen is rendered inside
SaleOrderManagementScreen, the `useListener` calls in
SaleOrderManagementScreen are called twice. This is because
MobileSaleOrderManagementScreen is derived from
SaleOrderManagementScreen. Because of this, when an event is triggered
in the SaleOrderManagementScreen, say the 'click-sale-order', the
handlers are called twice. To fix this, we should not render
MobileSaleOrderManagementScreen inside the SaleOrderManagementScreen
anymore. Instead, depending on the screen size of the device, identified
using `env.isMobile`, we show the appropriate screen, that is, when
`isMobile` is true, we show MobileSaleOrderManagementScreen otherwise,
we show SaleOrderManagementScreen.
closesodoo/odoo#95282
X-original-commit: 6a8a43d09a798be3dfc5581561b67bc5c5521634
Signed-off-by: Masereel Pierre <pim@odoo.com>
When opening the sale order management screen, we should always start
with the default domain so that we don't have instances where fully-paid
sale orders show in the screen.
X-original-commit: 5b8cff6a545d1fb3ee614cdd347e0aa463dc8a5e
Part-of: odoo/odoo#95282
When in mobile view, the sale order management screen don't show when
clicking the Quotations button.
This change fixes this problem. Check the comments in the changes for
more details.
X-original-commit: 4ac8c363213dec747a7ca1bf5f2b22c6e2c6abf2
Part-of: odoo/odoo#95282
Because the setup method is not properly executed, sale order management
screen crashes when viewed in mobile screen.
X-original-commit: c27716c97c4d32bb0b12f3772ea55941fa423c63
Part-of: odoo/odoo#95282
Sale orders' amount in POS are displayed in the POS currency but they
can be in another currency making it possible to settle the wrong amount
Steps to reproduce:
1. Install Point of Sale and Sales
2. Go to Settings > Invoicing > Currencies and activate another
currency (e.g. EUR)
3. Go to Settings > Sales > Pricing > Pricelists and create a new
pricelist for the new currency
4. Create a new Sale Order with the EUR pricelist and any product and
confirm it (do not invoice)
5. Open a new session in the POS Shop
6. Go to Quotation/Order
7. The new SO is displayed with the amount in EUR but the currency
symbol is USD
Solution:
Add a filter on the POS currency to the domain of the rpc call
search_read on sale orders
Problem:
The field `amount_total` is used to display the price but this field can
be in any currency
opw-2865371
closesodoo/odoo#94710
X-original-commit: 0ebe29c794813a0854c7a6f433088a919a52cbbc
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Currently, when customer does not specify taxes on down payment product in pos
and tries to use down payment for quotation, they get javascript error.
With this fix we will assign down payment tax 0 in case there is no tax
specified
fixes OPW-2843483
closesodoo/odoo#91077
X-original-commit: c6ec2ccf611fa099187f0547222a5fa3c09da9af
Signed-off-by: Masereel Pierre <pim@odoo.com>
If applied, this commit will fix the following bug by making the
behavior of applying a down payment similar to doing it in sales app
Steps to reproduce:
1- install sales, POS
2- set customer tax t on down payment product and use the product in
POS and sales
3- Create a product p with tax t
4- add p to a new sales order so
from sales:
5-apply a down payment of a percentage per (let's say 100% for clarity)
6- the down payment is calculated correctly and the total amount to
be paid is per * (p.untaxed_price + t * p.untaxed_price)
now from POS:
5- choose SO from the list
6- apply down payment of percentage per
7- the down payment is calcualted incorrectly. the SO is double taxed.
now the amound due is
(per * (p.untaxed_price + t * p.untaxed_price)) * (1 + pos_default_tax)
Bug:
when applying a down payment the full amount is treated as the untaxed
amound and then later the POS tax is added on it.
Fix:
using the untaxed total and also using the down payment product tax
similar to what happens in sales since the 2 flows can be mixed
OPW-2790821
closesodoo/odoo#89915
X-original-commit: 7dbd8d8e6ea5149c0b8d388ebfb1d97e43d47783
Signed-off-by: Masereel Pierre <pim@odoo.com>
When showing the discount the to the public, the down payment and gift card products were taken into account in the discount computation shown in the receipt.
This also fix a mistake made in fc546e0481ae0159e67791240833bc1e38a4440f where it was implemented in the wrong place and returning a wrong value in a reduce callback.
closesodoo/odoo#89603
X-original-commit: 597ea7aa3f28ad82e602e1ba5679bb49d2973b78
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Previously, only one popup is allowed such that when one is not
yet close, but another one is requested, the new one will replace
the old. The function that tries to wait for the replaced popup
will never resolve resulting to some potential broken state.
This commit resolves the said issue which now allows multiple
popups at a time. We can use POS instance without demo as an
example.
Before this commit: The popup that asks whether to load the demo
products will be shown but it will be replaced by the cash opening
popup.
After this commit: The popup that asks whether to load the demo
products will be shown, then the cash opening popup will show.
When the user is done with the cash opening popup, the demo products
confirmation is shown next.
closesodoo/odoo#83661
Related: odoo/enterprise#23859
Signed-off-by: Masereel Pierre <pim@odoo.com>
All named arguments on the catch block must be used. If for some motive
the named argument on the catch block is not used, its name must begin
with '_'.
closesodoo/odoo#85569
Related: odoo/enterprise#24867
Related: odoo/design-themes#552
Signed-off-by: Géry Debongnie <ged@odoo.com>
Multiple refactors
- The module pos_hr had two attributes `cashier` and `employee` referencing to the same actual person. The `employee` attribute was removed for the sake of `cashier`.
- Refactor of the `useSelectEmployee` which returned functions that where used in two components. Instead, a mixin class was implemented and inherited from both components.
- Renaming of the substring `client` and `customer` to `partner` (css included) when it was referencing to the actual `res.partner` object. This way, developers will always know that the object used in the UI is coming from `res.partner`.
- Renaming of the substring `client` to `customer`(css included) when it was referencing to a real life person. This avoid having ambiguity since the term `client` can refers to multiple things (hardware, browser, person, ...)
closesodoo/odoo#83983
Related: odoo/enterprise#24477
Signed-off-by: Masereel Pierre <pim@odoo.com>
Current behavior:
In the PoS when you add an order the 2 terms "Settle the order" and "Apply down payment" where hardcoded in the code.
Steps to reproduce:
- Have PoS and Sale module installed
- Go in PoS
- Try to add an order sale
- The 2 terms are hardcoded and cannot be translated
opw-2754052
closesodoo/odoo#85168
X-original-commit: 440cd020cfce4147973d356fd714a5d78c315c70
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
In 6d13271aac, the API of useAutofocus was chanded but the calls to
useAutofocus in the module point_of_sale were not adapted accordingly.
We adapt them in this commit.
Part-of: odoo/odoo#84306
Current behavior :
When creating an invoice from a PoS the description attached to the product was not the same as the one in the SO
Steps to reproduce:
- create a SO from Sales
- create an invoice from the SO
- preview the invoice
- open a POS session
- fetch the same SO
- validate the order with an invoice
compare the 2 invoices, they are not the same
opw-2674896
closesodoo/odoo#83833
X-original-commit: dbd766f1b87f91eefce7b6e5946856961fd96c70
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
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>
In the next version of Owl, all exported terms are directly available
from the top level `owl` object. This commit aims to adapt existing
imports to this new system. This is done by importing any Owl property
used in files at the top, right after the `import` or `require`
statements.
closesodoo/odoo#82736
Related: odoo/enterprise#23609
Signed-off-by: Géry Debongnie <ged@odoo.com>
When you are choosing to apply a down payment on a sale order in pos,
it'll add a line to the pos order with the down payment product and the
value you choosed.
In this case we are considering that the down payment product is set and
a traceback is triggered when you try to apply down payment.
So we are now handling this error when no down payment is configured.
closesodoo/odoo#83037
X-original-commit: a103a7f3c129cc1140b734f8f0be24cd4b8667b8
Signed-off-by: Masereel Pierre <pim@odoo.com>
Set up a [TEST] product with a tax A
Create a SO with [TEST] and a tax B and confirm
Open POS, import the created SO
[TEST] will be imported with tax A
while tax B should be pulled from the sale order line instead
opw-2699793
closesodoo/odoo#81580
X-original-commit: 0a5cbfeb7edcce6e6bb915d6e61c736491695ada
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Before this commit, when you clicked on "Review" the order lines weren't
visible due to the number of control-buttons.
To fix this, a "More..." button is displayed if there is more than 3 buttons.
When you click on this button, a new modal will display a menu with all controls.
Note that we had to find a way to close this popup after clicking on an action.
Task ID: 2453679
X-original-commit: 430d40f90c1e9a7e8e3663e8f2b129b0c24911e1
Part-of: odoo/odoo#79448
Co-authored-by: Adrien Dieudonné <adr@odoo.com>
Using a list view isn't the best way to display data on small screen.
We had to change this behavior to display a kanban view of orders.
We also merge design of "Ticket" screen and "Order Management" screen.
Task ID: 2453679
X-original-commit: d0e53721a97c14419a2f81ef8aa8be317cc5644a
Part-of: odoo/odoo#79448
Co-authored-by: Adrien Dieudonné <adr@odoo.com>
Following wowl and https://github.com/odoo/odoo/pull/73725, isRpcError
no longer works. We introduce a new method called isConnectionError
since it's actually what we are interested of in the previous use of
isRpcError. After handling connection error, we just rethrow any other
errors such as RPCError (which includes server error such as UserError
or any programming error in the server) and let the errorHandler in
Chrome handle them.
closesodoo/odoo#76661
X-original-commit: a447872b2ef0267d654295ac58dddc74e31d6424
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
After merging https://github.com/odoo/odoo/pull/75322, orderManagement
context and order-management-screen styles were removed by which
pos_sale was dependent. Because of this, settling quotations in pos_sale
doesn't work. We restore the needed context and styles in this commit.
closesodoo/odoo#75809
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When we want to open a quotation from the mobile view, we are
redirected to the POS Orders instead of the sale order.
This is because we are calling the wrong owl component.
Part-of: odoo/odoo#75682
Since now, there was no possibilities to pay a Sale Order in a point of
sale without re-encoding every lines of the sale order in a pos order.
So we've now added the possibility to choose a sale order from the point
of sale, and apply a down payment or settle the selected order. You
still get the possibility to invoice it, and the stock is correctly
managed.
The SO is then updated accordingly to what have been done throught the
POS.
closesodoo/odoo#74096
Task-id: 2500902
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Samuel Degueldre