Current behavior :
When the download is finished, the wizard stay open
Expected behavior :
Wizard should automatically close after downloading
Reason :
The key `close_on_report_download` wasn't defined during new wizard implementation ( commit d9f45ba694 )
OPW-2710611
closesodoo/odoo#82472
X-original-commit: e50a60573e1f9ad201d4db8607d9ff121cd476c2
Related: odoo/enterprise#23355
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Claude Thibault (thcl) <thcl@odoo.com>
Suppose a product with several suppliers, all with the same partner. On
the purchase order, the product description will always be based on the
last supplier
To reproduce the issue:
1. Create a vendor V
2. Create a product P:
- Type: Storable
- In Purchase, add a line L01:
- Vendor: V
- Vendor Product Name: Name01
- Vendor Product Code: C01
- Quantity: 1
- Price: 10
- In Purchase, add a second line L02:
- Vendor: V
- Vendor Product Name: Name02
- Vendor Product Code: C02
- Quantity: 20
- Price: 2
- Once P is saved, ensure the lines order in the purchase tab:
- L01
- L02
3. Add a reordering rule on P:
- Min: 1
4. Run the scheduler
5. Open the generated PO
Error: The description is incorrect ("[C02] Name02" instead of "[C01]
Name01")
When computing the display name of the product,
https://github.com/odoo/odoo/blob/7691567286869ca65e63fc79c2cee11e1f415fcb/odoo/models.py#L1728-L1730
`name_get` returns a tuples list: `[(37, '[C01] Name01'), (37, '[C02]
Name02')]` where `37` is the product identifier. This list is then
converted into a dictionary and here is the issue: it will use the last
tuple to define the value for key `37`, i.e. "[C02] Name02". Therefore,
`name_get` should return the correct name, and only this one.
Another issue could be highlighted: when the user changes the quantity
of the purchase order line, if another supplier info is selected, the
description won't be updated (for the same reason as above)
OPW-2702616
closesodoo/odoo#82321
X-original-commit: a42608214f2e9ef3f5e59b4b54cd7f72a6019e06
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Since [1] whenever the image of a `product.template` is updated, the
write date of all its related `product.product` is updated. This was
done to force a change of the unique parameter on image fields, which is
based on the last update field.
After this commit the `product.product`'s last update is instead
computed by also taking the `product.template`'s last update into
account. This avoids the need for updating the write date when the
image is changed, but on the other hand it also forces product images to
be reloaded whenever any other field of the `product.template` is
changed.
[1] https://github.com/odoo/odoo/pull/71139
Related to https://github.com/odoo/odoo/pull/76309
task-2477438
closesodoo/odoo#78356
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
Purpose
=======
The fields are not used, don't work correctly and there is a specific
report to generate the product prices according to the pricelist and
the ordered quantities
Cache the pricelist rule used for price computation in a dedicated non
stored field, since it is used both for the price_unit and the discount
computation.
This divides by 2 the number of pricelist requests/queries when
discounts computation is enabled.
* Leave the flush to the orm
* Ease inheritance and customizations
* Make sure the order is correctly shared with the
product.pricelist.item model order
* Do not rely on context, everything should be cleary specified through
parameters
Catch context keys in an unique targeted place to improve code clarity
* Drop strange old API
* do not provide unused partner parameter anymore
* do not provide products, qty as a list of tuple, we only request the
same qty for all products anyway
* Clear methods, add/adapt comments and docstrings
* Reduce potential side-effects of context content.
- Adds a default `product_id` only when the supplier info is added from
a product variant form view;
- Adds a domain on `product_id` to constrain the field to its product
template, and only if it has a product template (otherwise, there is
no domain);
- Adds a onchange to remove the product variant if the user changes the
product template and they don't match anymore because before this
commit, it was possible to have a supplier info with a variant who
doesn't belong to its supplier info's product template;
- Replaces the options `no_create_edit` by `no_create`/`no_open` as the
former doesn't work as expected.
task-2581265
Part-of: odoo/odoo#74695
When Print Labels was revamped in odoo/odoo#69690 it was decided that
only product barcodes would be printed. Unfortunately we want SN/Lot
barcodes to be printed instead when they are filled in, so we make this
the case when applicable (i.e. when printing Transfer Quantites + qtys
done).
closesodoo/odoo#80079
Task: 2678336
X-original-commit: 105587e9e411442fd8e6d30efaa35b90b0e09959
Signed-off-by: Arnold Moyaux <arm@odoo.com>
The label wizard is extended from product to stock, so we can print
labels even when stock isn't installed (e.g. only purchase or sales
installed). Therefore we shouldn't reference a field that's introduced
in the stock extension (i.e. label wizard will throw a stack trace when
stock is not installed).
Noticed during task: 2678336
X-original-commit: 9aeba3668e89f14bcfa4ea37861f33ad9add86d8
Part-of: odoo/odoo#80079
Currently, if we print the pricelist report after refresh,
the traceback will occur. It has been fixed.
closesodoo/odoo#79968
Task-id: 2584806
X-original-commit: a4c2f01a8e94e7361b25862758c1a20abad6c7aa
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The documentation link for the product_images module was already
hard-coded in the settings view but has changed since then.
closesodoo/odoo#79796
X-original-commit: 92a35d5a7c4683525fcafc5c0cb1391da33347fb
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The two fields (name & price) were only updated on pricelist (`product.pricelist`) save, not when the rules were updated (`product.pricelist.item`).
The reason was that name and price are compute fields, which were added to the tree view but not added to the form view.
This commit adds "name" and "price" to the `product.pricelist.item` form view and hence the values will be updated as soon as the popup form is saved.
Fixes: #78488
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#79748
Forward-port-of: odoo/odoo#78699
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
- Create a report to show price on each template
--> Issue: The price is the same
closesodoo/odoo#78870
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce the bug:
- Go to purchase > Configuration > Vendor Pricelists
- Filters > select the “Active” filter
Problem:
Currently, the filter does not include records that do not have a specified `”date_end”`, even though they are considered active.
Opw-2659829
closesodoo/odoo#78643
X-original-commit: bb8bef5cff3b67e42218469e898f2b95e4ab315d
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
If `_name_search` is called with `limit=None` it could take time in the loop
because `_name_search` for `product.product` has `limit=100`, i.e. it could be
100 iterations to scan 10 K products. To solve this problem, call `_name_search`
with `limit=None` to get all product variants at once.
As an example, the problem is reproduced on using menu `Manufacturing > Products
> Bills of Materials`, which makes following search query:
```
["|", ["code", "ilike", "XXX"], ["product_tmpl_id", "ilike", "XXX"]]
```
for which ORM calls `_name_search`:
https://github.com/odoo/odoo/blame/9b23864027bc24032993833f213395cb45fe86bb/odoo/osv/expression.py#L863
In a customer database, this speeds up the query from 70 seconds to 3,5 seconds.
---
opw-2631012
closesodoo/odoo#77601
X-original-commit: 038816725a988a0ada3d6f8518a436ea46a81eba
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
The combination of a RR and a supplier that has a minimum quantity and a
lead time leads to incorrect results
To reproduce the issue:
1. Create a product P:
- Type: Storable
2. Add a reordering rule for P (min: 10, max: 50)
3. Add a vendor to P
- Quantity: 1
- Price: 1
- Delivery Lead Time: 7
4. Run the scheduler
5. Open the generated PO
Error: The order deadline is <today minus 7 days> instead of today. The
receipt date is today instead of <today plus 7 days>
When computing the quantity to order, the method needs the value of
`qty_forecast` (L254 in [1]) The computation of `qty_forecast` leads to
the computation of `lead_days_date`. To do so, it gets the lead days of
the associated stock rule `_get_lead_days`. In this method, a seller is
selected: [2] However, none of the parameter is defined: [3]
In the above case, the seller has a minimum quantity of 1. Therefore,
since this information is not given in [2], the vendor is not selected
and his lead time is therefore not taken into account. So,
`lead_days_date` will be equal to 0 and won't be recomputed. As a
result, the planned delivery date is today. Then, the quantity to order
is computed (L260 in [1]), so later, the module is able to select the
correct seller. However, this one has a lead time of 7 days -> the
generated PO will have the planned date to today and the order deadline
to <today minus 7 days>
Once an orderpoint has its quantity to order defined, its lead time
should be recomputed because it may be different depending to the
selected seller (and thus we should take this quantity into account when
searching for a seller)
[1]
https://github.com/odoo/odoo/blob/59ac8d891de6e20604494d6cfc6fc357a88d226c/addons/stock/models/stock_orderpoint.py#L254-L260
[2]
https://github.com/odoo/odoo/blob/1b03087524080f1a9751b1561cd8891466e72367/addons/purchase_stock/models/stock_rule.py#L153
[3]
https://github.com/odoo/odoo/blob/045c6ad3353bb0849d3f93d3488d8dcd8b8975b0/addons/product/models/product.py#L602
OPW-2614798
closesodoo/odoo#77110
X-original-commit: f2eb1dca99d16d70613c2f724d4b73f273a49ae7
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Commit fa034b2a64 removed lst_price on
product.template That means we need to check if product is a variant or
not to choose the suitable price field.
closesodoo/odoo#76503
X-original-commit: c50e7b106b08577228a410e1e34403bd8a6eb80d
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Several changes distinguish product attributes better from variant
attributes. The variant creation mode is added on the template form for
attribute lines with more than one value. Specification attributes are
no longer listed as variant attributes in the product variant form and
tree views.
task-2466988
closesodoo/odoo#72559
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Tom De Caluw <tdc@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
Description of the issue/feature this PR addresses:
Currently, we cannot display prices per unit (for example $/kg, etc.)
on products shown in the shop. This is important for any eCommerce
business that sells something other than units, or just for informational
purposes.
Desired behavior after PR is merged:
Allows the user to add unit measurements for products. This behaviour is
disabled by default, and can be enabled through the settings page by
activating "eCommerce Base Unit Price" option.
Enabling it displays a price per unit field in /shop's product page,
comparison tool and cart. The price per unit of measurement is
automatically computed and can be displayed both on the product,
the cart and the comparison pages.
Enabling it also modifies the product's configuration page to include
what unit of measure to display in the price per unit field, as well
as the number of units used to calculate the price per unit.
task-2558128
Part-of: odoo/odoo#72242
Co-authored-by: Kamen Zhekov <kzh@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
This commit removes the pdf and zpl reports for product templates and
variants. Instead, labels are printed via a new wizard allowing to
specify the label quantity, format and optional text.
There are a bunch of usual retail label sizes in pdf or zpl code
Task : 2501730
closesodoo/odoo#69690
Related: odoo/enterprise#20246
Related: odoo/upgrade#2542
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Improve the UI for the MO and the WO with some new features, better readability and usability
- The forecast for the MO in draft makes the preparation of a MO easier. The behavior of `forecast_availability` depend of the state of the move
- The sum of expected duration and real duration in the MO, make the MO visually clearer
- The field Scheduled Date is rounding up to the next hour for less manipulation
- The automatic reference in a BOM if there is already a BOM for this product allows making less manipulation. I'm using this variable `number_of_bom_of_this_product` with the result of the query inside so I didn't need to do the query twice and the query doesn't take the current bom.
- A rounded value is better for the OEE in WO summary
- Have a tag for a workcenter can be a good idea to add more information to it. I'm using a random value for the color of the tag, we are doing it frequently to have a random color on multiple think.
- Knowing the final product of a WO is clearer
- To notify the user when creating a product with a reference that are already existing is a good idea.
- Change some color in the MO view for better readability
- And more minor tweak (like to align some part in the view)
--- Links ---
The PR: https://github.com/odoo/odoo/pull/74540
The PR on enterprise: https://github.com/odoo/enterprise/pull/20006
Task related: 2442895
closesodoo/odoo#74540
Related: odoo/enterprise#20006
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
PURPOSE
Display the color of the attribute value on the product kanban card
SPECIFICATION
Add color field for models `product.attribute.value` and
`product.template.attribute.value`.
Task-2593655
closesodoo/odoo#74356
Related: odoo/enterprise#20048
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* Linting, typos & cleanup
* Avoid using the context to pass data to the server
* JS: let the web client service manage the data transfer
instead of "manually" specifying it in the report_name
closesodoo/odoo#73198
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
------
In the new pricelist report, showing the resulting price of a product in the
situation of a pricelist or another, for certain quantities, the specified
quantities are shown as "X Units".
This can be misleading when using multiple Unit of Measure, because
the quantites are expressed in the products unit of measures, thus
not always in "Units".
We should probably either group the products by UoM, to display
adequates column titles, or we should update the display to make sure the user
understands clearly that the prices are /unit in the product uom.
users should be able to 'hide' pricelist name on the PDF.
TaskID-2360597
New reception report added for non-outgoing transfers. This is intended
to support easier stock allocations by allowing dynamic MTO
assignment/unassignment, e.g. if we have an incoming transfer with
products we want to assign to an existing outgoing transfer, then we can
use the report to create a MTO link to the specific outgoing moves. To
support this assignment flow, the report also allows printing of labels
to place on the product so stock workers know which transfer/MO the
product has been assigned to.
Expected use case is when a product is purchased to fulfil a sale.
Demo data has been added so reception report can be immediately
seen/used for this flow.
Implementation Notes:
- Report has been made flexible to work with batch transfers.
- Only done moves can be assigned to moves that already have quants
reserved (prevents undesired behavior + this makes sense logically)
- Confirmed (+ Done and everything inbetween) moves can be assigned to
any confirmed moves that are not already assigned.
- Report does not affect quant reservation/unreservation at all. It
works only with linking moves (i.e. move_orig_id/move_dest_id) so
move/transfer linkage traceability is stored within db (i.e. this
isn't possible with quants)
Limitations: To keep code simple for now, this assignment flow will
break in certain cases:
1. Done amount of an assigned move is less than the Demand amount
(linked move will not autoreserve correctly when assigned move is
validated, same issue already occurs in multi-step transfer).
2. If a linked move is unreserved after its assigned move is
validated, then another move can reserve its quants and its
assignment link will not be accurate.
3. Already reserved SNs + assign move, may lead to mismatching SNs
between report and what's actually reserved.
4. Changing a linked move's Demand amount after a move is assigned to
it.
5. Potential moves to assign to are only checked for being in same
warehouse, not in a matching source location to destination location.
User is expected to make this match on their own.
Task: 2500844
ENT PR: odoo/enterprise#18268
Upgrade PR: odoo/upgrade#2731closesodoo/odoo#70669
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Automatically activate `group_multi_currency` if there is more than one active currency,
deactivate it if there is only one active currency
retain sale/pos feature of activating group_product_pricelist
adapt tests accordingly
Task 2610735
closesodoo/odoo#74396
Related: odoo/enterprise#20106
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Users will now have a quick way to add images on their products in batches, allowing fast visual identification of them.
task-2518519
closesodoo/odoo#70198
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Excluding non-active records decreases number of combinations generated in
_cartesian_product. The excluded combinations have to be rejected anyway [1], so
don't waste time on it.
STEPS:
* activate "Product Configurator"
* create a product with many attributes
* make some `product.template.attribute.value` inactive (ptav_active = False):
** create a sale order with that value (e.g. color "Black" in "Customizable Desk (CONFIG)")
** delete that value in `product.template` form (tab "Variants")
* add the product to a sale order
* RESULT: `_cartesian_product` doesn't generates combination with archived attribute
[1]
https://github.com/odoo/odoo/blob/f9d26509a714ecd290c42e1d58e416bb01268447/addons/product/models/product_template.py#L839-L841
---
opw-2540675
closesodoo/odoo#74310
X-original-commit: ce487c920c777735e5e7e46ee131cb18dfc5c9fc
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
