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>
The `_computeUnclaimedFreeProductQty` method was not properly computing
reward quantities for order type rules. This commit fixes the
computation to handle order type rules separately, allowing free
product rewards to be granted as expected.
The computation now also takes into account which rules were actually
used when calculating points. It will ignore any rules that were not
used in the points calculation when determining free product rewards.
This ensures the rewards match the rules that contributed to points
for the order.
opw-3492083
closesodoo/odoo#135972
X-original-commit: ff22b2cce65d324dc73295bc85a2469d42e3b82f
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
At the moment, the pos displays the selected order in multiple
screens, such as the `ProductScreen`, the `TicketScreen`, the
`SplitBillScreen`, the `self_order` app, but uses completely
different implementations for each. This means that when
a change needs to be made to the one, it generally needs to be made
to the other as well, which is error-prone.
In this commit we create generic `OrderWidget` and `Orderline` components,
that have not dependencies on POS objects and we refactor the `ProductScreen`,
the `TicketScreen` and the `SplitBillScreen` to use these components.
The `OrderSummary` component was removed and it's contents are now in the
`OrderWidget`.
We also introduce a very simple new component called `CenteredIcon` that
can be used whenever we want to show an icon that fills a whole div. In this
commit we use it for showing the cart icon when the order is empty.
In a future commit, the `pos_self_order` will be refactored in order
to use the same `OrderWidget` and `Orderline` compoenents as the POS.
Task: 3470365
In addition, this commit solves the issue from the task 3491303.
closesodoo/odoo#132248
Related: odoo/enterprise#45972
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Current behavior:
When a loyalty reward was applied with a promotion program, a promotion
reward was added with a -Infinity value.
Steps to reproduce:
- Create a loyalty program with a reward of 5€ fixed amount for 50
points
- Create a promotion program with a reward of 10% discount
- Open a pos session, select a customer (and add points to the loyalty
program if needed).
- Add a product to the order, the 10% discount should be applied
- Now click on the reward button to apply the loyalty reward
- The loyalty reward is correctly applied, but a new promotion reward
is added with a -Infinity value.
opw-3297817
closesodoo/odoo#133550
X-original-commit: ee60da301209c84264d706b9d16e45af541a3bbf
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@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>
This commit fixes the ui of the pos. When a popup was open in pos, elements
were rendered at the same level as the popup.
closesodoo/odoo#135124
Signed-off-by: Joseph Caburnay (jcb) <jcb@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>
At the moment, the point_of_sale module has 3 different implementations of
numpads. This is absurd. In this PR we unify them all into a single
numpad component.
One of the reasons why there are multiple numpads is because each requires
a slightly different set of buttons. The new `Numpad` component provides
a simple API which allows the consumer to specify what the buttons should be.
This is done by proving the `buttons` prop, which has the following type:
```js
buttons: {
type: Array,
element: {
type: Object,
shape: {
value: String,
text: { type: String, optional: true },
class: { type: String, optional: true },
disabled: { type: Boolean, optional: true },
},
},
}
```
In this PR we also provide a simple set of helper functions for the tours
and adapt all of the existing tests accordingly.
closesodoo/odoo#132245
Task: 3470346
Related: odoo/enterprise#46427
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit, formatters like `formatMonetary` and `formatFloat`
weren't loaded in the assets front-end.
This commit introduces `formatAmount` ( `formatMonetary` calls
`formatAmount` but makes some prior processing to deduce the currency
from the field) and makes `formatAmount` and `formatFloat` accessible
from any front-end application.
Note: The currencies were added in the front-end session info because
they are needed in `formatAmount`.
closesodoo/odoo#133824
Related: odoo/enterprise#46658
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Before this commit:
===================
In the back-end, there is only one field "date_order" is used, while on the
frontend side, there are two separate fields: "creation_date" and
"validation_date," which causes confusion in the code flow and leads to
redundancies.
After this commit:
==================
Revised the order date flow by eliminating the confusion stemming from the
separate "creation_date" and "validation_date" fields. Both have been
consolidated into the "date_order" field, offering clarity to the order date
process.
task - 3482072
closesodoo/odoo#133293
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Currently when the pos.config is set to "Skip Preview", when printing a
receipt, the receipt or bill screen shows very quickly and disappears.
This is not good UX.
Now, the receipt is printed from the payment screen itself. We don't
need to show the receipt screen at all.
closesodoo/odoo#132550
Taskid: 3441238
Related: odoo/enterprise#46187
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
*: pos_discount,pos_loyalty,pos_restaurant,pos_self_order
In a previous commit (669b9fcc2f) we added the
backend logic needed for creating combos in `pos`.
In this PR we add the combo functionality to the classic pos ui.
This means that products can now be grouped together and sold as a combo.
ex: Create a product called `Burger Menu` with type='combo'.This product will
have multiple combos associated with it, for ex:
- Drinks - will contain the list of drinks from which the customer can choose
- Main Course - will contain the list of main courses from which the customer
can choose
- Dessert - will contain the list of desserts from which the customer can choose
In the event that one of the products inside one of the combos is to be more
expensive, this product will have a specific `combo_price` which will be added
to the main combo product's price.
We add the relational fields `combo_parent_id` and `combo_line_ids` in the
`pos.order.line` model. In the previous example, `combo_parent_id` will contain
the `id` of the `orderline` of the `Burger Menu` product.
In many cases `combo lines` have to be handled together. For example, deletion
of an orderline containing a product from a combo implies the deletion of all
other orderlines containing products from that combo. This means that multiple
methods from the codebase had to be changed for this reason. Places that needed
changes for this reason:
- `split_bill_screen.js`
- `addProductToCurrentOrder()`
- `remove_orderline()` and `add_orderline()` from the `Order` js model
In this PR we also:
- improve the demo data such that it contains a `pos combo`;
- refactor the `ProductItem` component such that it relies on a stateless
component. This stateless component can now be used anywhere; ( it is now used
in the popup which allows selecting the desired combo products )
- add a new method called `is_pos_groupable` on the `Orderline` js model. Before
we relied on the product unit to see whether or not a product is groupable. We
now needed a new mechanism, which could account for different reasons for
which products are not groupable, such as belonging in a combo;
Note on price calculation:
- The idea is simple, imagine a rectangle divided into two parts. The whole
rectangle is the total order, whereas the two partitions are the orderlines.
- Now, imagine shrinking the rectangle by a certain factor. This shrinked
rectangle represents an order containing a combo -- because normally, a
combo results to smaller price. The two partitions are also shrinked by the
same factor.
- So the calculation will be:
- Nominal total price is calculated. This is the sum of the orderlines'
prices when they are added individually. This represents the whole
rectangle.
- Target price is derived from the combo product's price and selected
components' combo prices. This represents the shrinked rectangle.
- Reduction factor is computed as the ratio between the target price and the
nominal price.
- Each component's unit price is adjusted by multiplying the reduction
factor.
- When the unit prices of the components are computed, we now let the normal
price computation take place.
- A spreadsheet is prepared to show a sample calculation:
https://docs.google.com/spreadsheets/d/1iOdnaILnvKiaf2_z7jTijYiVfB_3mjKWjq6nOB70Un0/edit#gid=0closesodoo/odoo#129483
Task: 3430636
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Co-authored-by: Joseph Caburnay <jcb@odoo.com>
*:point_of_sale,pos_adyen,pos_online_payment_self_order,pos_restaurant,
pos_sale,pos_self_order,pos_self_order_adyen,pos_self_order_restaurant,
pos_self_order_sale
This PR adds the kiosk to the existing `pos_self_order` module, which
until now has enabled end-users to order their restaurant meals directly
from their smartphones.
We've added the possibility of creating kiosks / totems (devices with
large touch screens) that allow users to order their menu directly
without having to go through a waiter.
Once the order has been placed, the user will be invited to pay either
by adyen, already integrated into this PR, or at the counter.
At the end of the order, the user will receive an order number and his
table number if `service at table` is activated.
Main differences with the Self-order mobile:
- Kiosk shouldn't be accessible publicly
- Kiosk should support payments via card readers
closesodoo/odoo#129562
Design: XLU
Dev: ADGU & MODA
Taskid: 3323163
Related: odoo/upgrade#5024
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
For loyalty programs of type 'coupons' with no rules defined,
the points were not being calculated correctly in the PoS.
The pointsForPrograms function was returning an empty list [] when
no rules exist. This caused _getRealCouponPoints to skip calculation.
This commit checks the program type and returns the points
if it is 'coupons'.
opw-3457550
closesodoo/odoo#133445
X-original-commit: 25ff280dfbec7e6d6f1c0a345e1902a2ab5c0774
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
In our continued effort to remove legacy code, this commit replaces
the unique usage of the legacy MutexedDropPrevious util with the new
mutex util. The legacy MutexedDropPrevious has been removed.
Part-of task-id 3439226
closesodoo/odoo#132948
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
* point_of_sale, pos_loyalty, pos_restaurant
before this commit, syntax error exist in point_of_sale,
pos_loyalty and pos_restaurant modules.
* export translation of above modules
* check odoo log file
errors in the log:
* Opening and ending tag mismatch: input line
* XMLSyntaxError: Entity 'nbsp' not defined
* Opening and ending tag mismatch: button line
* Specification mandates value for attribute disabled
after this commit, no error's wont be shown in
the log
closesodoo/odoo#132132
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Current behavior:
When using a gift card in the PoS, you would get 2 gift card reward
lines, one positive and one negative. Wich should not be the case.
This happens because the gift card reward had taxes.
To fix this we need to remove the taxes from the gift card reward,
as it is done in the sale_loyalty module ´_get_reward_values_discount´
https://github.com/odoo/odoo/blob/30062210cc879a1d2349b888a510f29ea40d5920/addons/sale_loyalty/models/sale_order.py#L313
Steps to reproduce:
- Install the pos_loyalty module
- Open PoS
- Buy a gift card and copy the code
- Buy a product and pay with the gift card
- You will see 2 gift card reward lines, one positive and one negative
opw-3472830
closesodoo/odoo#133034
X-original-commit: 7814bb2663ac75ef91922897b88022d87f58241f
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
*: pos_loyalty,pos_restaurant
The ticket screen contains a widget showing orderlines
and information about them for paid orders. This commit introduces
the use of this widget for open orders. On the ticket screen,
the cashier will be able to have information about the orderlines
for each order without necessarly loading the order in full screen.
The user now have to click on the order on the ticket screen and click
on the new button "Load order" to display it in the main screen.
closesodoo/odoo#128288
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
In this commit, all usages of env._t() are replaced by _t().
In templates files, env._t() didn't work because terms used
in attributes where not extracted into the translation files.
Only string are exported from .xml files to translation files.
So, to make it works, we set a variable that is then used
in attributes.
For example :
<t t-set="string_to_translate">String to translate</t>
<Dialog title="string_to_translate>...</Dialog>
task-3292454
closesodoo/odoo#131390
Related: odoo/enterprise#45631
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
The call to super was wrong, it was called in the old way this._super().
This has now been corrected with the new method
super().`function name`()
closesodoo/odoo#132022
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
As all the templates are now imported in the owl app, there is not need
anymore to specify the owl="1" attribute in the templates.
Part of task~3443861
Part-of: odoo/odoo#130467
Improve gettext to directly handle value injection within translations,
removing the need for sprintf.
closesodoo/odoo#123932
Related: odoo/enterprise#45370
Signed-off-by: Samuel Degueldre (sad) <sad@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>
Before this commit, if you update the quantity of a line that it's
`disallowLineQuantityChange` it will call `_showDecreaseQuantityPopup`
to update the quantity and it will call the `set_quantity` to modify
the quantity. Calling 'set_quantity' won't call the `_updateRewards`
and it causes us to not update the rewards.
Steps to reproduce:
- In a French company, install the module "France - VAT Anti-Fraud
Certification for Point of Sale"
- Create a Loyalty program that gives you 1 point for each euro spent.
- Add items to the cart, and the points sum up.
- Remove items from the cart, the points don't subtract.
+ If points reward is added to the cart and then removed, the points
are still considered as used.
The solution is to override the `_showDecreaseQuantityPopup` function
in the pos_loyalty to call the `_updateRewards`.
opw-3430349
closesodoo/odoo#130794
X-original-commit: 1bbeaefe0f750fceba19cc9199cd7a0681fd1f7a
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
In the commit [1], the patch has been refactored to support the
native keyword `super`. The current commit just adapts the codebase
to that change.
task 3410198
[1]: 19ea1ac08043e22a811630968e44715cc3bfc495
Part-of: odoo/odoo#125716
pos*: point_of_sale,pos_hr,pos_loyalty,pos_restaurant,
pos_sale,
In this commit we refactor some parts of the pos ui with the interest
of providing a simpler and cleaner codebase.
One pattern that is heavily used in the pos ui is that in which
views are changed based on the screen size at the component level.
This means that it becomes very difficult to understand what parts
of a specific template will be seen in mobile or in desktop views.
In most cases, the pos adapts for mobile screens by using the same
main components, but in different configurations. For example, a
component that was visible in desktop mode, might become accesible
through a menu in mobile mode.
In order to improve the situation, the proposed solution is to
separate the logical parts of the ui into `owl templates` and
to inject this templates wherever the need arises.
Thus, instead of constantly using `t-if="ui.isSmall"` in all places
where there is a difference between the mobile and desktop views,
we have a main conditional branch at the root level of the component
representing a certain screen and then build 2 separate views, one for
mobile and one for desktop, each calling the needed templates.
In this commit we implement this pattern for the `payment_screen`.
This will allow us to observe this pattern over a period of time,
before implementing it on the other screens.
In this commit we also:
- add small fixes and improvements relating to
the previous commit, in which the pos was
refactored to bootstrap;
- replace the `<br>` tags in the numpad component
with the bootstrap grid system;
- adapt the `cash_move_popup` to rely more on `t-model`
and less on `t-on-change`
Part-of: odoo/odoo#129544
Co-authored-by: vlst <vlst@odoo.com>
Co-authored-by: Xavier Luyckx (xlu) <xlu@odoo.com>
pos*: point_of_sale,pos_discount,pos_hr,pos_loyalty,
pos_restaurant,pos_sale,pos_sale_product_configurator,pos_six
Prior to this commit, the point_of_sale module relied on custom CSS.
To enhance user experience, increase flexibility, and simplify maintenance,
most of the custom css was replaced in this PR with Bootstrap utility classes.
Task: 3354582
Authored-by: Xavier Luyckx (xlu) <xlu@odoo.com>
Part-of: odoo/odoo#129544
Co-authored-by: vlst <vlst@odoo.com>, Pedram (pebr)
Current behavior:
When creating a loyalty program, with a rules that award points for each
dollar spent, the value of the point was inconsistent because it was
taking the rewards into account.
Steps to reproduce:
- Create a loyalty program with a rule that award 0.1 point for each
dollar spent, and a reward that gives 1$ per points.
- Create a product with a price of 265$.
- Open the PoS and create a new order for 1000$.
- Select a customer and pay the order.(The customer now have 100 points)
- Create a new order with the product created earlier, and apply the
reward.
- The value of the reward shoudl be 126.5$ (100 points + 26.5 points
from the current order) but it is not.
opw-3275585
closesodoo/odoo#129963
X-original-commit: 70256e5cf8359a09687acc3e2d4f8792ef4f9801
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Current behavior:
When scanning a product that should trigger a reward, the reward was not
applied.
Steps to reproduce:
- Create a reward that applies a 10% discount on specific products
(e.g. Whiteboard pen)
- Make sure a barcode is set on the Whiteboard pen product
- Open a PoS, and scan the Whiteboard pen product barcode
- The reward is not applied
opw-3373435
closesodoo/odoo#129406
X-original-commit: 9991d923ec0e7fc74e5d319d43a0052e6e4d7416
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
pos*: l10n_ae_pos,l10n_co_pos,l10n_fr_pos_cert,l10n_gcc_pos,
l10n_in_pos,l10n_sa_pos,pos_adyen,pos_discount,
pos_epson_printer,pos_hr,pos_hr_restaurant,pos_loyalty,
pos_mercury,pos_restaurant,pos_restaurant_adyen,pos_restaurant_stripe,
pos_sale,pos_sale_loyalty,pos_sale_product_configurator,pos_six,
pos_stripe
In the previous commit, we moved and renamed files such that they
better follow certain guidelines.
In this commit, we adapt imports accordingly.
In order to efficiently accomplish this task, i used the following [script](https://github.com/vlst-odoo/tools/blob/main/fixImports.py)
Task: 3394192
Part-of: odoo/odoo#127056
pos*: l10n_ae_pos,l10n_co_pos,l10n_gcc_pos,l10n_in_pos,
l10n_sa_pos,pos_adyen,pos_discount,pos_epson_printer,
pos_hr,pos_hr_restaurant,pos_loyalty,pos_mercury,
pos_restaurant,pos_restaurant_adyen,pos_restaurant_stripe,pos_sale,
pos_sale_loyalty,pos_sale_product_configurator,pos_six,pos_stripe,
The POS has a large number of add-on modules. As such, it is
important that they all respect strict guidelines when it comes
to file structures.
Before, each module had more or less it's own rules when it came to
this, apart from the fact that code was mostly organised into
`js` and `xml` folders.
In this PR, we move to a much more structured approach,
in which each module follows the following pattern:
src/
|-- app/ <-- the module's own new logic
|-- overrides/
| |-- components
| | |-- overridden_component_a
| | | |-- overridden_component_a.js
| | | |-- overridden_component_a.xml
| | | |-- overridden_component_a.css
| |-- models
| | |-- overridden_model.js
Apart from the structural changes, this PR introduces changes
to file names, such that they respect the default pattern of
snake_case naming.
In this commit, we move the files. In the following one we
make the needed changes in the code, such as adapting imports.
In order to efficiently accomplish this task, i used the following [script](https://github.com/vlst-odoo/tools/blob/main/rename.py)
Task: 3394192
Part-of: odoo/odoo#127056
The goal of this commit is to prepare ground to remove
lazytranslate function _lt() and keep only _t()
for a better understanding of the use of the translation function.
In this commit,
the translate function _t() has been updated to return the translation
if they are loaded. If not, it throws an error.
the lazytranslate function _lt() returns _t() function.
Corollaries :
Steps in test tours are now a function that returns an array of steps
to avoid any interpolation of _t in this ones before translations has
been loaded.
Example :
registry.category("web_tour.tours").add("example", {
test: true,
steps: () => [
{...},
{...},
],
});
task-3292454
closesodoo/odoo#124157
Related: odoo/enterprise#43153
Signed-off-by: Samuel Degueldre (sad) <sad@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>
Before this commit, if you have a discount promotion on the order,
adding a free product reward would change the discount incorrectly.
The problem is that in the `_getDiscountableOnSpecific` function the
non-discount rewards weren't excluded from `discountLinesPerReward`.
opw-3276337
closesodoo/odoo#127003
X-original-commit: 914dad0d23df4c3f8a117252a8159c07df9ee8ad
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
pos*: pos_loyalty, pos_restaurant, pos_sale,
pos_adyen, pos_six, pos_stripe
At the moment, the `pos` models don't have access to the `env` variable.
This makes using `env` inside a model rather awkward.
This PR makes it so all the pos models have access directly to `env`.
closesodoo/odoo#124320
Task: 3358456
Related: odoo/enterprise#42209
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
In order to add the l10n_cl_edi_pos module we had to adapt some
things in the PoS module. This task changed the error handling of errors
sent to the server from the payment_screen. This led to some changes in
payment_screen.js and partner_editor.xml. It also add the mechanism
of not allowing an single order to combine refund and normal sale
in some localization if needed (needed for Chili).
closesodoo/odoo#121151
Related: odoo/enterprise#40940
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
Current behavior:
When computing the discountable values of an order, the discount of the
program where not taken into account if you used specific discountable
products.
Steps to reproduce:
- Create products A and B with a price of 20$
- Create a loyalty program
- Rule:
- Minimum qty : 2
- Apply on specific products : Product A and Product B
- Reward : 5 points per order
- Reward:
- 10$ per order
- In exchange of 2 points
- Apply on specific products : Product A and Product B
- Open PoS and add Product A and Product B to the order
- A reward should be added automatically with a value of -10$
- Click on the reward button, another reward should be added but it has
the wrong value. It should be -10$ but it is not.
opw-3232565
closesodoo/odoo#126245
X-original-commit: f33d3b09ff49aae1fdaf3379915b7e7b5f03080c
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Before this commit, purchasing a gift card along with applying a free
product promotion in the same order resulted in the gift card balance
being decreased by the free product price.
Steps to reproduce:
1. Create a buy x get y promo program.
2. Open the POS and use this program and sell a gift card in the same transaction.
3. Activate the promo program and complete the transaction.
The promo program discount will take money of the gift card amount.
Also there is another issue with Loyalty Cards points:
When the reward's product in not valid of the rule, it will decrease
the point when you add the reward.
opw-3284636
closesodoo/odoo#126014
X-original-commit: 975ffef9d1fa7a41b223859e5355e05bdba1d11c
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@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>
*: l10n_ae_pos, l10n_co_pos, l10n_fr_pos_cert, l10n_gcc_pos, l10n_in_pos, point_of_sale,
pos_adyen, pos_discount, pos_epson_printer, pos_hr, pos_loyalty, pos_mercury,
pos_restaurant, pos_sale, pos_sale_product_configurator, pos_six, pos_stripe
After the architectural refactor of the PoS App, there are two classes that make sense to merge.
In this refactoring task, we're merging them.
closesodoo/odoo#124477
Task: 3358550
Related: odoo/enterprise#42257
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
*: l10n_fr_pos_cert, pos_discount, pos_loyalty, pos_sale, pos_self_order
The `Orderline` model contains the fields: `price_manually_set` and `price_automatically_set`.
They are meant to signify what type of price the orderline has: `automatic`, `manual` or `original`.
It's very confusing to manage the two fields when in fact they only describe three types of setting the orderline price.
This PR replaces the 2 fields with a single one: `price_type`, which will take one of the 3 possible values.
closesodoo/odoo#124858
Task: 3358265
Signed-off-by: Heinz Robin (rhe) <rhe@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>
pos*: l10n_ae_pos, l10n_co_pos, l10n_fr_pos_cert, l10n_in_pos,
point_of_sale, pos_discount, pos_epson_printer, pos_hr, pos_loyalty,
pos_mercury, pos_restaurant, pos_sale, pos_sale_product_configurator,
pos_six
Previously, none of the templates of the pos were namespaced, this means
that depending on context, you have to access them differently: in xpath
the module prefix is necessary even if the template name itself isn't
namespace, but in owl components you cannot use the namespaced version
because owl doesn't have the notion of modules.
This commit namespaces the component templates of all the pos modules so
that it's consistent with the rest of the code base. It also removes
some extraneous calls to super.setup() that were leftover and are not
necessary for components extending directly owl's base Component.
closesodoo/odoo#124069
Related: odoo/enterprise#42094
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The process of emailing _gift cards_ bought from the Point of Sale is rather confusing.
This PR makes the experience more intuitive.
closesodoo/odoo#123222
Task: 2711714
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
pos*: l10n_co_pos, l10n_fr_pos_cert, l10n_gcc_pos, l10n_in_pos,
l10n_sa_pos, pos_adyen, pos_discount, pos_epson_printer, pos_hr,
pos_hr_restaurant, pos_loyalty, pos_mercury, pos_restaurant, pos_sale,
pos_sale_loyalty, pos_sale_product_configurator, pos_six, pos_stripe
The previous commit reorganizes the files in the pos, this commit
renames all of the imports of those files to match their new location.
This is done in a separate commit to allow git to better keep track of
the changes and apply forward-ports more seamlessly.
Part-of: odoo/odoo#123498
The issue occurred when a loyalty program's rule was set to be
based on money spent, and the reward was a free product with a
sale price of zero. This caused a zero division error in the code,
resulting in the remaining points becoming NaN after the reward
was obtained in the point of sale.
opw-3253366
closesodoo/odoo#123123
X-original-commit: 1eaca074741157e42c12da22e945a1817e7ceec3
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
This fix is a followup to the changes made in 5d951d9
where `format_currency` is replaced with `formatCurrency` which is based
on a more standard way offormatting monetary values.
closesodoo/odoo#122420
X-original-commit: b56a5d1
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Pedram (PEBR)