When the limited product loading option is enabled in the PoS config,
the Top-up eWallet product was not loaded into the PoS. This caused
an error when trying to process an eWallet refund from the PoS since
the Top-up product was missing.
This commit ensures that the Top-up eWallet product is always loaded
into the PoS regardless of the limited product loading setting.
opw-3510639
closesodoo/odoo#136865
X-original-commit: 8eafd156f4a4a8680709feef8b38cbead39957f6
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Before this commit, if a product was set to be available in the PoS,
and also existed in a reward, it was loaded to the PoS twice. This
caused issues in _loadProductProduct during the assigning of pricelist
items, and could result in missing pricelist information for a product.
opw-3487702
closesodoo/odoo#135494
X-original-commit: b64f9bfeb7782e9665ea60e57f09031b6588f883
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Before this commit, if you added a domain to a loyalty reward with
one of many2one fields like [("categ_id", "ilike", "test")], it wasn't
possible to open the PoS.
This commit addresses this limitation by replacing the many2one fields
with their corresponding value. To do this the product's field type is
loaded to ensure that this improvement applies exclusively to many2one
fields.
However, it's important to note that this improvement currently handles
only "one-level" of related many2one fields. Any domain that appears
like ("categ_id.foo", "ilike", "foo-val") won't function as expected.
opw-3473103
closesodoo/odoo#134811
X-original-commit: d0a6ab8d1f89f0dd2aa6641c63b6973ae7c753ad
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
*:pos_hr,pos_hr_restaurant,pos_loyalty,pos_restaurant
Before when serializing a pos.order from the server, we are using
several methods for different use cases.
- table syncing: get_table_draft_orders
- order sharing: get_draft_share_order_ids
- ticket screen: export_for_ui
All of these methods had their own logic.
Now, to improve the maintainability of point_of_sale, order
serialization is only performed via export_for_ui.
Enterprise PR: https://github.com/odoo/enterprise/pull/45151closesodoo/odoo#130695
Taskid: 3449870
Related: odoo/enterprise#45151
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
When specified, restrict the promotion to customers using said pricelists
task-3049956
closesodoo/odoo#107656
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Lucas Vermulen (luve) <luve@odoo.com>
Co-authored-by: Morgane Demesmaeker (edm) <edm@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>
currently it is only possible to define the end_date that
does not allow to prepare the program in advance.
Added the start_date property to the program model.
task-3305712
closesodoo/odoo#121193
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Previously, when a reward was applied on a product, the product was
checked against the reward_product_ids field, which is a computed m2m
field that contains all the IDS of the products on which this reward is
available. In many cases, rewards are available on all products, causing
the computation of the m2m to fill it with the ids of all products.
This caused performance issues on all DBs with lots of products (~200k)
in all flows involving rewards.
We can't remove reward_product_ids from the data loaded in the frontend
in stable because existing JS customisations might crash if they depend
on its presence. As such, to keep compatibility with existing databases,
an ir.config_parameter has been introduced to opt into the new
behaviour. This parameter is set when creating a database so that new
databases don't suffer from this performance penalty.
For existing databases, the parameter can be set by hand if the old
behaviour is not necessary and the performance penalty is an issue in
practice, but is unset by default.
When opting into the new behaviour, the reward_product_ids field now
always evaluates to an empty recordset, and the desired behaviour should
be achieved by evaluating records against the reward_product_domain
instead. In the point_of_sale, the products available on rewards are
calculated by evaluating each product against the reward when it is
loaded. In the loyalty modules, instead of using the in operator on the
reward_product_ids field, we instead evaluate the reward product domain
against the product, which is much faster. This is always done even when
not opting into the new behaviour as the change in implementation cannot
be observed outside of timing.
closesodoo/odoo#120074
X-original-commit: 6f72d053a31aca520cbfbba2d1257568b7f7c0cb
Related: odoo/enterprise#40503
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
After this commit, we will be using float_compare function to compare
points. This will ensure that any floating point errors are properly
handled and that we receive correct responses from the
`validate_coupon_programs` function.
opw-3264681
closesodoo/odoo#118829
X-original-commit: 48013733a6e8b655cbc81211b1010e76102b9c2a
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Before this commit, when loading the pos with pos_loyalty, even if limited product was activated, all the products were loaded to make sure that we could apply rewards.
Now, we don't load all the products but we only load the rewards by default.
closesodoo/odoo#114021
X-original-commit: 60e7cdee62cf6b19ce0b26f2c7cbe708f74a806e
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
This commit is a forward port from v16. It completes another commit that was
done in master only:
https://github.com/odoo/odoo/commit/7c415e972fa97ba52d8d5165fd47494965e3053d
---
Module `pos_restaurant` synchronizes orders between different POS devices. It
works by pushing order from POS to server and loading it back. This commit
assures that loyalty fields are correctly prepared before returning values to js
client. Specifically, many2one fields must be just ids [1] [2], and not `[id,
name]`. Similar cleaning is already done in `pos_restaurant` module for `product_id`
field [2].
To correctly implement this patch, empty `_prepare_order_line` is added to
`point_of_sale` module to be sure that extension of that method in `pos_loyalty`
is not ignored: the method in `pos_restaurant` didn't have `super` call and
`pos_loyalty` module doesn't depend on `pos_restaurant`
STEPS:
* install pos_restaurant, pos_loyalty
* prepare gift card
* open pos, create order, apply gift card
* switch to floor screen and then back to table (order) screen
[1]:
https://github.com/odoo/odoo/blob/c4b90db77705139333bdf5faf26b12fc120d1661/addons/pos_loyalty/static/src/js/Loyalty.js#L833
[2]: https://github.com/odoo/odoo/blob/c4b90db77705139333bdf5faf26b12fc120d1661/addons/pos_restaurant/models/pos_order.py#L76closesodoo/odoo#111617
X-original-commit: 0cf1fb6cf9dad69d58939d735081428a5e1650f4
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Previously, reward_id was an array of two elements containing
the ID and name of the reward. But in the frontend,
reward_id is supposed to be an int with the ID
Adaptation of the _prepare_order_line function in the following modules:
- point_of_sale
- pos_restaurant
- pos_loyalty
Now the data is correctly sent to the frontend and the error
is no longer present.
closesodoo/odoo#111048
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
`action_view_pos_orders` is unused and it is incorrect
because it generates a wrong domain (`('id', 'in', pos_order_ids)` where
`pos_order_ids` is a list of tuple(<id>, <display_name>))
Part-of: odoo/odoo#104838
- Gift cards can now be sent alongside the receipt via mail in the Receipt Screen.
- The gift card report no longer show n² gift cards
- Properly download all PDF files for the gift cards when there are multiple gift card programs
closesodoo/odoo#102910
X-original-commit: 5b269ebb3e725ff84c437e204874c14251ed1d78
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
It was possible to sell gift cards without mail template or report link to the gift card program.
Thus, it was impossible to get the info related to the card unless you have backend access rights.
We now make sure the gift card program have a template and a report when starting the session.
closesodoo/odoo#102885
X-original-commit: e81db2e6e1a3179f9cb6c8410111201d311a97ab
Signed-off-by: Masereel Pierre <pim@odoo.com>
- Make content helper more generic for programs
- Add search fields for loyalty.card
- Fix creation emails for gift cards in pos not being sent properly
- Fix validity date check on loyalty rules being inverted.
TaskId-3002190
closesodoo/odoo#102160
X-original-commit: f893fda1a40127b7510e861c96f4d4cf9d10f79d
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
* Allow multiple loyalty programs.
* Improve gift card workflow: https://app.excalidraw.com/l/65VNwvy7c4X/1Xt93llULvo
* Integration with the ewallet programs: https://app.excalidraw.com/l/65VNwvy7c4X/4B9AEOSbaku
Note that we prevent refunding eWallet and gift card top up and
reward products. If for instance the user wants to refund gift cards
they'll have to transfer the gift card to ewallet by topping up the
customer's ewallet and paying with the gift card to be refunded.
closesodoo/odoo#100891
Task-ids: 2959620, 2959661
X-original-commit: fa06e3225650ed9d1a96709b0398e7f33313acf5
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Need to show the pos_report_print_id option on gift card and ewallet
programs like the mail_template_id. It's important on printing
newly generated gift card and ewallet from pos.
closesodoo/odoo#99678
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
After this commit, the settings of coupons, promotions,
gift cards and loyalty cards are now managed under a
single one field in PoS Settings configuration. Moreover,
this settings field is "global" and shared between the
eCommerce and Sales app.
task-2959620
closesodoo/odoo#99060
Related: odoo/upgrade#3842
Signed-off-by: Masereel Pierre <pim@odoo.com>
This commit improves some messages and usability for loyalty and its
submodules:
- Coupons should not be restricted to the partner assigned to them
anymore
- Merged "I have a promo code" and "Use a gift card" into a single
toggle
- Boolean fields have been added to each app to disable them where we
don't want them.
- Reduced the size of coupon codes
This means that we increase the risk of collision which should be
handled by the model as well now.
Creating a coupon with an existing code will retry the creation (up
to 10 times) until the coupon is indeed created.
- Make it clearer in the coupon generation wizard that an email will be
sent to the customer.
- Reintroduce coupon/gift card details on sale order lines in eCommerce
which was wrongfully removed.
- Remove the "on product with taxes: " message on order lines when
the amount is not split between taxes or if the tax message would be
empty.
- Make it possible for some error messages to be displayed as warning
instead of errors
- Split program types in two menuitems, one for promotions discount
loyalty etc and one for gift cards and ewallet, the latter has
simplified views.
- Views overall have been reviewed to make it easier to understand how
to programs work. New program types have also been added.
TaskId-2951413
Part-of: odoo/odoo#99023
Co-authored-by: William Braeckman <wbr@odoo.com>
Small visual changes that should improve the user experience.
The loading demo data popup has been moved to the backend.
Created an Alert Popup that is less aggressive than an Error Popup
closesodoo/odoo#83780
Task-id: 2485062
Related: odoo/enterprise#26104
Signed-off-by: Masereel Pierre <pim@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>
Before this commit, the loyalty_points field, neccessary to
implement the loyalty functionality in PoS in offline mode,
was only loaded properly for the partners at the start of
a PoS session.
After this commit, the loyalty_points are loaded properly for
every partner throughout the duration of the session, including
those that are loaded in the background or fetched when using
the search bar, which was not the case before.
Part-of: odoo/odoo#84719
Before this commit, if the config setting
limited_products_loading was activated,
some reward products might not get loaded
in the frontend. So the UI crashed whenever a
reward product was accessed.
In this commit we force-load all the reward products
at the start of session, regardless of the number of
loaded products (loading_products_amount)
Part-of: odoo/odoo#84719
When limited_products_amout is 0, query is an
empty list. In this case, we do not need to
modify the result further, so we return it
as is.
Part-of: odoo/odoo#84719
Pedram (PEBR)