On this situation:
* P1 consumable product, kit, with components P2 and P3 in its BoM using
1 of each
* P2 comsumable product, kit, with component P3 using 1 in the BoM
* P3 storable product, 10 units in stock
Before:
The qyt_available for P1 is 10. That's incorrect: to assemble one P1 we
need precisely two of P3s, one for P2 BoM then an extra for P1 BoM.
After:
The qyt_available for P1 is 5.
closesodoo/odoo#122939
X-original-commit: b32554322d4c26665bdcb29fd58bb95f12faa20e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>
Since starting a workorder and marking it as done replaces the
planned dates with the actual ones,
there is no need to keep dates which will always end up being the same.
task: 3108291
see odoo/enterprise#36102
see odoo/upgrade#4247closesodoo/odoo#110550
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Reproduction:
1. Install Sale, Inventory
2. Go to Sale->products, search for “Customizable Desk”
3. Hover the cursor on the stat button “Sold”, from its definition, the
analysis should show the sold items in last 365 days
4. Click on the “Sold” button, no filter for “Order Date”
Reason: in V14, the “time_ranges” feature is removed. Thus using it in
the context won’t create any filter for searching
Fix: We use a custom filter to replace the time range "last_365_days".
We also make sure that the domain produced by that filter is the same as
the one used to compute the button count server side (this was not the
case in Odoo 13 when "last_365_days" was used). Similar fix is also done
in mrp and l10n_ar. Mind the utc convert for correct results.
opw-3000595
Related commits:
Removal of time_ranges: https://github.com/odoo-dev/odoo/commit/be5a51a345b8986da0e19627260f64f984e11ae9
Date filter fix: https://github.com/odoo/enterprise/pull/10938closesodoo/odoo#108951
X-original-commit: 03057029b210a59f3d7012aeea66cfa95790a8c8
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Liu Jinjiu (jili) <jili@odoo.com>
When a kit template has several variants, the on hand quantity can be
incorrect.
To reproduce the issue:
1. Create two products P_compo, P_kit:
- P_kit:
- Storable
- Variants:
- Color (White, Black)
- P_compo:
- Storable
2. Update the on hand quantity of P_compo: 10
3. Create two BoMs:
- BoM01:
- Product: P_kit
- Variant: Black
- Type: Kit
- Components: 1 x P_compo
- BoM02:
- Product: P_kit
- Variant: White
- Type: Kit
- Components: 2 x P_compo
4. Open the form view of the template P_kit
Error: it displays "15 units on hand", which is impossible (there are
only 10 P_compo available)
Since it is difficult to determine the expected value, a decision has
been made: hide these smart buttons if a template has more than one
variant and if at least one of the variants is a kit.
OPW-2645299
OPW-2678400
OPW-3076502
closesodoo/odoo#108284
X-original-commit: cf3b83d6a48c080d900d9cf343e4012be718c79d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce the bug:
- Create a BoM with components
- Archive one of the components
Problem:
No warning is displayed for the user to inform that the product is
used as a component in a BoM
opw-3089104
closesodoo/odoo#107863
X-original-commit: 9b7c416387d93507b6f750aba58ad6233a59d512
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The main motivation for this change is to improve performance of BoM
`explode`, which heavily rely on checking the lines to skip. `explode`
is also called from product `compute_quantities_dict` which is called
multiple times during upgrades. With this fix we improved the running
time of an upgrade _test_ from 3h:30m to 2h:55m which gives a 16%
performance improvement.
The goal of `_skip_bom_line` is to check that for each attribute present
on the line, at least one value associated to that attribute must be in
the attribute values of the product(*). If none is found then we
consider that we can skip the line.
The previous implementation was inefficient. It grouped all values by
attribute, then checked one by one if at least one value is on the
product. In case one attribute does not have any value on the product it
skipped the line.
The implementation we propose here is to take the intersection of the
product and line values, then check that their attributes are the same.
The later can be done with a simple length check. In case they are
different the line must be skipped. Note that this works because only
one value is possible per attribute in a product.
Both implementations are equivalent. The second is more efficient
because does not branch and relies on (record)set operations.
For example, let's consider a product with two attribute values
`a` and `b`, and a line with multiple values `a`,`y` for
attribute 1, and `z` for attribute 2.
```
Product Line
+---+ +-----+
| a | <- same attribute -> | a,y |
+---+ +-----+
| b | <- same attribute -> | z |
+---+ + ----+
```
This line must be skipped. The reason is that the value `b` is not
among the list `[z]` of values for attribute 2 on the line. The new
implementation would get the intersection of attribute values as `[a]`
from there the comparison of the attributes will fail because `[a]` has
only one attribute while the line has two.
Let's consider a second case, where there is no value on the line for
attribute 2.
```
Product Line
+---+ +-----+
| a | <- same attribute -> | a,y |
+---+ +-----+
| b | <- same attribute -> | |
+---+ + ----+
```
This line is not skipped because there is no value for attribute 2 on
the line. Therefore the condition(*) per attribute is not violated for
this product. The new implementation gets `[a]` as intersection of values,
but now the attributes coincide: they are both attribute 1 for the
intersection and the line.
Finally,
```
Product Line
+---+ +-----+
| a | <- same attribute -> | a,y |
+---+ +-----+
| | <- same attribute -> | z,w |
+---+ + ----+
```
This line is skipped because none of `[z,w]` are in the product. The new
implementation would get again `[a]` as intersection which does not
match the attributes on the line.
closesodoo/odoo#105019
X-original-commit: 47f4c3cc72ecb612ef4edd8c603e27b698187d8a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Since the new Overview report can compute the lead days and availability
delays from a BoM and all of its components and/or subassemblies, we can
use this data to compute the days that would be required to resupply all
components from a BoM.
So we add a button to compute it directly on the product form.
Task-2628323
Part-of: odoo/odoo#93194
This commit achieves two things:
1) Avoid calling super() on an empty recordset, in case all products
are kits. Even on an empty recordset, some queries would be fired.
This commit avoids them.
2) Use prefetch to read kit components quantity fields, to make use
of the recorset optimizations that ends up saving sql queries.
Otherwise, component quantities were computed on-demand one by one.
closesodoo/odoo#94225
X-original-commit: ef4ae7f62d6b690b4745b4145ce25ff02b6b29f6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
- Add the concept of 'Days to Prepare MO' in mrp, similar to 'Days to
Purchase' but defined at the product level. Both concepts are merged into
Days to Order at the orderpoint level, taking the value of Days to Purchase
for orderpoints with a buy route and Days to Prepare MO for orderpoint with a
manufacturing route.
- Add the concept of 'Visibility Days' on orderpoints. The idea is to
avoid to create through reordering rules multiple small orders for the
same product on a small time frame but rather to order directly a bigger
quantity. When Visibility Days are defined, the quantity of the orders
created by a RR is not the quantity forecasted at Today + Lead times
(quantity that triggered the order according to the RR), but the
quantity forecasted at Today + Lead Times + Visibility days.
The Visibility Days are different for purchase and manufacturing.
Changing the route of the orderpoint will change its value. They
can be defined at the company level and further fine-tuned on the
orderpoint. In case of change of the parameters at the company level,
only orderpoints without a specific value of Visibility Days will
be changed.
- Alignement between Manufacturing and Purchase Security Lead Time
(previously the Manufacturing Security Lead time didn't impact the
procurement date, instead the manufacturing time was made longer).
closesodoo/odoo#86682
Task-id: 2738838
Pr: https://github.com/odoo/odoo/pull/86682
Related: odoo/upgrade#3415
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
``get`` default is a dict that gets evaluated to be sent as parameter,
causing an unnecessary read on the component's computed fields.
The read should only happen only if we don't have a value in ``res``.
closesodoo/odoo#88050
X-original-commit: 4d16869e5c0a627dfe32ad1c8f54e83373dc3c8b
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Purpose
=======
On product list we can see that kits are listed with quantity on hand
equals to the lesser quantity of the kit's components.
When applying the filter **Quantity on hand greater than 0**, the kit
disappears from the list.
The issue is that we compute product quantity from stock.quant, for kits
we don't create a quant beacause it's not a physical product.
Specification
=============
To solve the issue, we extend the method **_search_qty_available_new** from
**stock.product** in **mrp.product**, where we fetch all kits and add the id
of the products that verify the given condition.
opw-2717594
closesodoo/odoo#86262
X-original-commit: 9db235a0d8cb1f7a371a1dec8a441329de5d5eb8
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
decimal places while we compute stock_quants.
closesodoo/odoo#84708
X-original-commit: fba9c9f32cb3d53841946588a999998f6c936e26
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
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'`
Bert Stomphorst