- 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>
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>
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 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>
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 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>
Anh Thao Pham (pta)