currently the table_id, customer_count fields are editable from the pos order form in the backend and all the other fields are readonly
closesodoo/odoo#107135
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Splitting the method `_get_order_lines` will allow making it
inheritable, this way more order line fields can be added and expand
them easily and avoid having to overwrite it.
closesodoo/odoo#105858
X-original-commit: 457624160f03c28e9b90d14fb4c56fe2f7fabeed
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Current behavior:
When you open the order list, the orders are displayed in UTC.
Steps to reproduce:
- Be sure you are in a timezone different than UTC
- Start a PoS restaurant session
- Go on a table and make and order
- Go on the order list
- Go back on the table, then go back on the order list
- The time showed for the order is not correct (it's in UTC)
This bug was happening because `moment(order.validation_date)` consider
that the date is already in the local timezone, so it doesn't apply the
timezone offset. So we have to apply the offset manually before sending
it to the frontend.
opw-3002417
closesodoo/odoo#105417
X-original-commit: bd366a6d11fd8864b4c2fd2819463449d6da5278
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Before this commit: if you use the lot/serial number for the products, it
won't load correctly through the UI.
closesodoo/odoo#103940
Issue: https://github.com/odoo/odoo/issues/100888
X-original-commit: 0e2ea5ff786185a72916e5582fdbf45271819b8c
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Before this commit: if more than one user work on a PoS restaurant, the
synced validated orders wouldn't remove from other user devices.
Steps to reproduce the issue:
1. Create a PoS resturant
2. Login to the PoS with two different browser
3. Create some orders with some products in one of the browsers
4. Complete the orders in another browser
=> Orders will not remove from the first browser
The solution is to retrieve the latest orders of every table when going to
the TicketScreen
opw-2925193
closesodoo/odoo#100353
Related: odoo/enterprise#32871
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
With this change, we are now assuming each field that starts with
'pos_' to be a 'pos.config' field that has value that will be saved
to the 'pos_config_id' record. We made that modification because by keeping
some related fields not written at the same time can trigger contraints at the
wrong moments that would lead to validation errors when not supposed to be.
Part-of: odoo/odoo#97032
Purpose:
- Move PoS settings in general settings to be consistent with the rest
of Odoo (PoS being the only app where settings are split in two locations)
- Clean settings by enabling obvious settings or dropping unnecessary ones.
closesodoo/odoo#84719
Task-id: 2753430
Related: odoo/upgrade#3260
Related: odoo/enterprise#24425
Signed-off-by: Masereel Pierre <pim@odoo.com>
Moved the cross behaviors and logics in a new link module. This avoid having to
create hook methods in the `point_of_sale` that needs to be overridden.
closesodoo/odoo#92256
Signed-off-by: Masereel Pierre <pim@odoo.com>
Before this commit: In the PoS Restaurant, if the employee is not
installed, the orders wouldn't contain employee_id, and UI couldn't get
table draft orders.
Steps to reproduce the first issue:
- Install the' Point of Sale' module
- Make sure Employees (hr) isn't installed
- Create a PoS with "Is a Bar/Restaurant" enabled
- Open a PoS session in the incognito window
- Add the product to the orders for different tables
- Close the incognito window and open it again
It couldn't get table draft orders from the back-end.
Solution
It must check that "employee_id" exist in the dictionary.
opw-2856653
closesodoo/odoo#92157
X-original-commit: 822d444f74edf8dd9bae7a01d3646e0888128901
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Current behavior:
In PoS restaurant cashier were not saved correctly in db if you
switched table before making the payment of the order.
Steps to reproduce:
- Install PoS
- Activate restaurant on one of your PoS
- Activate Authorized employee
- Start a PoS session, and select a cashier
- Create an order on a table
- Leave the table and comeback to it
- Make the payment for the order
- Go in the PoS orders, the cashier wasn't saved
opw-2794574
closesodoo/odoo#91447
X-original-commit: 2c6ea058f9f8cfaf75529ff4028913a59f021ab8
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Cleaning of the principal methods used in the pos_restaurant flow. This make the code a lot more readable and maintainable as we strive for the single responsibility principle.
A few notable changes:
- [REF] `point_of_sale.assets` in `pos_restaurant` now uses glob syntax (`**`) for the js files, no need to add them in the manifest anymore.
- [MOV] Moved some methods to `pos_restaurant` (because it was only used there) from the `point_of_sale`
- [REF] Only the created, removed and updated orders of a table are being sent to the server once we reach the Floor Screen. Before, all the orders of a table were being sent to the server as the newest state. This led to some synchronization problem when two users wanted to modify each a different order of the same table, the user leaving the table last had **all** his orders states (even the ones he didn't modify) pushed to the server.
- [IMP] After a table transfer while being in offline mode, the transferred order is saved locally (if not yet synchronized) and going back to the previous table after getting the connection back will no longer show the transferred order after the orders fetching from the server.
- [FIX] When an order is selected (normal Point of Sale and in a table in `pos_restaurant`), the selected order is not changed in the Ticket Screen when deleting an order unless the deleted order is the current selected order.
- [FIX] Same as above but while settling all the tips from the `Ticket Screen`
- [FIX] Errors are now properly handled in the `Floor Screen` depending on the context.
- [REF] Kitchen order printing flow has been revamped and improved. This also fixes a bug where we would print a cancelled receipt changes for a skipped order line when adding a product which was already printed before (add 1 product => print => add same product + skip => print would give a cancelled changes for this order line).
closesodoo/odoo#85956
Related: odoo/enterprise#25051
Related: odoo/upgrade#3375
Signed-off-by: Masereel Pierre <pim@odoo.com>
Current behavior:
When using variant in PoS the price was not always correct
Steps to reproduce:
1. Set up items with modifiers (Modifier type must be of type variant creation mode : never, where adding a modifier leads to a different price than with the base item e.g. base item is 10 USD, modifier is 5 USD, total price is 15 USD;
2. Activate Product configurator and make sure it's a Bar/Restaurant in the PoS settings
3. Select the items with the modifier;
4. Leave the table and come back to the table
5. Change the quantity of this product
6. The price is back to the base price without the modifier
opw-2696529
closesodoo/odoo#83444
X-original-commit: d959dfada11a72d6bc275b35f5eeb06b045a0dea
Signed-off-by: Masereel Pierre <pim@odoo.com>
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
This commit accomplishes multiple objectives:
1. Loading of model data for the POS UI is now done in single
request (with some exemptions).
2. Backbone.js is removed and is replaced by reactivity.js
authored by the js framework team.
3. Better organization of assets in the `__manifest__.py`
Data Loading
------------
One request per model -- that's always been how the data is loaded
in POS UI. Now, we move the aggregation of data to the backend which
simplified the data loading. In the frontend, data loading is
initiated in `load_server_data` which makes the single rpc call
to the `load_pos_data` defined in `pos.session` model.
There remains some rpc calls during loading but the number is
greatly reduced.
This change result to faster loading of the POS UI. However,
there is no more progress bar during the loading.
Notable entry points:
- .js: `PosGlobalState.load_server_data`
- .py: `pos.session.load_pos_data`
It is possible to make customizations in the loading, but is done in
several steps:
1. Override `_pos_ui_models_to_load` to include the new model to load.
2. Define `_loader_params_<model_name>` to define the `search_params` and
optional `context`.
3. Define `_get_pos_ui_<model_name>` to return the data that will be
included in the full `loaded_data`. Perform the organization in this method
whenever necessary.
4. Override `_pos_data_process` for further post processing. The final
form of `loaded_data` in this method will be sent to the frontend.
Removal of Backbone.js
----------------------
POS is no longer dependent from `Backbone.js`, but it's replaced by a
new dependency -- `reactivity.js`. It's invented by the js framework
team which will be available in owl v2.
The consequences of this change are the following:
1. The old `PosModel` is renamed to `PosGlobalState`.
2. The name of the other models are kept (except Paymentline which
is renamed to Payment).
3. The name `PosModel` is now used as the base model of the data models.
This is symmetric to our use of `PosComponent`.
4. The instance of `PosGlobalState` is made reactive in `Chrome` (the
root component). As a result, whatever mutation made in that instance,
`Chrome` will rerender. But rendering is batched so multiple mutations
in a single sychronous function call will only result to a single
render call.
5. `PosModel`s can be extended in the `Registries` the same way as we
extend the `PosComponent`s.
```js
// E.g.
Registries.Component.extend(Chrome, PosResChrome);
Registries.Model.extend(Order, PosResOrder);
```
Reorganization of assets declaration
------------------------------------
This is a simple change that replaced the explicit enumeration
of loaded .js and .xml files. Also, we now have regions in the
manifest separating:
1. Augmentations of dependencies
2. Assets for `point_of_sale.index`
3. Assets for the qunit test (soon will be improved)
Other notable changes
---------------------
- Automatic call to `Order.save_to_db` is batched.
- Instances of `devices.DeviceProxy` (`proxy`), `devices.JobQueue`
(`proxy_queue`) and `BarcodeReader` (`barcode_reader`) are moved
to `point_of_sale.env`. Together with `posbus` and `posMutex`
(previously `flush_mutex`).
- `ActivePrograms` is now passed a props.
- `cashier` is no longer saved to `localStorage`.
- `pos_cache` is overhauled.
- `cache` is taken out from `PosDB` to prevent infinite rendering
loop whenever `cache` is mutated. It's now called `CACHE` in
the `db.js` file.
- reactive version of `posmodel` is exposed globally when in debug mode.
This means that calling when calling a mutator, the UI will react.
- Added control buttons in the `ProductScreen` is sorted during `Chrome`
setup. As a result, we don't need to worry on the loading order of the
control buttons components.
- Model can be simply instantiated using `BaseModel.create(obj)`. This
takes into account the extensions.
- `pos_coupon`: rewards are now updated whenever set_order is called.
- Component unit tests were removed. It wasn't useful and it just blocks
the development. We'll be introducing better unit testing later.
closesodoo/odoo#82461
Related: odoo/enterprise#23344
Signed-off-by: Masereel Pierre <pim@odoo.com>
Co-authored-by: Jacky (trj) <trj@odoo.com>
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Current behavior :
When you add a promotion campagn to a PoS the promotion is applied
on every line of every order everytime you load the order. This cause situations
where you have multiple discount for a single product.
Steps to reproduce:
- create a standrard promotion program (automatically applied, 10%)
- set that promotion on the PoS (bar)
- open a session, chooses a table and make an order --> promotion correctly applied
- get out of the table and go back to the same table --> 2 additional lines are created because of the promotion
opw-2699544
closesodoo/odoo#81096
X-original-commit: 72d6431eb26654b697fc0379f4b6d7e305bb79fc
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
To avoid the use of certificates when using direct devices
POS was redirected in HTTP
With new Chrome or Edge security measures this is no longer possible.
We add here the possibility to choose to redirect
the POS in https by adding a specific key in the parameters
closesodoo/odoo#78247
X-original-commit: 9cecb3bdbf5679b6d1d18dc2a250c86118bca6ce
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
In some use cases, the seller in point of sale needs to add a note on an
order line that has to be displayed on the receipt. So we've added a
field on the order line to set a note.
The note is also set on the invoice if the order is invoiced.
closesodoo/odoo#71598
Task-id: 2556994
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Because there are some restrictions with the HTTPS and trusted certificates
We forward, in some cases, the POS and the POS RESTAURANT to a specific url.
HTTPS: /pos/ui
HTTP: /pos/web
To allow rules for webserver
We make this change when we check 'Direct Devices'
And when we use a 'Order Printer' type 'epson_epos'
closesodoo/odoo#74239
Tasks: 2597021
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
With this commit, all instances of errors being raised inside
`BaseModel.unlink` overrides are moved into methods decorated with
`api.ondelete` which is safer.
- Go to Point of Sale > Configuration > Attributes and create an Attribute:
* Attribute Name: Attribute X
* Variants Creation Mode: Never
* Attribute Values: Value Y, Value Z
- Create a Product (i.e. Product X) available in POS with the created Attribute and Values
- Configure a POS and enable the following options:
* Is a Bar/Restaurant
* Product Configurator
- Open POS Session and select a table (i.e. Table 1)
- Select Product X and a value for Attribute X
- In the order summary, the value of the attribute appears after product name
- Go to Floor plan
- Go back to Table 1
The values of all attributes don't appear anymore in order summary
In POS front-end, when adding a product, the name of all chosen attributes values
are registered in a variable named "description".
The full product name displayed in the order summary is generated from display_name
of the product and this "description" variable.
When moving to floor plan, ongoing orders are saved in DB and reloaded when moving
back to a table.
As "description" is not saved, regenerating full product name from display_name of
product and "description" is not possible.
However the generated full product name is saved in DB and can be retrieved.
opw-2371965
closesodoo/odoo#61266
X-original-commit: df3061f6e8061cf039bf083f649b7585c8c31df4
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
As long as the payment is not validated, the cashier can add products
to the order, even if the payment has been completed. The amount
authorized can be adjusted if the payment interface implements the
canBeAdjusted method.
closesodoo/odoo#56656
Taskid: 2117032
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The amount is authorized when the customer scans its card, then the
customer writes the tip on the receipt and the total amount is captured
when the waiter manually inputs the tip, either right after or at the
end of the day.
closesodoo/odoo#56148
Taskid: 2321771
Related: odoo/upgrade#1661
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
This commit fixes the tipping workflow. It includes the following changes:
1. Instead of directly setting tip when clicking a tip amount in tip screen,
we set the input amount to that selected tip. Then we introduce validate
validate button to confirm setting of tip.
2. The tip screen is only shown for non-cash payments. This behavior can be
overridden in extension module in cases where the showing of the tip screen
is only available for certain type of payments.
3. We introduce a way a settle tips for multiple orders in the ticket list.
When the user filters by 'Tipping' status, an editable tip-amount column
appears which can be editted for each order. When tip amounts are final,
settle button will set tip for each order in tipping status.
closesodoo/odoo#56198
Task-id: 2322683
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
1. Introduce an option in restaurant config to allow setting tips after payment.
2. Tip form is shown in bills so the customers can choose/set their tips.
3. Validated orders are kept in TipScreen (access via TicketScreen) so that at the
end of the day, the user/cashier can set the tips for each validated order.
closesodoo/odoo#55488
Task-id: 2117029
Related: odoo/upgrade#1606
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
We now allow invoicing of finalized orders in an open session in this first
iteration of order management in the pos frontend. Additionally, receipt
reprinting is also introduced. With this feature, we can now reprint the
receipt of old orders.
closesodoo/odoo#51141
Task-id: 1981354
Related: odoo/enterprise#11690
Related: odoo/upgrade#1472
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Floors associated to the pos.config are deleted when is_table_management
is set to False from the backend interface because the backend issues a delete
request to the server. So instead of setting the [(5,0,0)] command during
onchange, we set it in write method to avoid unintended deletion of the floors.
Allow the user to archive the payment methods and the floor plans.
Change some typo.
Allow manager to have access to the cash closing control wizard.
Allow the user to set cash in or out in the wizard.
closesodoo/odoo#45719
Task-id: 2125227
Related: odoo/enterprise#8562
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Before, when a session was open, we couldn't change any of the options in the pos config.
Now, we're able to change most of the options except those which would lead to incorrect behavior.
closesodoo/odoo#40500
Task-id: 2086823
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Since synchronization of tables was added in POS restaurant,
requests are frequently made to the server to display the
number of open orders on each table.
The implementation of the counting caused O(num_tables) queries,
and those queries were slow on large databases because there
was no index for the `table_id` column.
This patch fixes both problems, and the counting now uses
3 fast queries regardless of the number of tables.
On a sample database with 2k tables and 50k POS orders,
calls to `get_tables_order_count` went down
from 1 s and 100+ SQL queries to 10 ms and 4 queries.
About 2 orders of magnitude faster, with server load drastically
reduced as well.
closesodoo/odoo#44782
X-original-commit: 6c21ea369dc247b3ab31b767315c48ffc8d40a3d
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Payment information for terminal transactions (payment_status,
transaction_id & card_type) was lost when going back to the floor
plan in pos_restaurant. Validated transactions were then considered as
not processed yet.
closesodoo/odoo#43550
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Before this, when we printed a ticket for the kitchen, if we went back to the table management and go back to the order, we could re print the same product.
Now, we can only reprint the order if there is something different.
closesodoo/odoo#42208
Task-id: 2123029
X-original-commit: c8f604045eb0d476766641386c4e5e1605b915c3
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Before this fix translations of the order names missed a crusial space
that is needed to get information out of it in the front-end.
* Load Spanish-PE translation.
* Change localization preference for a user (either admin or demo) to
Spanish.
* Login to Odoo POS using the user with spanish localization.
* Go to POS, select BAR POS, select a table and place a draft order
with at least 1 order line (do not proceed to payment)
* Go back to table mgmt view and click again to the previous selected
table and the error appears.
This issue happens in any translation where pos_reference for a draft
order is not separated with white space as it happens in English. I mean
in english the pos_reference is something like "Order 00003-001-0002"
but in spanish it is "Pedido00003-001-0002" (no whitespace), so
https://github.com/odoo/odoo/blob/13.0/addons/pos_restaurant/models/pos_order.py#L143
assumes that there will always be a whitespace which is not true for
some odoo translations like spanish one.
This fix adds a variable to the translation string making it more clear
the space is part of the string. To make sure the code will also work on
languages with the words in another order `order['pos_reference'].split(' ')[1]`
is replaced by `search(r"\d{5}-\d{3}-\d{4}", order['pos_reference']).group(0)`,
we know the uid will always be formatted as nnnnn-nnn-nnnn
solves #40036closesodoo/odoo#40302
X-original-commit: c32126da5ac55a03637d82cf520b8655be8546e6
Signed-off-by: Gert Pellin - GPE <switch87@users.noreply.github.com>
When you try to delete a floor, an error is raised if a pos config has
an opened session. Even if the floor is not used in the opened pos
config.
The real goal of this constraint is to avoid deleting a floor plan
linked to a pos config having an opened session.
Github issue: https://github.com/odoo/odoo/issues/38581closesodoo/odoo#38719
X-original-commit: 9ec5a4c0126db767e17fc352fa184e0ee2bcc7e7
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
WHen you are creating a draft order, the sequence is not saved on the
server, and when we load the orders from the server the session id is
not correct too.
This leads to having inconsistant sequence numbers in the POS, almost
when we are synchronizing orders through the pos restaurant.
We now show the orders sequence number prefixed by login number when the
order is synchronized and don't have the same login number as current.
TASK-ID: 2057436
closesodoo/odoo#36032
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
You don't only tip in restaurants. In e.g. the US you can tip at a
barber shop.
It's not a big change since all the fields were already in
point_of_sale anyway.
Add possibility to print orders on an ePOS compatible Epson receipt
printer located in the same local network than the browser running the
pos.
TaskID: 2033442
PURPOSE
=========
When working in restaurants, there are often more than one waiter working on the same floor.
But Odoo doesn't support that.
There can only be one person working on one session for the same tables.
The purpose of this task to allow several people to work on the same session (while synchronizing sessions).
SPECIFICATIONS
===============
- MultiUser is active by default.
- Allow multiple waiters to login on one PoS Config.
- All waiters login to the same session, the waiter that does the paiment is the responsible for the order (same as now).
- Synchonize the information across the multiple instances running on same floors.
Syncronisation will take place at switch of table.
(close tables automaticly if no activity, to force sync)
- Syncro cannot be done if no internet : how do we manage it ? We should inform the user the internet connection has been lost and that synchro cannot be done. What impacts? To check
Useful links
https://github.com/it-projects-llc/pos-addonshttps://apps.odoo.com/apps/modules/11.0/pos_bus_restaurant/
Related PR:
odoo#32789
TASK-ID: 1891130
closesodoo/odoo#33973
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The deletion of some records can create inconsistencies in the
point_of_sale.
It can create inconsistencies when a session is open, for example if you
delete a partner that can be set on a pos order. You'll also got
problems if you remove an employee and this employee can be used in an
open session.
We also avoid to get point_of_sale config inconsistencies, by deleting
models required by it. If you delete a picking type used in a pos
config or a sequence.
To avoid all this consistencies, we have restricted the deletion of some
records in specific cases.
TASK-ID: 1879971
closesodoo/odoo#35793
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The note and mp_skip field of pos.order.line only exist in the frontend
application, this causes errors in some task of the PoS and IoT teams.
This pr adds the fields to the database, resolving these problems.
closesodoo/odoo#34210
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Check that it makes custom binary fields into attachment as that's the
main reason for the change: when users create binary fields via Studio,
they're necessarily db-stored (as the interface doesn't allow altering
the attachment attribute and it's unclear how we'd handle users
switching it on/off every time), which significantly bloats their
database (and burns storage & backup space), especially as the primary
use case for binary fields is adding images and documents to records.
* check that binary fields are properly created as attachment=True
* add attachment=False on fields where that seems relevant (most but not
all of the fields previously using the default)
* remove occurrences of attachment=True
closesodoo/odoo#29308
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
niyasraphy