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>
This is a followup to the fix made in
99615ff6cc.
When calling JSON.stringify to undefined, it results to undefined, thus,
it is necessary to check if the value is undefined before JSON.parse'ing
it.
closesodoo/odoo#42812
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>
Without demo data, for the odoo-master transifex project
closesodoo/odoo#41935
X-original-commit: dab7670b73506fb3a835695ee3bd735e0c5e5c2b
Related: odoo/enterprise#7287
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Followup of a425695e
The terms were back in 12.0
Courtesy of Juan José Scarafía
closesodoo/odoo#41624
X-original-commit: 85d0c7001a997748d7691205bbb8d066597591a5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
There is no unique constraint on the properties to avoid having two
properties for the same field, company and res_id.
Having two properties for the same field, company and res_id, leads to
inconsistencies through the code, as reading a company-dependent field
nondeterministically returns one of the available property value.
So now, before creating a property, we have to check that there is not
already a value for the field, company and res_id and write or create
depending on if it is already exists.
The properties of specific records already satisfy the constraint thanks
to the implementation of company-dependent fields that use the method
`set_multi`. We added a method `set_default` to set generic properties,
and its implementation does the right thing. It also simplifies the
code to set such properties, by the way.
closesodoo/odoo#40473
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.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>
* In a pos-session with table management create a new order with products
and go back to the floor-plan.
* The order is sinced to the back-end.
* Open the table again, remove all products but keep the order.
* Go back to floorplan to trigger syncing again.
* Open the table again.
behaviour before fix:
* The empty order is not loaded in the frontend anymore.
* To close the session the order has to be manually removed in the backend.
After fix:
* The order is still visible in the frontend and can be removed or finalysed as expected.
closesodoo/odoo#40165
X-original-commit: 3add8dd226f39d5166873a575b858694eeb2e6ee
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.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 a table is created, the new table appears to be selected but the
capability to resize and drag is not active. As a result, when this new
table is dragged, it is unselected instead. This is because of the call
of `save_changes`. The table widget is rendered but the event handlers
for resizing and dragging are not assigned. After this commit, the
created table can be resized and dragged immediately after creation.
closesodoo/odoo#38068
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Until now, the ticket printed from the web or to the printer were
different because one was using the OrderReceipt template and removed
some fields, and the other was using the BillReceipt.
We are now using only the bill receipt, to avoid to maintain multiple
template showing the same thing.
TASK-ID: 47990
Before this fix product lines did not merge on adding a same product
after transfering an order or re-opening an order that was synced.
To verefy if lines can be merged an unused field 'type' was compared.
Removing this field fixes the problem.
Before this fix, if an empty order gets transfered to another table, the
screen gets stuck on the floorplan until the window is refreshed.
With this fix the new table is opened.
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>
When you are in a pos session, and have installed pos_restaurant, you
get the number of guest ('1') printed on the ticket even if you are not
in a session of type restaurant.
So we are now checking that you have a table (which mean you are in a
pos session of type restaurant) to show the guest number.
TASK-ID: 2057436
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.
When we are running the tests on runbot, we get race condition when we
verify if the syncronisation is beeing sent, so we removed all of this
as it doesn't really verify if it synched or not, and we make a search
in python after tour execution.
closesodoo/odoo#36010
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When you are trying to resize and/or move a table in editing mode on the
floor plan, it doesn't work anymore, because the polling that will count
the orders by table will re-render the table after it has been selected
so the classes making it dragable are ot there anymore and you cannot
move or resize it.
Tu ix this behavior, we are not calling table order count when we are in
editing mode.
TASK-ID: 2057368
When you were trying to edit the table map of your pos, you were getting
a traceback because, it was getting information from a table that
is not in the list of table.
So we are now correctly set the table in the list when it is created and
duplicated.
TASK-ID: 2057368
When we open a table, the option verify sync is called, and doesn't
always work because of a race condition when we chack the status of
connecting, and the icon that has already changed.
As it doesn't really check anything because we check in python that the
orders are synchronised, we removed it.
closesodoo/odoo#35949
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
In the tour of pos restaurant, we are closing the pos that will redirect
to /web, and we won't wait this redirection. That will lead to a
remaining request taking too much time.
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
Add possibility to print receipts 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>
To use a kitchen printer, the user can only enter the IP of the Box and
it would be transformed into an URL with the protocol and port number.
This only supported HTTP so people that used HTTPS needed to enter the
full url to their Box.
Antoine Prieels