The scheduled end date of a work order is not consistent with its
scheduled start date when starting the work order
Steps to reproduce:
1. Install Manufacturing
2. Go to Settings > Manufacturing > Operations and enable Work Orders
3. Create a manufacturing order for any product, with any component and
a work order
4. Confirm and plan the MO
5. Edit the scheduled start date of the work order to the next working
day and save
6. Start the work order
7. The scheduled start date changes but the scheduled end date doesn't
Solution:
When starting a work order, change the `date_planned_finished` according
to the new `date_planned_start`
opw-3005767
closesodoo/odoo#105055
X-original-commit: 0edeed2ff07693933aaf1a17958b5c5fc9a65c35
Related: odoo/enterprise#33661
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
To reproduce the issue:
1. In Settings, enable UoM
2. Edit the UoM 'Dozens':
- Rounding: 1.0
3. Create two products P_finished, P_compo:
- P_finished:
- UoM: Dozens
4. Create a BoM:
- Product: P_finished
- Qty: 1 x Dozens
- Compo: 1 x P_compo
5. Create and confirm a MO for 1 x P_finished
6. Edit the MO:
- Set the producing qty to 1
- Set the 'to consume' quantity of P_compo to 1.23
Error: the consumed quantity of P_compo is still 1.0 (it should be
1.23). If the user tries to set the quantity to 1.56, the consumed
quantity will become 2 (also incorrect, should be 1.56)
The UoM used to round the new consumed quantity of the component is
incorrect. Considering its definition:
https://github.com/odoo/odoo/blob/0fdd35cfb5c7145b3a7a855956004e38de7c6e2a/addons/mrp/models/stock_move.py#L164-L170
the UoM of `unit_factor` is `UoM_sm / UoM_mo`. Therefore, in
`_update_quantity_done` (see diff), when we compute `new_qty`, we have
(in terms of UoM) `(UoM_mo - UoM_mo) * UoM_sm / UoM_mo`. So, the value
is already in the correct UoM (`UoM_sm`) and we just have to round it
based on that UoM
OPW-3016837
closesodoo/odoo#105059
X-original-commit: 90c245a3785a22c9fcbe7dcc2d06ae4205b4fdc9
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
The main motivation for this change is to improve performance of BoM
`explode`, which heavily rely on checking the lines to skip. `explode`
is also called from product `compute_quantities_dict` which is called
multiple times during upgrades. With this fix we improved the running
time of an upgrade _test_ from 3h:30m to 2h:55m which gives a 16%
performance improvement.
The goal of `_skip_bom_line` is to check that for each attribute present
on the line, at least one value associated to that attribute must be in
the attribute values of the product(*). If none is found then we
consider that we can skip the line.
The previous implementation was inefficient. It grouped all values by
attribute, then checked one by one if at least one value is on the
product. In case one attribute does not have any value on the product it
skipped the line.
The implementation we propose here is to take the intersection of the
product and line values, then check that their attributes are the same.
The later can be done with a simple length check. In case they are
different the line must be skipped. Note that this works because only
one value is possible per attribute in a product.
Both implementations are equivalent. The second is more efficient
because does not branch and relies on (record)set operations.
For example, let's consider a product with two attribute values
`a` and `b`, and a line with multiple values `a`,`y` for
attribute 1, and `z` for attribute 2.
```
Product Line
+---+ +-----+
| a | <- same attribute -> | a,y |
+---+ +-----+
| b | <- same attribute -> | z |
+---+ + ----+
```
This line must be skipped. The reason is that the value `b` is not
among the list `[z]` of values for attribute 2 on the line. The new
implementation would get the intersection of attribute values as `[a]`
from there the comparison of the attributes will fail because `[a]` has
only one attribute while the line has two.
Let's consider a second case, where there is no value on the line for
attribute 2.
```
Product Line
+---+ +-----+
| a | <- same attribute -> | a,y |
+---+ +-----+
| b | <- same attribute -> | |
+---+ + ----+
```
This line is not skipped because there is no value for attribute 2 on
the line. Therefore the condition(*) per attribute is not violated for
this product. The new implementation gets `[a]` as intersection of values,
but now the attributes coincide: they are both attribute 1 for the
intersection and the line.
Finally,
```
Product Line
+---+ +-----+
| a | <- same attribute -> | a,y |
+---+ +-----+
| | <- same attribute -> | z,w |
+---+ + ----+
```
This line is skipped because none of `[z,w]` are in the product. The new
implementation would get again `[a]` as intersection which does not
match the attributes on the line.
closesodoo/odoo#105019
X-original-commit: 47f4c3cc72ecb612ef4edd8c603e27b698187d8a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When executing the product2bom method it is possible that an active_test
context is present in self. However, the method should not consider
archived BoMs.
closesodoo/odoo#104919
X-original-commit: a5f923859fad37e1fc52a3a4bcce5cce4cf69c87
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When the mrp_routing_workcenter table is big, the domain
[routing_line_ids, =, []] in the workcenter FormView can
lead to significant slowness. This comes from
the ORM having to retrieve the mrp_routing_workcenter
records in the read.
To avoid such issue, adds a new boolean computed field
to check if a given workcenter has Operations.
opw-2954461
closesodoo/odoo#99313
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Computed stored fields should not be depending on context. In this
particular case, compute_bom_id will make a 'search' on mrp_bom table
with sometimes 'active_test=False' in the context sometimes not.
This commit force the context to exclude archive records to ensure we do
not set an archived bom on a production order.
In a futur versionm it would be nive to have the ORM ignoring the
context in such case.
closesodoo/odoo#103055
Task: 2991906
X-original-commit: 6274f23a673fe073157d0f975adcb2b0c917b02f
Related: odoo/enterprise#32700
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When writing a workorder start or end date from its manufacturing order
(and if the MO is unplanned), an error is thrown
Steps to reproduce:
1. Install Manufacturing
2. Go to Settings > Manufacturing > Operations and enable Work Orders
3. Open an MO with Work Orders
4. Unplan the MO
5. Add a Scheduled End Date to one of the Work Orders
6. Save
7. An error is thrown
Solution:
Compute the new duration only if both `start_date` and `end_date` are
set (and one of `date_planned_start` and `date_planned_finished` is
passed in values)
Problem:
When only one of `date_planned_start` or `date_planned_finished` is
written on an `mrp_workorder` (and the other is not set), the method
`_calculate_duration_expected` is called but it fails because it passes
a False value instead of a datetime which will raise the error `'bool'
object has no attribute 'tzinfo'`
opw-3004280
closesodoo/odoo#103927
X-original-commit: 35a596dbbc4e2e55461bf7e5e8ae12873249d4af
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Quantity done will be always editable. Different use case:
1. If there is not location/package/tracing/owner -> same behavior than
before
2. If the details are needed:
- Immediate transfer. In case of increase the quants are reserved and the
`qty_done` on `stock.move.line` is increased depending the reservation.
If the quantity couldn't be fully reserve then default `stock.move.line`
are create (depending the putaway rules or multiple ones if the products
are tracked). In case of decrease, the quantity reserved are unreserve
but the `stock.move.line` are not unlink until the validation.
- Planned transfer. The quantity done will fill the reservation. If the
picking is not assign, it will reserve the quantity needed. In case of
decrease, it will only unreserve the extra quantity (compare to the
initial demand). To unreserve the quantity bellow the intial demand, the
`stock.move.line` could be unlink or use the `unreserve` button.
force_qty in `_action_assign` is needed because we don't reserve only
base on the initial demand (`product_uom_qty`) but sometimes on the
quantity_done.
In order to never block the user. The action_show_details is always
available. If the id is not available, it will save and open the record
(we take the record based on the new existing line with same product
and highest id).
closesodoo/odoo#102738
Task-id: 2960983
X-original-commit: cacc677a08066bc23e1c89df36027599d05f2a08
Related: odoo/enterprise#32555
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
If the components of the manufacturing order are in done or cancel
state you should NOT define the status of the manufacturing order as done.
It should only be set as done if components and finished moves are done/cancel.
TT38551
closesodoo/odoo#102273
X-original-commit: 8cc7af8af300829e25033781673b7c071dd57638
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit converts `popover_widget`, `stock_rescheduling_popover`
and `mrp_workorder_popover` to OWL
closesodoo/odoo#101987
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Use case to reproduce:
- Create a product with manufacture and MTO route
- Set the warehouse in 3 steps manufacturing
- Confirm a SO for 5 units
- Update the quantity to 4 units
Current behavior
Each picking has a quantity to 4 units. Except for the post
production to stock that still for 5 units but a return is
created.
Expected behavior
Each picking has 4 units
It happens due to `_run_pull` that will create a new procurement
group in post production location (the purpose is to avoid a merge
between semi-finished product and finished product). But in the case
of a negative procurement, we want to decrease a picking and not
create a production order. So create a new procurement group with the
next MO sequence will aslo create another issue because
`_run_manufacture` will skip the MO creation since the quantity is
negative and it will be a gap in the sequence number.
Instead of creating a new procurement group, search for an existing
in sibbling moves, so `_search_picking_for_assignation` could find
a picking to merge the negative procurement and decrease an existing
move.
closesodoo/odoo#100439
X-original-commit: c5e8adaa2b364e3ff4625e080df4c523a9673668
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This PR https://github.com/odoo/odoo/pull/97805 wrongly assumed that
self contained a single workorder. This would raise an error if there
were multiple records in self.
Solution:
Modify calls on `self` to `workorder` (as we already iterate through
them)
closesodoo/odoo#101775
X-original-commit: 26cb902e603d6d576957d1d329d3eef4e76af5f8
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
When drag and dropping a work order in the Work Orders Planning, the
end time wasn't recomputed. This can make the end time inconsistent with
the duration when the work order spans across a non-working time.
Steps to reproduce:
1. Install Manufacturing
2. Go to Settings > Manufacturing > Operations and enable Work Orders
3. Go to Manufacturing > Master Data > Routings and edit routing
'Primary Assembly' to last 120:00 minutes
4. Go to Manufacturing > Operations > Manufacturing Orders and create
one with values:
- Product: Table Top
- Plan From: today's date at 11:00:00
5. Save, mark as todo and plan the manufacturing order
6. Go to Manufacturing > Planning > Planning by Workcenter and trigger
the day view
7. Move the work order to 8 am
8. The work order still lasts for 3 hours (according to its start and
finish time) even though its expected duration is 2 hours
Solution:
Recompute `date_planned_finished` when we move a work order in the
planning (`date_planned_start` and `date_planned_finished` are passed in
values), and recompute `expected_duration` when we extend it (only one
of them is passed depending on the way we extend the work order).
(`duration_expected` is never passed in values when we manipulate a work
order through the planning)
Problem:
`date_planned_finished` wasn't recomputed when moving the work order in
the planning
opw-2893622
closesodoo/odoo#100988
X-original-commit: 2515482d5a706c65a7d8e27028f43987f17e6e67
Related: odoo/enterprise#31720
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Current behavior:
When updating the quantity of a MO after it has been confirmed, there
was no rounding applied on the move_raw.
Steps to reproduce:
- Create a new UoM A for units, with a ratio of 250 and a rounding
precision of 1
- Create a BoM for 250 quantity of product A, that use 1 quantity
of product B with UoM A.
- Create a MO for product A, and confirm it.
- Change the quantity to product by clicking on the quantity, enter any
value above 250 (e.g. 275)
- The quantity for product B should is not correct (should be 2)
opw-2964561
closesodoo/odoo#100523
X-original-commit: fdea8f8bbb865fb711d470053891545c8f627018
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Added an option on Manufacturing Operation Type
This option allow auto-consumption up to the reserved
quantity of tracked components in manufacturing orders.
Task : 2950200
Enterprise PR : odoo/enterprise#30805closesodoo/odoo#98461
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Create analytic accounting entries for employee times logs on workorder.
Compute BoM costs based on employee hourly cost and employee number
required on mrp operations.
closesodoo/odoo#91565
Task: 2427466
Related: odoo/enterprise#23032
Related: odoo/upgrade#3556
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This patch is part of a complete rework of the workorder tablet view and general
work order processing experience. It's mainly done in the Enterprise
repo. In community: the changes are the follows:
- The workorder kanban view remodeled
- Prepare workorder productivity timer to work with employee
Task: 2427466
Part-of: odoo/odoo#91565
- Add columns setup/cleanup time to Specific Capatities of Workcenter
- Take into account these 2 fields when compute expected duration in WO
task-2925474
Part-of: odoo/odoo#97588
Auto mark manual_consumption as True as soon as the component is use in
an operation and make the field read-only
task-2925474
Part-of: odoo/odoo#97588
The commit modifies the following:
- add tooltip : 'Displays the consumed Lot/Serial Numbers consumed.'
- Change the column Serial Numbers to also display lot number
- Make the column read-only
task-2925474
Part-of: odoo/odoo#97588
Since d7716f071d, the onchanges to create the stock moves in mrp
production have been replaced by computes.
There was a hack in the create() method to trigger the onchanges in case
of import. As those onchanges do not exist anymore, this hack needs to
be remove too.
The compute methods are called naturally in imports.
closesodoo/odoo#99434
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This commit fixes two bugs:
1) Wrong source location
Before this commit:
- Source location is incorrect after merging MOs and 3-step manufacturing is selected.
- Operation type is incorrect after merging MOs
After this commit:
- Set the source location from the correct picking_type's value while merging MO.
- Set the Operation type for the merged MO to be the same as the original MOs';
2) Traceback when splitting mo
Before this commit:
- When splitting a MO without a "responsible user" set then boom it's throwing traceback
After this commit:
- The "responsible user" is no longer required which matches the existing MO behavior
TaskID - 2754217
closesodoo/odoo#99374
X-original-commit: 67e3f2f66aeb1aa1a93ad5091af7c0375f6d9a93
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce:
- Manufacturing app > Operations > Manufacturing orders > Create
- Set product to [FURN_7800] Desk Combination > Save > Confirm
- Click on scrap, choose any product > Done
- Edit the manufacturing order > set the quantity to 1/1 > Save
An error pops up: You cannot change the UoM for a stock move that has
been set to 'Done'.
This happens because the scrapped product has its destination location
wrongly set to the production location of the manufacturing order.
Because of this, it is considered as a component of the manufacturing
order. The scrap is also confirmed right after creation, so its state
is set to 'done'. Finally, when confirming a manufacturing order, all
of its component moves are also confirmed, hence the error.
This commit prevents the override of the scrap's destination location,
so that it is not wrongly considered a component anymore.
The commit also adds tests for the override method, added in
commit 0b247ab17ccc5be0c2058ef92ccf3502c97e0bb3
opw-2945182
closesodoo/odoo#99218
X-original-commit: 81820d4df5f23d9b6b2701e513ada89b528a865a
Signed-off-by: Adrien Widart <awt@odoo.com>
The move line form view is too technical for the average user so instead we
can to auto-magically open the reference document instead (picking or MO
only for now).
We do the same with stock valuation layers as well, but this feature
will not be available until its custom JS is converted to OWL
"product moves" part of b2b task: 2882539
closesodoo/odoo#97109
Related: odoo/enterprise#29974
Related: odoo/upgrade#3819
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Since the new Overview report can compute the lead days and availability
delays from a BoM and all of its components and/or subassemblies, we can
use this data to compute the days that would be required to resupply all
components from a BoM.
So we add a button to compute it directly on the product form.
Task-2628323
Part-of: odoo/odoo#93194
The legacy field MrpFieldOne2ManyWithCopy added a control create
that performed an action when clicked.
In the new listRenderer we have added the possibility to define control
action buttons. So it is no longer necessary to create a custom field
for this use case.
Part-of: odoo/odoo#97558
Steps to reproduce the bug:
- Go to Inventory→ Configuration→ Warehouse Management →Operations Types
- Go inside “Receipts”, and enable the checkbox “Create New Lots/Serial
Numbers for Components” and `Use Existing Lots/Serial Numbers`under the
traceability section
- Create a receipt transfers with a traceable product
- Mark as to do the transfer
- Try to add a SN for the product
Problem:
Traceback is triggered: “key error: raw_material_production_id”
because we use this field to add it in the context from the parent in
the `stock.move.line` view:
https://github.com/odoo/odoo/blob/15.0/addons/mrp/views/stock_move_views .xml#L53
But this field is not present in all views of the `stock.move` model
Solution:
To avoid adding this field in all the `stock.move` views, it is better
to add it in the context from the `python` code
closesodoo/odoo#98110
X-original-commit: 545713ae0a559e7f2747dd3cb4211ab752e1ef0c
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
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>
MerlinGuillaume