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>
Steps to reproduce :
In a Manufacturing Order, update quantity (product_qty)
Expected behavior :
In the "Components" tab, "To Consume" column should update without Save
Actual behavior :
Due to "mrp_should_consume" widget not being reactive, should_consume_qty is not updated in the view until it's saved.
closesodoo/odoo#104364
Task: 2985735
X-original-commit: b3ec31d89eb635b555f77b3eb9ecaac4c65981e6
Signed-off-by: Arnold Moyaux (arm) <arm@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>
Steps to reproduce
==================
- Create a BOM
- Add a line with a product of type product
- Set the quantity to 0
- Save and click on overview
-> ServerError: Division by 0
Cause of the issue
==================
Lines with a quantity of 0 should be excluded from the computation
opw-3053167
closesodoo/odoo#104980
X-original-commit: b0f5170252ed73d31543b8d1dcf114ae6f0b65bc
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@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>
*: base_automation, lunch, mail, mrp, project, web_editor, website
This commit adds a warning if the props validation is not set for a
component.
The props validation is important to tell how a component should be
used, by looking at its code, it's a good documentation of the component.
It's also critical, to test if the component is correctly used, if all
the obligatory props are passed and that there are of the correct type.
For more information, see: https://github.com/odoo/owl/blob/master/doc/reference/props.md#props-validationclosesodoo/odoo#103723
Related: odoo/enterprise#33044
Signed-off-by: Géry Debongnie <ged@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>
- set monetary widget to align foat field with other monetary fields
- use default production order in the list view to have the same order
everywhere.
Task: 2991906
X-original-commit: 38b82230b75f972a7da5d4c53ea1a4c7359cd913
Part-of: odoo/odoo#103055
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>
Ensure the google slide are displayed in both readonly and editable
mode. The slides should be hidden only if the url is wrong or empty.
closesodoo/odoo#103872
Task: 2991906
X-original-commit: bbf4f1e7b9cb456f2930c270f7e2b2c35cc9e80d
Related: odoo/enterprise#33100
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Since odoo/odoo#95729
nodes with a `groups=` are completely removed from the views when
the user is not part of the group, instead of being made invisible.
In that PR, views have been adapted to add back fields, with invisible="1",
when they were required, for instance when they were used in a domain
of another field which was still there despite the user is not part
of the given group.
As `tree` views having `multi_edit="1"` where not considered
as editable views, the domain of fields in these views were not
validated:
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1460
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1321-L1322
while they are well required for the web client,
in `multi_edit="1"` this is possible to edit relational/many2one field,
and therefore it will do `name_search` calls using the domain of the
field, and therefore the fields used in these domains must always
be present in the views. Without it, a crash in the web client occurs
when attempting to edit the relational/many2one field.
This revision targets to consider the `multi_edit="1"` tree views
as editable, to make the field domains validated as they should be.
Hence, views are adapted to add back fields with `invisible="1"`
when they are required in domains of other fields.
Part-of: odoo/odoo#103790
In order to correctly handle dark-mode (#99755) elements
that match views bg-color should use `bg-view` class.
task-3012970
closesodoo/odoo#103132
X-original-commit: e29347b4c45325584b0dd30a15fdf5d662f62c99
Related: odoo/enterprise#32753
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Adapts the layouts of the immediate production and the production's
backorder to match the new grid css for groups.
Part of task-2985735
closesodoo/odoo#102958
X-original-commit: 5b999ee40e02647c0d2edfbce7081f6f8cf05857
Signed-off-by: William Henrotin (whe) <whe@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>
Before this commit, in the mrp_production form view, the quantity items
were spread out.
After this commit, they are closer together.
closesodoo/odoo#102582
X-original-commit: 3aa74fd15ed951974485fadd6a362fdaf374b202
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The status badge on workorder kanban card was hidden behind a dropdown
widget because of a wrongly used class.
X-original-commit: 491546a5c3ce6203763a7d829b44107e66ff3f42
Part-of: odoo/odoo#102398
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>
The event listeners were added to the upload object instead of the xhr
object making them being called before they were supposed to.
closesodoo/odoo#102061
X-original-commit: 804467d7b0a583ab36a47212d482b41d29ca2203
Related: odoo/enterprise#32247
Signed-off-by: William Braeckman (wbr) <wbr@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 creating a MO with some WO from a mobile, the quality checks are
not created
To reproduce the issue:
(Need quality_control)
1. Create two storable products P_compo, P_finished
2. Create a BoM:
- Product: P_finished
- Components: 1 x P_compo
- Operations: create a new operation OP
3. Add a step to OP:
- Type: Pass - Fail
4. Switch into mobile mode
5. Create a MO for 1 x P_finished
6. Confirm it
7. Open the WO
Error: the tablet view skipped the pass-fail step, the user can already
mark the MO as done and close it
When confirming the MO, it leads to the quality checks creation. To do
so, we iterate on the `quality_point_ids` of the WO to generate these
quality checks:
https://github.com/odoo/enterprise/blob/7ff0f43df777027bf8544be3ac95e76feb7da957/mrp_workorder/models/mrp_workorder.py#L406
But, the WO has not any quality point, which is incorrect: it should
have the one related to the step created on the operation P. This field
is a computed one and is based on the quality points defined on the
operation linked to the WO:
https://github.com/odoo/enterprise/blob/7ff0f43df777027bf8544be3ac95e76feb7da957/mrp_workorder/models/mrp_workorder.py#L70-L73
But again, there is an issue: the WO has not any defined operation
(which is incorrect, it should be linked to OP). And this is because of
the WO creation from the kanban view: the field `operation_id` is
missing so it is not defined during the WO creation.
OPW-2984037
closesodoo/odoo#101346
X-original-commit: 751f1253d4a32491d210aceb4767084088c314ad
Signed-off-by: Adrien Widart <awt@odoo.com>
With the change to 'always edit' on form views by default, several
'oe_read_only' fields had to be modified to play nice with the fact
that in most cases, there is no read_only mode
closesodoo/odoo#101188
X-original-commit: 868992abeeda983768323e1126b5643eff8fdb33
Related: odoo/enterprise#31810
Signed-off-by: Bouvy Damien (dbo) <dbo@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>
Steps to reproduce:
- install the mrp_plm module (Product Lifecycle Management app);
- create a product with a long name;
- create a bill of material for that product;
- create a manufacturing order and select that bill of material;
- confirm the manufacturing order.
Issue:
The value of the bill of material field overflows into the second column.
Cause:
There is a problem in the use of classes in the .xml file (o_row and d-flex).
Solution:
Change the classes used (Bootstrap and Odoo classes) to have the correct rendering.
opw-2966863
closesodoo/odoo#100305
X-original-commit: 7a7c6870a2006edab8ffe62c016e5eb0681a46f8
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@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
This views has multiple custom features such as file upload, attachment
viewer and download.
A lot of files have been rendered obsolete and have been deleted,
notably `file_upload_mixin` which has been replaced by the
file_upload service and hooks.
closesodoo/odoo#99769
Related: odoo/enterprise#31145
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Since [1], a global time off is created in the demo data. Its date is
"today + 8 days". In `mrp`, the test `test_workcenter_timezone` tries to
plan some work orders for the next Monday:
https://github.com/odoo/odoo/blob/06e33207cdc6608e629a316fdddc35a15e08a3ad/addons/mrp/tests/test_order.py#L1882-L1883
So, if you install the demo data of `hr_holdiays` on Sunday and run the
test the day after, the global time off will prevent the slot
reservation by the work orders (and so it will lead to a failed test).
[1] e9bc5b9f36closesodoo/odoo#99665
X-original-commit: efa48d90839b7bd8b5638f352d7846339e360ac2
Signed-off-by: Adrien Widart <awt@odoo.com>
- 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
MerlinGuillaume