Currently MRP only allows sequential scheduling of work orders.
This commit allows to specify the dependencies for work orders to be
scheduled in parallel or in a complex diagram.
By enabling the feature in the settings and at the bom level,
you can specify dependencies between operations:
on the operation form, select the operations on which the
current one depends.
The dependencies will be reflected in work orders during planning.
The workorders Gantt view has been adapted for you to visualize
and manipulate the dependencies.
Please note:
- work orders without predecessors will be started first
- they can all be done in parallel
- when all work orders of this step are finished, their successors
will start
- and so on, step by step
Also, with the feature activated at the bom level and no dependency,
the parallel scheme will be applied (all operations at first step).
Finally, without activation at the bom level, the dependencies will
be created in order to satisfy the current sequential model.
Task: 2691328
Part-of: odoo/odoo#87131
Steps to reproduce the product:
- Enable “Work Orders” option in MRP settings
- Create a storable product “P1” with BOM:
- BOM type: Manufacture this product
- operations: “OP1”
- Components: product “C1” consumed in the operation “OP1
- Create an ECO for “P1”:
- Type: New Product Introduction
- Apply on; Bill Of materials
- Click on “Start Revision”
Problem:
A BOM change will be created for the component “C1” where it will be added and removed.
When creating an ECO, a copy of the original BOM will be created,
and then we compare the BOM lines of the two BOMs if they are identical (product, qty and operation)
but as the operation has been duplicated therefore created with a different ID,
the two lines will not be identical and a distorted change in the BOM will be detected
Solution:
It is better to compare the fields of the operations instead of their ID to detect if a change has been made in the BOM
opw-2823253
opw-2809586
opw-2833083
closesodoo/odoo#92670
X-original-commit: 5c16aa22c70f8a0a377a55b912307ab07222c643
Related: odoo/enterprise#27943
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When manfacture in 2 steps is setup on warehouse, transfers are created
when confirming an MO, manual moves added did not have a warehouse and thus not
included in the picking. The default warehouse is set to the source location
warehouse in MO.
closesodoo/odoo#91879
Related: odoo/enterprise#27577
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>
following commit 55398263f9297ab2709e4c4c2a9c6c3ee7f59c8a
Introduce a new param to fix a notification issue. However
we could use the context instead of a new parameter in order
to avoid breaking the customisation.
Linked to PR #88303 discussion
closesodoo/odoo#92353
X-original-commit: 69dcdd410adcefe29bfa4fecd2e7c50fe3465b19
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When clicking order now on a replenishment line (orderpoint) for a manufacture or WH resupply route, it will sometimes show a notification for a purchase order that was created earlier instead of the correct one.
closesodoo/odoo#91404
X-original-commit: 9ca9bcc51fa289ddb0548f81a795755d196e31ca
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Bug fixed where when the MRP subcontracting module was installed the merging of MO's would not open the MO form view.
Correctly displays the breadcrumbs as well.
Task: 2799674
Community PR: https://github.com/odoo/odoo/pull/88801
Part-of: odoo/odoo#88801
# Issue:
With User1, create a MO with work orders, and start one Work Order.
With User2, go to the MO, and start the same Work Order
=> Nothing happen, we currently prevent the workorders to have more than 1 open Time Tracking.
OPW-2845080
closesodoo/odoo#91123
X-original-commit: 8cb5aad6126e3f63ee4ef91115c8b4a6be571828
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: DavidFesquet <dafr@odoo.com>
When updating the MO quantity, the reservation of the components doesn't
respect the reservation method of the operation type.
To reproduce the issue:
(Use demo data)
1. Edit the operation type "Manufacturing":
- Reservation Method: Manually
2. Create and confirm a MO for 1 x [FURN_8855] Drawer
- Note: the components are not reserved, as expected
3. Update the quantity to produce (2 x Drawer)
Error: The components are reserved
The new conditions are directly based on the conditions to reserve a SM
when confirming it:
https://github.com/odoo/odoo/blob/e55988fc4d8090f84157a026b7ecc7ea0dc146a7/addons/stock/models/stock_move.py#L1242-L1248
OPW-2822205
closesodoo/odoo#90728
X-original-commit: 76168d0f95203c97e60955c2df396b3bb81aa4f3
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce the bug:
- Create a MO with work orders
- Confirm the MO
- Under the tab Work Orders > click on the button start multiple times quickly
Problem:
Several `mrp.workcentre.productivity` are created for the work order,
whereas normally the workorder can have only one timer started (without date_end).
Solution:
- If the workorder already has a timer running, return true to stop the process
- Add a constraint to block the user when he tries for example to create with an rpc call several `mrp.workcenter.productivity`
without an end date for the same workoder
opw-2802436
closesodoo/odoo#90094
X-original-commit: dd22195a75ec437e42424ee95ca9a41feeb48b0b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Adapt db775ffd308638a390be52eba3ca11c9c2d1602d to subcontracting flow,
to avoid performance issues when receiving a large amount of SNs
closesodoo/odoo#85603
Task: 2777451
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Current behavior:
When using 2 steps delivery and selling a kit product, not all
moves had bom_line_id set. So if you go in the transfers you
couldn't always see the "Kit" column in the operations.
Steps to reproduce:
- Activate 2 steps delivery
- Create a Kit with 2 products
- Create a quotation with kit and confirm it
- Go in the delivery
- In WH/Pick you can't see Kit column
- In WH/Out you can see the Kit column
opw-2796974
closesodoo/odoo#89371
X-original-commit: 88c3c3f49393af08e4070c0d2f5cccbec9096c1f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Impacted versions: 15.0
Steps to reproduce (starting from ENTERPRISE 15.2):
- enable Work Orders
- create new BoM for a new product
- add 1 operation w/ 1 step (e.g. Instructions)
- add 1 component to BoM with operation_id (Consumed in Operation) = the operation
- Create and confirm a MO with new BoM + 2 Quantity to Produce
- Produce 1 product via the tablet view flow (i.e. complete instruction step + Validate 1 component in "Register Consumed Materials" step + Mark As Done)
Current behaviour:
Backorder is correctly created, but its workorder is missing the "Register Consumed Materials" step
Expected behaviour:
Step is correctly created
Note: same issue occurs with Byproducts having an operation_id (i.e. "Produced in Operation")
Issue is due to when _split_productions() first creates the backorders, they are created without move_raw_ids and move_finished_ids (see: _get_backorder_mo_vals()). When the backorders are created, they auto-create and auto-confirm their workorders. Since a quality point (e.g. operation step) exists for the workorder, the initial _action_confirm will _create_checks() for the quality point, but the "Register Consumed Materials" steps are created by the operation_id values in the move_raw_ids and move_finished_ids which haven't been set yet. This makes it so when the second _action_confirm() is called on the workorders (i.e. after their moves have been set) at the end of _split_productions(), the _create_checks() will be skipped because it assumes all the quality points have been created since one already exists.
Task: 2800975
Community PR: https://github.com/odoo/odoo/pull/87681
Enterprise PR: https://github.com/odoo/enterprise/pull/26437closesodoo/odoo#89486
X-original-commit: 67524eb948b7e122f33abf344b28b59bd81eb88d
Related: odoo/enterprise#26534
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce the bug:
- Create a manufacturing order to produce “Table”
- Confirm and plan the MO
- Start the work order
- Cancel the MO
Problem:
- The work order is cancelled, but the timers continue to run.
- "Block", "Unblock" and “Unplan" button should be hidden when MO is cancelled
opw-2817842
closesodoo/odoo#89442
X-original-commit: 5682015958d03f4a65969afe3fce9b9b05e5b505
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
This task will:
- Clean the code (e.g. the production's moves are now created directly)
- Have the same behavior when creating object in the UI or directly in
backend
It's mainly on the `mrp.production` object and most of the computed
stored field are used as default value or act like an onchange on draft
production. Once the production order is validated, it's only modify
by direct write
Task-2709753
closesodoo/odoo#83576
Related: odoo/enterprise#24405
Signed-off-by: Arnold Moyaux <arm@odoo.com>
This PR fix the "This attachment is already a document" Error when clicking on the "Apply Changes" button of a mrp.eco (Engineering Change Orders) in the PLM App.
With the Documents App installed and the "Product: Centralize files attached to products" document setting activated, copying the attachment will also copy the document.
Then when we try to copy the current document and link it to the new attachment, the above mentioned error appear.
The context no_document=True prevent the document copy during the attachment copy.
OPW-2762448
closesodoo/odoo#89324
X-original-commit: ed306afc0e812c1e42984f1b6cb94e61409f0144
Signed-off-by: Simon Goffin <sig@odoo.com>
Signed-off-by: DavidFesquet <dafr@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>
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
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>
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>
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>
JF Aubert