If applied, this commit will fix the following bug by using the price
with the additional cost added instead of only the price
Steps to reproduce:
1- install sales
2- create a product p with variant pv
3- set an extra value for pv
4- go to Products>Product Variants
5- open the pv in form view
6- the Sales Price is the price of p not pv
(which should be p + extra value)
7- also the tax string is calculated on p not pv
Bug:
```list_price``` is being used
Fix:
replace ```list_price``` with ```lst_price```
OPW-2774199
closesodoo/odoo#88270
X-original-commit: 46526f629f7645eaac8ce86e81e806cfa392b8b8
Signed-off-by: William André (wan) <wan@odoo.com>
Issue:
Imagine today is the April 7th 2022 and we set the inventory frequency to 90 days. If our last inventory date was on January 12th 2022, the next inventory date should be set to April 12th 2022. However, it is being set to January 27th 2022 which is wrong.
The next inventory date should be last inventory date + cyclic inventory frequency.
OPW-2795459
closesodoo/odoo#88267
X-original-commit: 990758ebbed294c8f25d90a5e4f6a7455be97a31
Signed-off-by: Arnold Moyaux <arm@odoo.com>
When creating a backorder for a manufacturing order, procure method for
its moves are lost in the process, as the the field is set to copy
False. But the split of a manufacturing order is not a usual copy case.
In this specific case, we need to keep the procure_method of the copied
moves, as it keeps the two/three-steps routes working for the splitted
manufacturing order.
Task-2797359
closesodoo/odoo#88208
Signed-off-by: Arnold Moyaux <arm@odoo.com>
This module replaces both website_sale_coupon and
website_sale_gift_card.
Connects sale_loyalty with website_sale to allow for promotion programs
in eCommerce.
TaskId-2675382
In a subcontracting flow, the extra_cost on the subcontracted production
is read on the purchase line (via _get_price_unit() ) at the production
creation. In case the price unit on this purchase line change before the
validation, the stock valuation layer linked to the production will not
take this new value into account.
This commit ensures the price unit is the right one at validation
Note: the first version of the current fix broke a use case. The test
`test_tracked_compo_and_backorder` has been added to protect that use
case.
closesodoo/odoo#87817
X-original-commit: 1ff1b4a9a2b9ab27b29fdcac93731fa053c77cc7
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Co-authored-by: William Henrotin (whe) <whe@odoo.com>
Co-authored-by: Adrien Widart <awt@odoo.com>
To reproduce:
1. Create a grouped tax with multiple taxes. Reorder the tax
items. (Important step.)
2. Assign tax to the product.
3. Open pos loading the product.
4. a. [BUG] If pos config is tax-included -> non-responsive ui.
4. b. [BUG] If pos config is tax-excluded:
Add the product. -> non-responsive ui.
Fix:
With the new reactivity in owl, mutating reactive objects will
trigger rerender. However, computing tax amount of orderline
or product with grouped taxes result to mutation of a reactive
object, triggering an infinite render (render -> compute with
mutation -> will trigger another render -> ...).
The call to sort is mutating the reactive array referred by
`children_tax_ids`. To prevent this infinite render, the solution
is to use a copy of the array when sorting the taxes.
OPW-2816546
closesodoo/odoo#88245
X-original-commit: b273056a12a34fec75d980e8a4a08ebaedad7e9c
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Inline styles applied by the editor should always have priority over the
general stylesheet. This failed in the case of nested styles (a <font>
with a color within a <span> with a font size for instance).
closesodoo/odoo#88004
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
To give a custom style to a template, we need to add a style element at
its top, with the id "design-element", and apply to it the supported
styles. These supported styles and their selectors can be seen in the
`DEFAULT_CSS_OBJECT` constant in `mass_mailing_snippets.js`.
However, comma-separated selectors were not supported, meaning styles
could only be incomplete.
task-2816655
Part-of: odoo/odoo#88004
This module is an unification of `coupon`, `gift_card` and an extraction
of the program models of `pos_loyalty`.
The goal of this module is to unify the creation of coupon, promotion,
gift_card, loyalty programs etc.. into a single base module and share
the same models.
Managers will be able to create programs based on rules and rewards.
Programs may apply on the current order (rules and rewards)
or on future orders, where the rules must match the first order to get a
reward on the second order
or even be nominative and accumulate points over multiple orders.
Every program is based on a point system. And each use of the program
will result in the creation of a coupon (except for nominative programs
which should be limited to one card per customer).
A rule may filter on quantity, money spent and products and give points
on the order, the amount of units paid or the amount of money spent.
A reward could be a free product, a discount or (with an additional
module) free shipping.
Discounts can be percentage based, fixed, or based on the amount of
points the card has.
They can also be filtered on products or tags, to discount specific
products.
A new feature is also being able to select communication plan for these
programs.
The manager can define a template to be sent upon the creation of a new
coupon/card or when reaching a certain amount of points.
TaskId-2675382
For empty list design:
Co-authored-by: Carlos Valverde <cvs@odoo.com>
Due to the recent changes of precompute.
The `tracking` fields of `product.template` would never be filled with
the default 'none' when the module was not loaded.
This means that any new product.product demo/data would fail the upgrade
scripts.
TaskId-2675382
The chatter and activity html have the video being sanitized upon
save. As it is a desired behavior, disable the ability to add
video from the editor for those field.
Task-2726483
closesodoo/odoo#88266
X-original-commit: c70d42d12eb522767f84a728c71ac30f66521e2a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Task ID: 2712093
Currently:
- In the payment widget the exchange difference value is always shown as 0 and is described as "Paid on", which can be confusing for a user
Desired:
- The exchange difference should have the difference amount and be described as "Exchange difference" (text-muted)
- In the payment widget pop-up, show the both the amount in company and foreign currencies
closesodoo/odoo#82206
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Because some lines can be sections/notes without a product, and the product
presence when needed is already verified by the sql constraints.
Fixes the mistake from #81818closesodoo/odoo#88244
X-original-commit: fd903101f564b1817f7b5a6aa099f644ef29a527
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The commands are grouped by command group when rendered by the Powerbox.
That creates a dissociation between the order in which they are rendered
and the order of the arrays in which they are present in the code. The
mechanism to navigate between them with the arrow keys is however
dependent on the latter. As a result we may end up with a visually
disordered navigation.
This adds a private function to reorder these arrays in the same way as
they are rendered, thereby fixing the dissociation.
task-2802749
closesodoo/odoo#87209
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When no command is found in the Powerbox, the text "No results" is
shown, which is annoying. Instead, this hides the Powerbox we such is
the case.
task-2802749
Part-of: odoo/odoo#87209
When using a pricelist with a currency different than the one
of the product, the surcharges, max_margin and min_margin must use
the currency defined in the pricelist.
These tests intends to ensure that this behavior is respected.
This behavior was in fact not present (and a fix was created in stable releases)
in previous releases (before the refactoring 57ced812f0).
To reproduce the issue:
1. Enable multiple currency and enable a second one with an exagerated rate for the sake of clarity.
2. Create a formula pricelist with the newly activated currency using either surcharge or the margin.
3. Create a SO with a standard product. By switching between pricelist, you will see an invalid price.
E.G.:
EUR_rates = 2 compared to USD PRICELIST = surcharge of 10€ on any product
PRODUCT_price = 300$ PRODUCT_price_euros = 150€
CURRENT_SO_price = (300 + 10)/rate_EUR = (300 + 10)/2 = 155€
EXPECTED_SO_price = (300 + 10*rate_EUR)/rate_EUR = (300 + 10*2)/2 = 160€
Solution:
Convert the pricelist item margin & surcharges to the base price currency.
To do so, the needed currency conversion date is given through the context.
opw-2760720
closesodoo/odoo#88243
X-original-commit: 20140e8f53633cfdf7a7147bad6055dcd707a778
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
Steps to reproduce:
- Create a new product as a storable
- Set quantity to 0
- Create a new internal transfer
Issue:
- The forecast button is in green which should not be the case
Solution:
For the internal transfers view, the green forecast button was invisible when "forecast are strictly less than 0". It should be "less than or equal to 0".
Inversely, the red forecast button should be invisible only when is "forecast are strictly greater than 0".
opw-2806764
closesodoo/odoo#88207
X-original-commit: a23108cba301a866504e2fc70aabdaf22c7ee0f8
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
Purpose
=======
Migrate subscription to sales order to simplify the code, the UX & make it more flexible for the future and easier to maintain.
Subscription still appears as a separate module.
This PR aims to move the sale.subscription models to sale.order. The implementation is quite similar to the sale_renting module.
Before this PR, sale.subscription records are similar to sale.order ones. A lot of logic is duplicated to handle the subscription line computations, tax handling, etc.
The current implementation of subscription has several drawbacks:
* the sale.subscription records depends on required sale order template.
* it is not possible to mix different periodicity in a subscription. Each partner has as many contract as periodicity needed (monthly, yearly etc)
* when the flow starts in sale_management, the first invoice must be created from the sale application.
* upsell prorata calculation to apply a discount is flawed when the salesman want to apply another discount.
This PR fixes these issues and make subscription more flexible. One record can have subscription lines with different periodicity. Each line have a next_invoice_date and invoices are generated when they are due with the matching lines.
Before this commit, the sale module could not be used to manage subscriptions in an override.
This commit adapts the sale module to odoo/enterprise#21825closesodoo/odoo#82632
Taskid: 2568007
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
momegahed