Add test for use case fixed by d43e9cb9ad8d1c0c020209de0e8f6ffdcbc960a1
closesodoo/odoo#89237
X-original-commit: 21be0d8e96b9fb6e9fd6476a664ce89b017a7767
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Usecase to reproduce:
With BoM structure
- Product A (RR 1-20)
|
Product B (MTO)
|
Product C (RR 5-50)
|
Product D (Buy)
Launch the RR. The MO are:
Current Behavior
- Product A 20
- Product B 20
- Product C 50
- Product C 70
Expected Behavior
- Product A 20
- Product B 20
- Product C 50
It happens because the MO are created as draft during the
`_run_manufacture` and are confirm at the end of
`_procure_orderpoint_confirm` in '_post_process_scheduler`.
However at the first MO for product A, it creates a MO for product B
and since it consumes product c, it checks if the orderpoint should be
trigger. MO for product C still "draft" and the orderpoint forecast is
now -20, so it will create a new procurement for product C with 70 units
To fix it we take the MO draft linked to the orderpoint for the
forecasted quantity.
closesodoo/odoo#89079
X-original-commit: 199a0dd0f013655a3c2345a41bc7c721e09bfc68
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In some cases, it is not possible to produce a tracked product that has
been used as a component of another product.
To reproduce the issue:
1. Create three products A, B, C:
- A storable
- B storable and tracked by lot
- C consumable
2. Update on-hand qty of B
- 10 x lot L01
- 5 x lot L02
3. Create two bills of materials
- Product: A
- Components: 1 x B
- Product: B
- Components: 1 x C
4. Produce 15 x A (MO01)
- Note: it should use 10 L01 and 5 L02
5. Produce 15 x B with lot L03 (MO02)
Error: When marking MO02 as done, a user error is displayed: "Cannot set
the done quantity from this stock move, work directly with the move
lines." The user should be able to mark the MO as done.
When confirming MO02, it confirms the associated SMs. Since the
conditions are respected, we try to assign both consumed and finished
moves. Because of step 4, there are two quants for the product B in the
production location (one for L01 and another for L02). Therefore, when
reserving the qty of the finished move, two SML are generated. As a
result, when marking MO02 as done, we write the `quantity_done` on the
finished move. This triggers the inverse method and leads to
`_multi_line_quantity_done_set`, where the error is raised because the
done quantities are not defined on each SML:
https://github.com/odoo/odoo/blob/1354081e43b71edbd434dccc6df6d0881c672a81/addons/stock/models/stock_move.py#L363-L364
Thanks to `_set_quantity_done`, we can write these done quantities on
each SML (and then the incorrect lots will be replaced by the producing
lot).
OPW-2752436
closesodoo/odoo#89015
X-original-commit: 65efb3ec5416fab6bb9ba0a015565b2abb3928cd
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
In some cases, due to rounding errors, the state of a MO is incorrect
OPW-2753598
closesodoo/odoo#88964
X-original-commit: d349743c99e042ecd798aa2079695339cc9e80c5
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce the bug:
- Create the workcenter_1:
- Time Efficiency: 100%
- Capacity: 2
- Setup Time: 1
- Cleanup Time: 1
- Create the workcenter_2:
- Time Efficiency: 100%
- Capacity: 4
- Setup Time: 10
- Cleanup Time: 5
- Alternative Work centers: workcenter_1
- Create a storable product “P1” with BOM:
- Add any product as component
- Add operation:
- Duration: 60
- Work center: Workcenter_2
- Create a MO:
- select “P1” as Product
- Qty to produce: 4
- Confirm and Plan
Problem:
The workcenter_1 is chosen while work_center_2 is faster it can manufacture the 4 units at the same time
while workcenter_1 must do two cycles
As the Time Efficiency = 100%, so:
Total duration = (Setup Time + Cleanup Time) + duration_by_unit * nb_cycle
Work_center_1 = (1 + 1) + 60 * 2 = 122
Work_center_2 = (10 + 5) + 60 = 75
The calculation is bad because we use the number of cycles necessary for the work_center defined in the BOM
in the calculation for the alternative work center
opw-2821749
closesodoo/odoo#88945
X-original-commit: deb87a6abf8b8ccc4328eaac21430eedc2536361
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@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>
Most of the extensions of `_name_get` are very similar and only want to
search for the given string in multiple fields.
A lot of extensions also don't take into account the negative operators.
Some implementations were also really outdated and needlessly
complicated.
closesodoo/odoo#86588
Related: odoo/enterprise#25608
Signed-off-by: Raphael Collet <rco@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>
If a warehouse is set to a route like default 3-steps, updating the MO's
quantity to produce won't update the outgoing picking from
post-production to stock.
Since the quantity is now changed in the following pickings, no need to
put a warning in those pickings for the quantity change as their moves
quantity were automatically updated.
Task-2797359
closesodoo/odoo#86572
Signed-off-by: Arnold Moyaux <arm@odoo.com>
When updating the quantity of a manufacturing order,if multiple steps
were related to to its components, the changes would not be propagated
to them as no procurements were made.
So if updating the quantity of a two-step MO, the quantities from its
components within the MO would be updated, but not the ones from the
related picking.
Task-2797359
Part-of: odoo/odoo#86572
Currently, when changing qty_producing on a MO, consumed number of each
component will always be updated. In this commit, we add a new boolean
field manual_consumption to bom.line. If checked, that line won't be
updated when changing qty_producing.
The same but invisible field manual_consumption is also added to each
line on MO. It will use the value on BOM as defualt value. When user
manually set the consued qty, it will be checked automatically. Also,
when user manually update the SML, the field on SM will also be set to
true.
Task-2687494
closesodoo/odoo#80118
Related: odoo/enterprise#25607
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit, production created via `_run_manufacture()` without
bom or with a bom without component, will not be confirmed because of b4fd050e20c1
closesodoo/odoo#87412
Task: 2802652
X-original-commit: 27a651f01fa5868295d2dafa7d4e03ce896e64c9
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
Purpose
=======
Pictures from the digest emails are currently stored on the database
itself, meaning that if the database expires (e.g. after trial expires) all
pictures from previously sent emails won't be visible.
This is an issue since digest tips are meant as a marketing tool to bring
people to Odoo after trying a database.
Digest pictures are now taken from Odoo's server
(https://download.odoocdn.com/digests) so that the pictures will still
be visible after the database has expired.
From this commit onwards, it should not be allowed to change a digest
picture with the same name (to display a gif of a newer version), since
all databases with previous versions would receive pictures of a version
that does not correspond to theirs.
This also means that everyone client's Odoo server will contain pictures
that are never used. This could be fixed if Odoo stored them somewhere
else and didn't make them dependent from the git repository.
Task-2372195
closesodoo/odoo#87343
X-original-commit: 35157677a2a63a2559a72aff21e62e23a3c671a2
Related: odoo/enterprise#25654
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
No longer show the reserved column from by-products production registration on an MO.
Task ID: 2797692
closesodoo/odoo#87225
Pr: https://github.com/odoo/odoo/pull/86768
X-original-commit: 7aa08fe325490bf6ca5efe8b9b7be4bcae843826
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”
- Add a BOM
- Try to add the product P1 as a component > save > validation error is triggered
> it's not possible to add the same component as the product to produce > correct behavior
- Create a manufacturing order:
- Select the product “P1” as product to produce
- Add the product “P1” as component
- save
Problem:
no validation error is triggered, It's possible to create a MO in which the final product is included in the component > wrong behavior
opw-2796750
closesodoo/odoo#87262
X-original-commit: f38727ee4e7b6596a9da5f3285c7622da0ac6772
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce the issue:
- create product P
- create a Engineering Change ders ECO in PLM app
- attach documents to ECO and apply changements
Bug:
- go to the product, try to open uploaded documents. they are not found
This bug happened since odoo/odoo@114b71f
opw:2762448
closesodoo/odoo#87176
X-original-commit: 779a0df6732db51af652d6c282490187d11244a1
Signed-off-by: Simon Goffin <sig@odoo.com>
Co-authored-by: mart-e <mat@odoo.com>
Current behavior:
When using a product kit that have a product kit in his BoM some move line where merging when they shouldn't.
Because of this the delivered count wasn't correctly updated in any sale order using this product
Steps to reproduce:
- Create product B to manufacture with a BoM (type Kit) using component A and component B
- Create product A to manufacture with a BoM (type Kit) using product B and component A
- Create a sale order with product A
- Confirm the sale order and validate the delivery
- The delivered count of product A on the sale order stays at 0
opw-2777810
closesodoo/odoo#87000
X-original-commit: 0e6480811e2144a1034f1347a816a0bd052c4516
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
When changing the structure of a kit, it lead to undesirable behaviors
on Odoo
Issue 01:
1. Create 3 products P_kit, P_compo01, P_compo02
- Type: Storable
- Category: PC
2. Create a bill of materials:
- Product: P_kit
- Type: Kit
- Components:
- 1 x P_compo01
3. Create a purchase order PO with 2 x P_kit
4. Confirm PO and process the receipt
5. Edit the bill of materials of P_kit:
- Add 1 x P_compo02 in components
6. Return 1 x P_compo01
7. Go back to the PO
Error: The received quantity is 0 while it should be 1.0
When processing the return, the received quantity is recomputed, which
lead to:
https://github.com/odoo/odoo/blob/59fcb31f5a0b8136dae26b70ca0087f9b5cf3d24/addons/purchase_mrp/models/purchase_mrp.py#L29
However, since in the mean time the user added a new line in the BoM,
`_compute_kit_quantities` doesn't find any associated SM
(`bom_line_moves` is empty in [3]) and thus returns 0.
Issue 02:
(Need account_accountant. Use demo data)
1. Create a product category PC:
- Costing Method: AVCO
- Inventory Valuation: Automated
- Set up the Price Difference Account
2. Create 3 products P_kit, P_compo01, P_compo02
- Type: Storable
- Category: PC
3. Create a bill of materials:
- Product: P_kit
- Type: Kit
- Components:
- 1 x P_compo01
4. Create a purchase order PO with 1 x P_kit
5. Confirm PO and process the receipt
6. Edit the bill of materials of P_kit:
- Add 1 x P_compo02 in components
7. Create and Post the bill
Error: an Odoo Error is raised "ZeroDivisionError: float division by
zero"
While confirming the bill, some anglo saxo lines are generated. To do
so, the valuation of the kit is computed: [1]. In the above case, it
will lead to [2]. However, since in the mean time the user added a new
line in the BoM, `_compute_kit_quantities` doesn't find any associated
SM (`bom_line_moves` is empty in [3]) and thus returns 0. Back to [1],
the quantity is used to divide the total price -> it will raise an error
if this quantity is zero
Suggestion:
Such situations should not happen: once a product is used at least once,
it should not become a kit nor have a new structure (if it was already a
kit). Otherwise, `_compute_kit_quantities` will not correctly work since
it is not possible to take the BoM changes into consideration.
[1]
https://github.com/odoo/odoo/blob/abfe37fcea5b20f77799d9331d4d011530880669/addons/purchase_stock/models/account_invoice.py#L72-L74
[2]
https://github.com/odoo/odoo/blob/75191404788ab83645ee35b779991ea6fcdfa406/addons/purchase_mrp/models/stock_move.py#L19
[3]
https://github.com/odoo/odoo/blob/7d1af314320547ab5e37c1d97cad22992c98565b/addons/mrp/models/stock_move.py#L275-L294
OPW-2780855
closesodoo/odoo#86821
X-original-commit: 33fa43f795798276fa9d29dd0810289cbb1a2a9c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
To reproduce:
1. create a BOM with analytic account
2. create a MO to produce 10 of the above product
3. change producing qty to 5, SAVE the form.
4. change producing qty to 10, SAVE the form.
It happens because the server receive at the same time a new
`stock.move.line` creation and a quantity_done to write on the
`stock.move`.
closesodoo/odoo#86431
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Workorder _action_confirm works in batch and is designed to
link workorders and moves per production.
Original code breaks the 'per production' constraint by linking
moves from all productions to workorders of the last one when
called on workorders from multiple productions.
closesodoo/odoo#86698
Task: 2797201
X-original-commit: b25f1e005987641a208de30162808005ad6e705a
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Current behavior:
When you use a workcenter with start and stop time in a BoM the start/stop time is applied for each quantity in the BoM report and workorder. For example if you have 3 quantities the start/stop time
will be applied 3 times.
Steps to reproduce:
- Create a product to manufacture (With atleast 1 operation)
- Create a workcenter that has positive Start/Stop time values
- Start and stop time are multiplied by the quantity in the BoM report
opw-2779381
closesodoo/odoo#86321
X-original-commit: 3bb32903f90fa86eb28b4551b07a5817f8e9f528
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@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>
Re-integrate code from 37681e9d2e24663691b4be022f34c29c7126d9f6
lost with f11fcf6bb4
allowing different quantities to be recorded on work orders
and generate back orders with correct quantities on back work orders
(cancelled if no remaining quantity).
closesodoo/odoo#84502
Task: 2751230
Related: odoo/enterprise#24624
Signed-off-by: Steve Van Essche <svs@odoo.com>
Steps to reproduce the bug:
Go to a work order that is ready or waiting, try manually changing the scheduled start or end date > save
Problem:
Traceback is triggered because when we modify the date, we check if the start date is before the end date. But we cannot compare a False with a date
opw-2768054
closesodoo/odoo#85991
X-original-commit: 1768a072fd40d14dc8c402c3ccad9a6733460c03
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
To reproduce the issue:
1. Storable product with MTO and manufacture route
2. On your warehouse set 3 steps manufacture
3. Create and Confirm a SO for this product
Error: The smart button linking the Manufacturing order does not appear
on the MO.
Problem was introduced by [1] and fixed by [2,3]. Moreover, [1] wasn't
deployed on versions >14.0 so there was no need for [2] on these
versions ([3] has been merged on all versions). However, [1] have
recently been deployed on next versions ([4]) so we need to FW [2] too
without disturbing the improvements from [3].
[1] 7ab0ac3e56949e5015bb2dcfd2af34b56dee92c8
[2] 96b56ea350c283d824468c591d42e4aeeada0d69
[3] 475e6b3cb027b3127b8e46fd8c9f90abc35162d7
[4] 7d7976a61d0af41ebb4df2e24ba222f6570f689c
OPW-2778883
closesodoo/odoo#85676
X-original-commit: 8ce61133af600ffec4c43033e64c2460366856ce
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Co-authored-by: Arnold Moyaux <arm@odoo.com>
Co-authored-by: Grazioso Andrea (agr) <agr@odoo.com>
Co-authored-by: Adrien Widart <awt@odoo.com>
ISSUE 01
When adding a product to a sale delivery, another picking is generated
to return the additional product
To reproduce the issue:
1. Create two consumable products P01 and P02
2. Create and confirm a SO with 1 x P01
3. Add 1 x P02 to the delivery and validate it
4. Go back to the SO
Error: Another picking has been generated, it's a return for P02. This
picking should not exist.
When validating the picking, because of the new line, a sale order line
is created with a quantity equal to 0. During the SOL creation,
`_action_launch_stock_rule` is called and checks if a procurement must
be created and processed. To do so, it checks if the SOL quantity (0 in
our case) is the same than the procurement quantity (1 in our case):
https://github.com/odoo/odoo/blob/6a0cbff92141961655a5f3e33abc23a2c5b1045d/addons/sale_stock/models/sale_order.py#L543-L549
Since the values are not the same, a procurement is created and
processed.
The feature that updates the SO when adding some products to the picking
has been introduced by 1f0835a9d01b46b5cc617756f854c25541b644a7 and is
correctly working in 14.0 because the condition (in
`_action_launch_stock_rule`) is not the same:
https://github.com/odoo/odoo/blob/ec5475ee881c5ca2bcc992592bfa4edf12f492df/addons/sale_stock/models/sale_order.py#L572-L574
In 14.0, we check if the SOL quantity is greater than the procurement
quantity. The condition has changed in 15.0 due to a new feature
(bda3225c6cc27bb2c2933eda3cc68c6f9708daf3).
ISSUE 02
When delivering more than sold, a useless SM is generated.
To reproduce the issue:
1. Create a consumable product P
2. Create and Confirm a SO with 3 x P
3. Deliver 5 x P
Error: A new line appears (Demand: 2, Done: 0)
Because the delivered quantity is more than expected, an extra move is
created. Then, the extra_move is merged into the initial one a condition
is respected:
https://github.com/odoo/odoo/blob/6f2ba1e1b40a458e23c8ed712927c44d75d86614/addons/stock/models/stock_move.py#L1603-L1610
Here is the issue: the field `date_dealine` is not copied anymore (see
[1]). Therefore, the condition will never be respected
[1] fb781dcf57
OPW-2716309
closesodoo/odoo#85649
X-original-commit: fabc32c4733bb404e74dc111d80aa1fe1edd4bfb
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@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>
Steps to reproduce the bug:
- Go to inventory > configuration > Operation types > Manufacturing
- Set "Reservation Method" to "Manually”
- Create a storable product “A”:
- Update on-hand quantity to 10
- Create a storable product “B”:
- Create a bill of materials and add the product B as component
- Create and confirm a MO with 2 * product B
- Product A is not reserved for this MO (works as expected)
- Validate the production of 1 unit and create a backorder
Problem:
product A is reserved for the backorder because there is no verification of the reservation method before assigning it.
Solution:
No need to assign here, because when an MO is confirmed, move_raw/move_finished are confirmed too: https://github.com/odoo/odoo/blob/89ddaa49b901787f58a3fa9efb4115d5f2038611/addons/mrp/models/mrp_production.py#L1172
And when a stock_move is confirmed, it is assigned or not by checking the reservation_method:
https://github.com/odoo/odoo/blob/dda9700d8236091626cbd78efc0ca4116e1e1acd/addons/stock/models/stock_move.py#L1239-L1245
opw-2744513
closesodoo/odoo#85508
X-original-commit: 5926bb178236a74999a7868f0acf4ee86b61d7b8
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
When unbuilding a MO, if the latter has several lines (in its
components) for the same tracked product, it won't work.
To reproduce the issue:
1. Create two storable products P_compo and P_finished
- P_compo is tracked by USN
2. Update P_compo's quantity to 2
3. Create a MO:
- Product: Finished
- Quantity: 1
- Components:
- 1 x P_compo
- 1 x P_compo
4. Process the MO
5. Unbuild the MO
Error: a validation error is displayed while it should not "The serial
number has already been assigned: Product: P_Compo, Serial Number: C01"
The for-loop in `action_unbuild` do not handle the case where there are
several SMs for the same product. In the above case, there are two
component lines for P_compo, so there are two SM in `MO.move_raw_ids`.
When unbuilding the MO, the module creates and processes two SMs (SM01,
SM02) that "produce" two P_compo (stored in `produce_moves`).
When processing the first one in the for-loop, it takes the original
moves (so the `MO.move_raw_ids` with the same product) and uses them one
by one. Since SM01 needs one P_compo, it uses the first SM of
`MO.move_raw_ids` (and reuse the lot of that SM). Later on, when
processing SM02 in the for-loop, it does exactly the same thing: it
takes the original moves and uses the first one. Here is the issue: this
first SM has already been used and so does its lot, so this SM should
actually not be used again.
OPW-2715155
closesodoo/odoo#85354
X-original-commit: 8d2597965202a76ddeea8d8fed60b7ac014e2df8
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Fine tuning of commit 6acfb2e
It correctly merge the purchase.order in case of direct link and
avoid to relaunch the procurement.
It also correctly set the created_production_id if the demand come
from a SO
closesodoo/odoo#85301
X-original-commit: 9b6fa6c3db55daa3533c0d5cb13da7c98fc3e936
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Usecase:
- Create a BoM with a product tracked by SN
- Create a MO with qty 5
- Mass produce
- Generate
-> All the `stock.move.line` in the move_raw_ids don't have
the qty done prefilled. The purpose of the feature is to create
and validate a lot of MO at once. Which is impossible if you have
to fill all the quantity manualy.
The choice of a new kwargs that directly set the qty_done is justified
by the performance.
-> For On a BoM with 10 components for a final product. For 1000 finished
product with SN
- If we do a loop on each `stock.move.line` to set
qty_done as the reserved quantity. It goes from 40s to 135s
- With the kwargs. It remaines 40s
closesodoo/odoo#83123
X-original-commit: 8ce5926b5a337dc97237f39492e094288b453743
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
*: mail, mrp
Previously, to prevent images and iframes from making GET requests in
tests, we would listen for the DOMNodeInserted event. This event is
deprecated and should not be used. Additionally, we weren't listening
for attiribute changes for performance reasons, which would result in
some GET requests still being made when an src attribute was changed.
This commit changes the mechanism that is used to do this from mutation
events to a MutationObserver which is not deprecated, and now also
listens for attribute modifications as MutationObservers can be
configured to only listen for changes to certain attributes, greatly
alleviating the performance impact of listening for those.
This mechanism has also been enabled globally by doing it once in the
test setup code, instead of requiring one to call a specific helper, as
we never want to make real requests during tests.
Some tests have been adapted to this new behaviour.
closesodoo/odoo#85216
Related: odoo/enterprise#24665
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Set the warehouse with manufacturing 3 steps
Create a BoM with a Components that use a Sub BoM
Set Both product MTO + Manufacture
Create a MO
You have only 2 picking for the first MO with the SFP
that contains both the finished product and the intermediate
component. However they are created and moved at two different times
since you could not create the finished product withtout the
component, so there is no meaning to put them both in the same picking.
It happens because the _assign_picking will merge moves with the same
procurement group. In our case, it's the wanted behavior to have the
2 differents SFP linked to the same MO.
The idea between the fix is:
- We want to have the pick components picking merged.
- We want to have the store components split since they come from
different MO
So we create the different procurement groups during the _run_pull with
the picking type of store finished product. This way the pickings won't
be merged during _assign_picking
We will also propagate those groups to the newly created MO in order to
keep the picking type sequence and correct name.
FW PORT of
https://github.com/odoo/odoo/commit/bcfa03821b92bf52675db0e3b54d3cb19dfe3087
opw-2585525
closesodoo/odoo#85195
X-original-commit: a647e680a196f7e6d9147d51dd80f8c31e0e741b
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce the bug:
- Go to inventory > configuration > Products > Attributes
- Create a new Dynamic Attributes > add two attribute values
- Create a storable Product “Test”:
- Add the two attributes
- Save
- Create a BOM related to this product
- Create a new manufacturing order:
- Do not choose a product
- Select the BOM related to the product “test”
Problem:
Traceback is triggered because as the product template only has dynamic variants, there is not a `product.product` record created yet.
but we try to access it in the onchange: https://github.com/odoo/odoo/blob/14.0/addons/mrp/models/mrp_production.py#L598
Solution:
do not set the product when a BOM of a product_tmpl without a variant was chosen
opw-2732254
closesodoo/odoo#84543
X-original-commit: 50b538e7d32bbce7cad7c05f0bc80db6b969a70b
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce:
- Create + confirm a MO
- Add a byproduct with a Produced (qty) > 1
- Change the `qty_producing` to a non-zero qty
Expected result:
Byproduct's "Produced" qty stays unchanged and its "To Produce" is 0
Actual result:
Byproduct's "To Produce" defaults to 1 and its "Produced" qty is
updated to scale to the according to the amount `qty_producing` (i.e.
if `product_qty` = 2 and `qty_producing` = 1, then by-product's
"Produced" = .5
Additionally, a Missing Record error pops up because of missing
stock.move.line
Solution, don't allow byproducts added after MO is confirmed to default
to 0. Additionally allow byproducts to have 0 "To Produce" quantity and
don't sum the cost share of merged byproduct moves since when Produced
> To Produce then an extra move is created and the cost share ends up
being doubled during the merge.
closesodoo/odoo#85130
Task: 2716164
X-original-commit: 51ff14a56b909bdf22c9f1c4540347655578e1f4
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
When creating a MO _date_planned_finished_ is not added.
Consequently calculates wrongly the date planned to finish the MO.
X-original-commit: 2b2509e154af0e58a3f30f1d7fe40fb854b6b881
Part-of: odoo/odoo#84896
Rewrite _post_inventory to make it work better
with mo batches. This mainly improves the
time it takes to mark_as_done manufacturing
orders from the Workorders ListView.
stock.move._action_done is faster
when called outside of a for loop, i.e.
directly on self.
opw-2760394
closesodoo/odoo#84846
X-original-commit: 4cc6083ea1bd28be07e275322481ad11d8995d58
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When printing a delivery slip, if the delivered product is a kit
composed with a subkit, the products of this subkit won't be listed
To reproduced the issue:
1. Create 5 consumable products: 'Compo 01', 'Compo 02', 'Compo 03',
'Sub Kit', 'Super Kit'
2. Create two phantom-type boms:
- Sub kit:
- 1 x Compo 02
- 1 x Compo 03
- Super Kit:
- 1 x Compo 01
- 1 x Sub Kit
3. Process a delivery with 1 x Super Kit (the picking must be done)
4. Print the delivery slip
Error: The report only contains two lines, i.e. the name of the kit
('Super Kit') and the name of the 'direct' component ('Compo 01)
The issue comes from the SML used to define `kit_move_lines` (XML side).
It uses `has_kits` which only contains the top level kits' SML:
https://github.com/odoo/odoo/blob/1b1067b0cf2a3de2773915ff8205084492b1bbe3/addons/mrp/report/report_deliveryslip.xml#L6-L9
This is the reason why the SML for Compo 02 and Compo 03 are not listed
OPW-2740247
closesodoo/odoo#84735
X-original-commit: 586f900433eb09ee04d0ed073acfdcfa0fc59d58
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@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>
Adrien Widart