This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”:
- routes:
- MTO
- Manufacturing
- Create a SO:
- Select the product “P1”
- Confirm the SO
Problem:
The created MO is in confirmed state instead of draft.
This blocks the user, for example imagine that he has configured
the product with a first BOM without components and 2 others with
components. when the MO is created, the first bom will be selected,
and as the MO will be confirmed, the user will not be able to
select another BOM
Solution:
Since the MTO rule is not linked to an order point, we could be more
flexible, so the production created via `_run_manufacture()` without
bom or with a bom without component and operation via the MTO mechanism
will not be confirmed
opw-2897267
closesodoo/odoo#97099
X-original-commit: c623478aba040c0493e6da8a67c9742880572199
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
On the commit 69dcdd4, the order='create_date desc'
was removed and the way of getting the MO for the notification changed. Now, the context is used, it should be written_after instead of written_date.
(The MO created is correct, only the notification is wrong)
OPW-2877457
closesodoo/odoo#96856
X-original-commit: b80287b265a4c01babedcbb58459c35d36a48066
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Enable 'Multi-Step Routes' option in Inventory settings
- Edit warehouse and update Manufacture = 'Pick components, manufacture and then store products (3 steps)'
- Create a storable product 'P1' with BOM:
- BOM type: Manufacture this product
- operations: “OP1”
- Components: product 'C1' consumed in the operation 'OP1'
- Set Reordering rules for product 'P1'
- Run Scheduler and MO will be generated with order points
- Edit MO and add Producing Quantity less than to produce
- Validate the MO and create backorder.
Current behaviour:
- child/parent MO were getting visible when backorder was created in 2/3 Step Production.
Expected behaviour:
- No child/parent MO visible until child/parent relations are there
closesodoo/odoo#96533
Task: 2846768
X-original-commit: 14431b2497dcf4aaf778ef1b06e023101b00a4e2
Signed-off-by: Tiffany Chang <tic@odoo.com>
_split_productions wrongly compute duration expected for backorders.
Setting quantity on production adapt many things including workorders,
so adapt original production after copy_data for backorders.
closesodoo/odoo#96179
Task: 2884562
X-original-commit: 71b8531881ff6924762ec34db3f2ddf858383218
Signed-off-by: Tiffany Chang <tic@odoo.com>
When creating a new manufacturing order with `move_finished_ids`
passed in the values, but `byproduct_id` is not amongst the move values,
the creation of the manufacturing crashed.
```
File "/home/odoo/src/odoo/master/addons/mrp/models/mrp_production.py", line 811, in create
vals['move_finished_ids'] = list(filter(lambda move: move[2]['byproduct_id'] is False, vals['move_finished_ids']))
File "/home/odoo/src/odoo/master/addons/mrp/models/mrp_production.py", line 811, in <lambda>
vals['move_finished_ids'] = list(filter(lambda move: move[2]['byproduct_id'] is False, vals['move_finished_ids']))
KeyError: 'byproduct_id'
```
By reading the implementation of the byproduct moves field:
```py
@api.depends('move_finished_ids')
def _compute_move_byproduct_ids(self):
for order in self:
order.move_byproduct_ids = order.move_finished_ids.filtered(lambda m: m.product_id != order.product_id)
```
it seems a better implementation to filter the move on the fact their
product is different than the manufacturing order to determine whether
they are byproduct or finished product moves.
Take the opportunity to write a unit test testing the tricky behavior
of the create override when both `move_finished_ids` and `move_byproduct_ids`
are passed in the create values.
This is related to revision
odoo/odoo@6c087f2043closesodoo/odoo#96044
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”
- Tracking: by serial number
- BOM:
- Component: C1
- Create a storable product “P2”
- BOM:
- Component: P1
- Create a MO to produce one unit of P1:
- serial number: SN1
- Confirm and mark as done
- Unbuild the manufactured product
- Manufacture the same product using the same serial number again
- Create a new MO to produce one unit of “P2”:
- Component P1 → select SN1
- Try to confirm and validate the MO
Problem:
Get User Error: The serial number “SN1” used for component “P1”
has already been consumed
We do a search in the `stock.move.line` to find if the SN has already
been used in a previous MO, but there is no specific condition to get
only those used in an MO so the unbuild order is in the same condition
and therefore the SN is considered as it has already been used
opw-2883450
closesodoo/odoo#95935
X-original-commit: 5ac7f4d6fa5551ba7c6da49a52edf0a7df2d0745
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Stpes to reproduce the bug:
- Create a storable product “P1”:
- tracking: Serial number
- BOM: 1 unit of C1
- Create the MO 1:
- produce 1 unit of P1:
- Create the SN1
- Create the MO 2:
- produce 1 unit of P1:
- Create the SN2
- Create an Unbuild order:
- Select the MO1
Problem:
You have the possibility to select any Serial number linked
to the product “P1”, whereas only SNs created in this MO can be selected
opw-2834529
closesodoo/odoo#95956
X-original-commit: 167b1668450c5af44bc1d36d1c7d59921bc2b811
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
This allows to create a mrp.unbuild record without
the need to call the onchanges to set the uom and locations
or to set them manually during the `create` call.
For instance, this makes easier to create unbuild orders
using XMLRPC when you do not use multiple UOMs or multiple locations.
closesodoo/odoo#95557
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
With this revision, the expected duration is correctly set
when creating a production order with work orders without the need of
onchanges, through a form.
For instance, this allows an easier implementation to create a production
order with work orders through XMLRPC API calls,
as you will not need to manually set the expected duration value
or to call onchanges manually to set it.
For instance, without this change to remove the `default=60.0`,
the part added by this revision in the test `test_update_quantity_3`
would fail
```
2022-07-11 09:15:14,644 21 ERROR master odoo.addons.mrp.tests.test_order: FAIL: TestMrpOrder.test_update_quantity_3
Traceback (most recent call last):
File "/home/odoo/src/odoo/master/addons/mrp/tests/test_order.py", line 347, in test_update_quantity_3
self.assertEqual(production.workorder_ids.duration_expected, 90)
AssertionError: 60.0 != 90
```
while it just does the same thing than the existing `test_update_quantity_3` test
but without the use of a form / onchanges.
Part-of: odoo/odoo#95733
This allows to create a production order record without
the need to call the onchanges to set the product, uom or bom
or to set them manually during the `create` call.
For instance, this makes easier to create production orders
using XMLRPC when you do not use multiple UOMs.
closesodoo/odoo#95544
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Convert the onchange on `product_id` to a compute field
This allows to create a `mrp.bom.byproduct` record without
the need to specify the uom during the creation nor calling the onchange
method. The uom defaults from the product uom.
This way, if the database is not configured to use multi UOMs,
the users do not have the specify the UOM to use.
For instance during an XMLRPC call to create a byproduct.
closesodoo/odoo#95270
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Purpose of this commit to fix the UI in Manufacture app.
So, in this commit done following changes As suggested in Task:
- Able to expand next activity column of MO list view
- Added tooltip of default capacity field on work center
- Added quantity tooltip of BOM
TaskID - 2689994
closesodoo/odoo#95315
X-original-commit: 463a81eb325f624e8947f1b3444947f8ba1dc24b
Related: odoo/enterprise#29113
Signed-off-by: Tiffany Chang <tic@odoo.com>
Now the way of access to an action is using the method `_for_xml_id` of
the model `ir.actions.actions` and not reading the action itself because
they need the access of the group "Administration/Settings" which not
all the users have it, so we were having an error with users that have
the permissions to see MRP Picking Types but they didn't have the group
mentioned above.
closesodoo/odoo#95312
X-original-commit: 1554fc9f8a98f4723b4f3cc1a8c0bd772c317ce5
Signed-off-by: Tiffany Chang <tic@odoo.com>
In some cases, replanning a work order does not change anything.
To reproduce the issue:
(Use demo data):
1. In Settings, enable "Work Orders"
2. Create two manufacturing orders (MO01, MO02) with 1 x [FURN_8522]
Table Top
3. Confirm MO01 and MO02
4. Set the same Scheduled Start Date (SSD) on the WO of each MO
- A warning should be displayed on the work order line because of
the conflict
5. Open the warning and click on "Replan"
Error: Nothing happens, the warning is still displayed and the scheduled
start date does not change.
For the warning symbol to be displayed, we check (through
`_compute_json_popover`) if two work orders are in conflict:
https://github.com/odoo/odoo/blob/8cb5aad6126e3f63ee4ef91115c8b4a6be571828/addons/mrp/models/mrp_workorder.py#L719-L722
So, we base this information on the `mrp.workorder`
However, the planning logic is based on another model:
`resource.calendar.leaves`. When planning a WO, we create a
`resource.calendar.leaves` and we link this slot to the WO thanks to the
field `leave_id`:
https://github.com/odoo/odoo/blob/4870606b00a758e63713e6e82c0cba9b1e7dd4aa/addons/mrp/models/mrp_production.py#L1238-L1248
Therefore, when replanning a WO, we ensure that the new slot does not
overlap any existing slot in the same workcenter. But, here is the
issue: when writing the start date (step 4), we try to replan the WO of
the MO only if this MO is already planned:
https://github.com/odoo/odoo/blob/4870606b00a758e63713e6e82c0cba9b1e7dd4aa/addons/mrp/models/mrp_production.py#L723-L724
Wich is not the case in the above steps. So, we don't (re)plan anything
=> we don't create any slot.
As a result: the warnings are displayed, which is correct, but when
trying to replan one of the WO (step 5, viathanks to
`_plan_workorders`): There isn't any slot starting from WO's start date
(there isn't any slot at all!), so we can create a new slot -> the start
time of the WO does not change -> considering their start times, there
is still a conflict between both WOs.
Comment: if after the step 5, the user tries to replan the other WO, it
will work: the first replanning fails but a slot has still been created.
Therefore, when replanning the second WO, the newly-created slot will be
detected, a second slot will be created after the first one and the
start date of the second WO will be postpone (according to the second
slot).
(!) Note that nothing creates any slot if we directly define the start
time of the WO during the MO creation (step 2). So this use case will
fail too.
We should ensure a perfect coherence between both models
`resource.calendar.leaves` and `mrp.workorder`.
OPW-2887413
closesodoo/odoo#95087
X-original-commit: 9d4d8d24792933e53a4ca422ccedde8ddc93cdf4
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
It could happen that there are other objects than stock.move linked to
the manufacture order. This is currently creating an error when
concatenating the objects. As we are only keeping stock.move objects to
log the exception on those, we should filter them before the concatenate
operation to avoid the error.
closesodoo/odoo#94893
X-original-commit: 1cdb682163e24fc01677cdcd0e1b83592443fffc
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Alex Thuyls (alt) <alt@odoo.com>
Co-authored-by: vancleeff <mvw@odoo.com>
Settings user is not able to access Bill of Material (mrp.bom) records
unless they have additional groups (account, inventory, manufacturing, ...)
This commit makes sure the operation is done in sudo so that any setting user
is able to save the settings.
Part-of: odoo/odoo#91909
When unbuilding a product, the selected source location is not applied
on the SM.
To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create two storable products P_compo, P_finished
3. Update the qty of P_compo: 1 in WH/Stock
4. Create a BoM:
- Product: P_finished
- Components: 1 x P_compo
5. Process a manufacturing order MO with 1 x P_finished
6. Transfer the P_finished from WH/Stock to WH/Stock/Shelf 1
7. Create an unbuild order UO:
- Manufacturing Order: MO
- Source Location: WH/Stock/Shelf 1
- Destination Location: WH/Stock/Shelf 2
8. Confirm UO
9. Open the associated product moves
Error: The SML of P_finished is incorrect, its source location is
WH/Stock instead of WH/Stock/Shelf 1 (as a result, the quants are
incorrect too).
The issue only happens with P_finished. The destination of the
components is correctly defined:
https://github.com/odoo/odoo/blob/90a87d6ecd420c61ea8db8a6c571db477ee7220e/addons/mrp/models/mrp_unbuild.py#L229
(i.e., we use the destination location of the unbuild order)
OPW-2869454
closesodoo/odoo#94367
X-original-commit: 45ec5871a1ee6e3a31e790323f08df20715f4171
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When a MO is generated in order to supply another one, the smart buttons
"Source MO"/"Child MO" are still invisible.
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Enable MTO route
3. Edit the warehouse: 3-steps manufacturing
4. Create 3 stored products Super, Sub and Compo:
- Sub has two routes: MTO and Manufacture
5. Create two BoMs:
- For 1 x Super:
- 1 x Sub
- For 1 x Sub:
- 1 x Compo
6. Create and confirm a MO with 1 x Super
Error: On confirmation, a second MO is created to produce one Sub, which
is correct. However, neither the first MO nor the generated one has a
link with the other one (through the smart button "Source MO"/"Child
MO")
When confirming the MO, a SM is created to bring one Sub to the
pre-production location. Thanks to MTO route, this will generate another
SM that brings one Sub from post-production to stock location (this will
lead to the creation of the second MO). However, the other SM (1 x Sub
from Post to Stock) doesn't have the same procurement group. This is the
reason why it is not found by the `_compute` methods.
OPW-2730830
closesodoo/odoo#94334
X-original-commit: 81e5ce05f2f79eb19489f00fb867143189fb38df
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
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>
When creating a backorder for a manufacturing order, date_deadline for
its raw_moves are lost in the process, as the field is set to copy
False. But the split of a manufacturing order is not a usual copy paste.
In this specific case, we need to keep the date_deadline as well, or
resulting moves wouldn't be able to be merged with moves in
pre/post-production pickings from the original manufacturing order.
Task-2797359
X-original-commit: b50db19fa0da58dc0734c8cd494795743eaf0984
Part-of: odoo/odoo#93233
Since https://github.com/odoo/odoo/pull/86682, when a user opens
the replenishment view, the Days to Purchase are not taken into
consideration when calculating the forecast of a product.
This was due to the fact that the Days to Purchase are now taken from the
orderpoint and not from the company settings. This is fixed by taking
the company setting if no value from the orderpoint is sent to the
method.
closesodoo/odoo#93252
Task-id: 2871408
X-original-commit: ac1df1949e4523aff65543f1381300fc7de3b4e4
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: npi-odoo <npi@odoo.com>
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>
Nicolas Pierre