Suppose a tracked-by-usn and consumed product returns in the stock
thanks to a repair order. Using again this component in a new
manufacturing order will raise an error
To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create two products P_finished, P_compo
- Storable
- P_comp tracked by USN
3. Update the quantity of P_compo:
- WH/Stock: 1 x Lot01
4. Create a manufacturing order MO:
- Product: P_finished
- Components:
- 1 x P_compo
5. Confirm, Check availability and Mark MO as Done
- (Lot01 should be consumed)
6. Create a repair order RO:
- Product: P_finished
- Parts:
- Type: Remove
- Product: P_compo
- Lot: Lot01
- Destination Location: WH/Stock
7. Confirm RO, Start RO, End RO
- (There should be one Lot01 available in stock)
8. Repeat 4-5
Error: When checking the availability on the MO, Lot01 is correctly
reserved. However, when marking the second MO as done, a User Error is
displayed: "The serial number Lot01 used for component P_compo has
already been consumed" although this lot should be available
When checking the uniqueness of the lot, nothing includes the products
back in stock thanks to the repair orders.
OPW-2701668
closesodoo/odoo#82544
X-original-commit: 3d9355f90fa1dd9436f1745c515c89947ed04de0
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Instead of using sort + groupby of itertools (which group only
consecutive), use only the groupby of odoo.tools which
decrease the complexity of the code and avoid unmatched keys
between sort keys and groupby keys
task-2648449
Part-of: odoo/odoo#76761
no need to make rounding during computing qty_available
STEPS (see the test):
* create product with uom dozens
* create product with uom units
* create bom kit to convert one to another
* set qty on hand to 1 for product dozens
* check qty for product units
BEFORE: qty=11
AFTER: qty=12
---
opw-2632782
closesodoo/odoo#76242
X-original-commit: 26b28408d8970baa8cbf59ffaff90cab1e579410
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When a product's has a kits bom, we consider it a kits product.
When a product is a kits product, we count its "on hand" and "forecast"
qty by caculating how many can be produced according to the bom.
We add status button to the show the qty on kit product form.
Task-2444000
COM PR odoo/odoo#75555
ENT PR odoo/enterprise#20440
UPG PR odoo/upgrade#2783
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This revision has a similar goal than the previous revision
62c5b8d95c1ba5634e201c0c8a3e2d91fb2305a7
but this times, it's a kit/phantom bom which is nested in another
kit/phantom bom, and their computation is asked in the same time.
```
2021-08-20 11:29:54,835 1689 ERROR db_22687 odoo.upgrade.stock.tests.test_on_hand_quantity: FAIL: TestOnHandQuantityUnchanged.test_check
Traceback (most recent call last):
File "/tmp/tmpv3ujv2vr/migrations/testing.py", line 208, in test_check
self.check(value)
File "/tmp/tmpv3ujv2vr/migrations/stock/tests/test_on_hand_quantity.py", line 20, in check
self.assertEqual(before_results, self.convert_check(after_results), self.message)
AssertionError: Lists differ: [[551[14585 chars] [8988, '137'], [8989, '137'], [8990, '20'], [[1793 chars]91']] != [[551[14585 chars] [8989, '137'], [8990, '20'], [8991, '126'], [[1778 chars]91']]
First differing element 1007:
[8988, '137']
[8989, '137'
```
```
SELECT b.id, b.type, p.id as kit_product_id, b.product_tmpl_id as kit_product_tmpl_id, pt.name as
kit_product_name FROM mrp_bom b JOIN product_template pt ON pt.id = b.product_tmpl_id JOIN product_product p ON p.pr
oduct_tmpl_id = pt.id WHERE p.id = 8988;
-[ RECORD 1 ]-------+-----------------
id | 2208
type | phantom
kit_product_id | 8988
kit_product_tmpl_id | 9049
kit_product_name | KIT Poulie AR G4
```
```
SELECT b.id, p.id as kit_product_id, b.product_tmpl_id as kit_product_tmpl_id, pt.name as kit_product_name, l.product_id as component_product_id, component_t.name as component_name FROM mrp_bom_line l JOIN mrp_bom b ON l.bom_id = b.id JOIN product_product p ON p.product_tmpl_id = b.product_tmpl_id JOIN product_template pt ON pt.id = b.product_tmpl_id JOIN product_product component ON component.id = l.product_id JOIN product_template component_t ON component_t.id = component.product_tmpl_id WHERE l.product_id = 8988;
-[ RECORD 1 ]--------+---------------------
id | 2213
kit_product_id | 8761
kit_product_tmpl_id | 8879
kit_product_name | VEL BP KIT direction
component_product_id | 8988
component_name | KIT Poulie AR G4
```
upg-22687
closesodoo/odoo#75735
X-original-commit: c2df3d43fe16dde9057422f573fed1b976bc1c0b
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
For improved cost analysis, byproducts can now have a "cost share" (out
of 100%) indicated. This cost share will by multiplied by the total BoM
cost (i.e. components + operations costs) and reflected in the stock
valuation. The final product will also have the byproducts cost
subtracted from its final stock valuation. This is of course only
applies when costing methods are appropriate (i.e. non-standard price).
Additionally, we can now "Compute Price from BoM" for byproducts (via
its product form) and the BoMs that it is a byproduct of are now counted
towards its # BoMs smart button (we will now also see these BoMs when
clicking on the smart button). Of course when there is no cost share for
byproducts then clicking on "Compute Price for BoM" will not change the
a byproduct's cost and if there are multiple BoMs the prodcut is a
byproduct of, the calculation will only be based on the first BoM it
finds (i.e. same as current logic for manufactured products).
BoM Cost report has been updated to include byproducts with cost shares
(byproducts with cost share = 0 will not show up in report).
Additionally we update the report to display operations only costs now
that BoMs are allowed to have no components in them.
Part 1 of Task: 2440068
Upgrade PR: odoo/upgrade#2727
Related ENT PR: odoo/enterprise#20169
Part-of: odoo/odoo#74951
On BoM, a component line can be filter out depending
of the product variant to manufacture
(with "Apply on Variant" field).
Extend this feature to operation and byproduct line.
task-2614126
closesodoo/odoo#74973
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When updating the quantities available for a product, an inventory move
is generated without setting the product_tmpl_id, as this field is related
to the product_id of the move. However, when creating the move, Odoo will
consider it a default missing value and will try to fill it in the method
default_get.
When navigating to the product variants of a template from the template form,
a default_product_tmpl_id is set in the context pointing to the template. This
context is propagated to the update quantity action to create/update quants for
the variant.
The problem when dealing with kits is that the products available to update
their quantities are the components of the kit. When navigating to a variant
and updating the quantities of a component of the kit variant, the default product
template in the context will be the kit template.
This is causing that, when generating the inventory move, the move is created with
product_id of the component, and product_tmpl_id of the kit template.
This issue creates a critical data inconsistency as the component's template is set
to the kit's template, which apart from making no sense generates a recursion error.
To fix this, when triggering the action to create/update quants for a kit product, it
must be ensured that no default product template is being set.
closesodoo/odoo#71069
X-original-commit: bdeea73dc1efb6ff7d02cc2f58347a69762bcc3c
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
previous implementation works slowly for products with many variants.
Performance Test
================
* ~5 K product.template
* ~14 K product.variants
* ~12 K mrp.bom
* ~414 K mrp.bom.line
Reading time for field ``used_in_bom_count`` on a product with ~1000 variants
* Before 9,5 sec
* After 1,5 sec
---
opw-2494423
closesodoo/odoo#69341
X-original-commit: a2d63e8ae5d6bc0e822d12d724b5e3ff5a979cad
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Some usage of `_bom_find` are performance bottleneck (one request by
product). By example, when the mrp is installed, search products
with fields compute by `_compute_quantities` (e.g. 'Negative forecasted
quantity'). it is due to the override of `_compute_quantities`
in mrp which will make (in the worst case) a `_bom_find` for each
product in the DB.
To avoid this situation the `_bom_find` method become batched
which can handle several products in once. The signature of the method
has changed and uniformize in all module.
Example performance Gain:
------------------------
In a DB with 7000 products (type 'product'), 500 locations, 1800 BoM,
9000 Stock moves, etc. Search in the tree view with filter "Negative
forecasted quantity":
Before: 10879 (nb SQL request) 12.67 +- 0.11 sec (Total RPC Time)
After: 159 (nb SQL request) 1.82 +- 0.03 sec (Total RPC Time)
task-2439019
When `qty_available` was being called
for a kit and its components at the same time,
e.g.:
- Kit product
- Product 1
- Product 2
The kit product available qty was always computed to `0.0`,
because when computing its component available quantity,
they were computed to `0.0` because they were marked
as `protected` by the ORM when calling the compute method
for these records at the first call.
When the `qty_available` compute method for the kit
then called recursively the `qty_available` compute
method for the component, as the component record
were marked as protected,
the ORM filled their value with the Falsy value `0.0`.
This issue occured particularly in the upgrade integrity unit test
which makes sure the available quantities of the products remain
unchanged after upgrade. This test computes the available
quantities for a bunch of products at the same time,
and its therefore likely a kit product gets its available
quantity computed as the same time than its components.
upg-3185
upg-4215
upg-4228
upg-5558
upg-5745
upg-5856
upg-6012
upg-6064
upg-6076
upg-6306
upg-6514
upg-6588
upg-6729
closesodoo/odoo#65758
X-original-commit: 8e152a567a6003dae4abb3b537b963eec4142d6d
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
When running the scheduler, if one of the concerned product is a
kit, it will always generate a RfQ for the components, even if there
are already enough of them.
To reproduce the error:
(Need purchase)
1. Create 2 products P and P_compo
- Both must be storable products
- P_compo must have at least one vendor
2. Go on P-product page
3. Add a reordering rule (e.g., min: 5 and max: 10)
4. Add a BoM
- Must be a Kit
- Add P_compo to components
5. Inventory > Operations > Run Scheduler
6. Go to Purchase, find the generated RfQ
7. Confirm the order, Receive Products, Validate
8. Go on P-product's page
- As you can see, you have enough P-products on hand
9. Repeat steps 5-6
=> You should not find any RfQ since you already have enough P-products.
When checking the P-product's page, you can see the correct quantity on
hand because it uses the `_compute_quantities` method and this one has been
overridden in the mrp-module so a kit will be correctly computed.
However, when running the scheduler, it uses another method to get the
current quantities: `_compute_quantities_dict`. Since this method has
not been overridden in mrp-module, it will use the basic implementation
and this one does not consider the possibility for a product to be a
kit.
This fix creates an override of `_compute_quantities_dict` so it can
compute the correct quantities of products with 'phantom' as BoM type.
Moreover, for the code to be simpler and clearer, thix fix also merges
`_compute_quantities` and the new `_compute_quantities_dict`.
OPW-2421841
closesodoo/odoo#64326
X-original-commit: 609e2f4427082431b56aa8f999d74ed9d39db653
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
- Create Product A with UOM of type Unit
- Create Product B with UOM of type Unit
- Create BOM of type Kit on Product A with Product B as a component
with UOM of type Unit
- After saving BOM, change the UOM of Product B with UOM from another
categories (e.g. kg) and save the product
- Try to access product list
A warning appears and prevent showing the products in any way.
It is caused by the call to `_compute_quantities`.
In this case, it is ok to skip the error. Indeed, it will raise later on
when trying to use the kit. But at least, it gives the possibility to
the user to access the product list.
opw-2393711
closesodoo/odoo#62537
X-original-commit: 6de2537ac82d9dad3cb3f56a7b9b35856681a6ad
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The 'On Hand' button triggers action_open_quants on product model. It
do not explode the kit into its component
closesodoo/odoo#62390
X-original-commit: 49b965eb1ec6a7ec6c07fa643cc6ae35ee8b5d91
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Steps to reproduce:
- Let's consider a product.template TP with a kit
- Let's consider the variants V1, the only variant of TP with a kit
- The virtual_availalbe of V1 is 100 (smart button Forecasted in the form view)
Bug:
The virtual_available of TP was 0 instead of 100
The virtaul_available of a product.template must be the sum of virtual_available of all its
variants with kit
PS: This commit changes the available quantity of product_product_table_kit in demo data.
As this quantity was not equal to 0, the type of the product could not be changed.
opw:2297226
closesodoo/odoo#57325
X-original-commit: 74b762da63e159b1965428b2bcb972293c4efea6
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Co-authored-by: Florent de Labarre <florent.mirieu@gmail.com>
Steps to reproduce:
- Let's consider a product.template TP with a kit
- Let's consider the variants V1, the only variant of TP with a kit
- The virtual_availalbe of V1 is 100 (smart button Forecasted in the form view)
Bug:
The virtual_available of TP was 0 instead of 100
The virtaul_available of a product.template must be the sum of virtual_available of all its
variants with kit
PS: This commit changes the available quantity of product_product_table_kit in demo data.
As this quantity was not equal to 0, the type of the product could not be changed.
opw:2297226
closesodoo/odoo#55707
X-original-commit: 4df4ad023b9dd24edf75e8993d1d31c73ce26bc0
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Co-authored-by: Florent de Labarre <florent.mirieu@gmail.com>
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
Go to inventory>product variants (list view), search for
'FURN_78236'.
Set quantity on hand (qty_available) 50
Now, back in list view, adjust your search to FURN_7
QTY on hand for FURN_78236 is 0.
This occur because during the computation of qty_available, the bom
kits (FURN_78236) are calculated first, but the qty_available depends
on the bom lines products, which are calculated only at the end.
Since qty_available became protected by the global environment, it
cannot be recomputed recursively and it is not in cache, thus is 0.
Making the simple products compute first in the _compute_quantity fix
the issue
opw-2226417
closesodoo/odoo#48924
X-original-commit: f41c650f162021bb6c76736c7dcbe4eee059cec1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
PURPOSE
Keep consistent behavior of the stat buttons and the different stock
reports when archiving a product
SPECIFICATION
Currently, you can archive a product but the behavior of the different
stock reports, stat buttons isn't coherent afterwards. Here are the
different behaviors that should be improved:
1.Keep quantity on hand and forecasted quantity visible (in the stat
button + when opening it)
2.Automatically (un)archive RR and BOM if the product is (un)archived
3.Valuation report: show the archived products without the "archived"
filter (behaves already this way in the inventory and forecast reports)
4.When a product has been archived and still has quantity in stock,
include it in inventory adjustments for which counted quantity = default
to stock on hand (dont do so for archived exhausted products).
Also, revert #47478 since we don't have active field.
LINKS
Task 2178269
PR #45586Fixes#41634
Related: odoo/upgrade#811
Related: odoo/enterprise#8513
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Create a new Product
- Add a BOM to this product
- Set the BOM to be a kit
- Add components to the BOM
- Create a PO for the components for a qty of 5
- Confirm the PO but don't transfer the products
- Check the phantom kits outgoing_qty and incoming_qty they will match
A Phantom Kit Products outgoing_qty and incoming_qty are identical
Closes#43447closesodoo/odoo#43584
X-original-commit: 4b2e235be6cab947ce2e0b3b17b54530f984ce72
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When a BoM is using a component with a quantity required set to 0,
tracebacks were occuring when computing the available quantities
for the kit.
Fixes#38807closesodoo/odoo#39267
X-original-commit: 7676269ba56c8e293ef4cd3dffbe7eccbad4a9d0
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Computing quantities of a kit product made only of consumable
failed as the quantities are not initialized.
This commit makes sure this kind of products don't have their quantities set up
in mrp and so are set to 0 in stock
closesodoo/odoo#37382
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this commit, the product/product template computed mrp quantity
fields wasn't computed by active company but for all companies.
So, set `compute_sudo` on false for the different computed mrp quantity
fields of products and product templates to avoid to search with sudo
active and to search by company.
The computation of kit quantities was not efficient. A loop on each product
of the recordset to consider performed. Each time a product was seen as 'not a kit',
a new computation on the complete recordset was done. This leads to a N^2 complexity
This commit only compute stock quantities for non kit product in one batch
Selling a product you don't have in stock anymore triggers a message
without pertinent information about available quantity.
This commit adds a little widget on sale order line to inform the salesman
there are not enough quantity available. Clicking on it will reveal:
* The estimated delivery date
* The actual quantity on hand
* The quantity forcasted at the estimated delivery date
For kit product, the quantities are the maximum occurence of kit available
regarding components quantities.
Task 2003485
closesodoo/odoo#34336
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The stock module adds 4 quantities on products:
Quantity on hand
Incoming quantity
Outgoing quantity
and Forecast Quantity
Forecast Quantity is equals to Quantity on hand + Incoming quantity -
Outgoing quantity. Those two last ones are computed from the open stock
moves wainting to be validated but the reservation is not taken into account.
This commit introduces a fifth quantity 'free_qty' that acts like the forecast
one but only with reserved quantities.
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
last_year_mo_order was removed in commit 4a350ff8cc. However it was still used in action_view_mos.
This commit adpat the action context in order to keep the same behaviour than previously.
task id 1922547
closesodoo/odoo#30347
Several last cleaning in the product and product variant form :
- various labelling and design improvements
- sales, purchased and manufactured stat button (number of sales was
incorrect and click will now open normal sales analysis)
- now archiving related product.template if there is only one active product.product
Task-1880039 closes#28633
The quantities for kits were computed only if sale_mrp was installed.
That's why the override of the method 'compute_quantities' needs to be moved in MRP.
TaskID: 1929518
closesodoo/odoo#30271
In purchase we add a stat button that counts the number of purchase
orders linked to the product.
In this commit we change this count to count the quantity of products
linked to a purchase order.
We basically do the same thing with the stat button of sale (sale
orders) and mrp (manufacturing orders).
There was a filter 'Bom Components', that didn't filter anything. So we
make it work to show the products/product templates that are used as
components in BOM.
We've also added a filter 'Manufactured Products' that show the
products/product templates that have at least one BOM
TASK-54350
- Display correct bom count for product, before this commit it was
not displaying the bom count when we have bom for template without variant.
task-39561
- Create a Product A with attribute color and attribute values white and
black.
- Create 3 products (Components 1, 2 and 3)
- Create a BOM for A like:
Component 1, Variant column is empty
Component 2, Variant white
Component 3, Variant black
- Go to Inventory > Master Data > Product Variants, and open one of the
2 variants of Product A
The BOM count is zero, while it should be 1.
The current implementation of `bom_count` doesn't take into account
attributes that can be set on the BOM line.
opw-1814973
In case a product is a single variant we should not leave it with a BoM
of zero as soon there is a BoM for its template. This would for example
hide the `compute_price` object button which relies on the `bom_count`to
be visible.
BoM is not found for a single variant product and compute price not
possible from the `product.product` view although it is implemented
actually there.
Closes#16237
- Create a product with 2 variants
- Create a BOM specific for each variant
- Go in the product variant page
the stat button indicates 2 BOMs instead of one.
opw-725126
Adrien Widart