Steps to reproduce the bug:
- Enable “Multi-Step Routes” option in the inventory settings
- Create a storable product “P1” with BoM:
- Add any Component
- Go to “Miscellaneous” tab
- Create a new picking type and set in the “Operation” tab
- Create a Mo:
- Add the product “P1”
- Select the created BoM
- Go to “Miscellaneous” tab
Problem:
The operation type set on BoM does not update when selecting the BoM
on a manufacturing order
opw-3091436
closesodoo/odoo#108632
X-original-commit: cd561574d044d4799163ac90305c7914855ead50
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Before this commit, if a user changes a MO move qty to 0
and then tries to change the MO qty to produce, an error occurs.
The move with 0 qty is no longer cancelled or unlinked as this was not
the intenteded behavior.
Since the change production wizard no longer deletes cancelled moves
a test was updated accordingly.
closesodoo/odoo#108534
Taskid: 3082611
X-original-commit: 39abadb30dc8fab6b2a1ca24cb2916ab148fb5fa
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Ahmed Khalaf <ahkh@odoo.com>
When a kit template has several variants, the on hand quantity can be
incorrect.
To reproduce the issue:
1. Create two products P_compo, P_kit:
- P_kit:
- Storable
- Variants:
- Color (White, Black)
- P_compo:
- Storable
2. Update the on hand quantity of P_compo: 10
3. Create two BoMs:
- BoM01:
- Product: P_kit
- Variant: Black
- Type: Kit
- Components: 1 x P_compo
- BoM02:
- Product: P_kit
- Variant: White
- Type: Kit
- Components: 2 x P_compo
4. Open the form view of the template P_kit
Error: it displays "15 units on hand", which is impossible (there are
only 10 P_compo available)
Since it is difficult to determine the expected value, a decision has
been made: hide these smart buttons if a template has more than one
variant and if at least one of the variants is a kit.
OPW-2645299
OPW-2678400
OPW-3076502
closesodoo/odoo#108284
X-original-commit: cf3b83d6a48c080d900d9cf343e4012be718c79d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Since 2515482d5a70, the duration expected of a workorder was always set
to the real duration at the validation of the workorder. This commit
ensure the duration expected is left unchanged even if the
date_planned_finished is updated.
closesodoo/odoo#108233
X-original-commit: 46e1ae4d9918de1aaf6b4a7565dba422b03fcb36
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Create a BoM with components
- Archive one of the components
Problem:
No warning is displayed for the user to inform that the product is
used as a component in a BoM
opw-3089104
closesodoo/odoo#107863
X-original-commit: 9b7c416387d93507b6f750aba58ad6233a59d512
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- install “mrp_mps”
- Create a storable product “P1”
- routes: Manufacture + MTO
- make sure there is no BoM set
- Go to “Master Production Schedule”:
- Add the product “P1”
- Add a quantity and click on “Replenish”
Problem:
A User Error is triggered with the following message: `The unit of
measure Units defined on the order line doesn't belong to the same
category as the unit of measure False defined on the product. Please
correct the unit of measure defined on the order line or on the product,
they should belong to the same category.`
The `compute_qauntity` function is called to convert the qty into the
UoM of the BoM, but since there is no bom, an empty record is given as
a parameter:
https://github.com/odoo/odoo/blob/8c5fb8b71538462422c8f166b772b5e316ecd6b5/addons/mrp/models/stock_rule.py#L122https://github.com/odoo/odoo/blob/0f91970020af640faa3a06369fa888315f83f98f/addons/uom/models/uom_uom.py#L215
opw-3085227
closesodoo/odoo#107476
X-original-commit: 7d0df9035cf603ed25ef88a3cf99ed89aef6771e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
To reproduce:
Create a MO without product_id, then add a new line in work orders.
Error raises.
Since cab8d8fe7f744fb4dd0cd61b624f6f4519eb8d8d, we started to show
qty_remaining of WO on MO form. It triggered the compute function of
qty_remaining. Since we don't set product_id, production_id.product_uom_id
is not provided when doing the calculation.
To fix, add production_id.product_uom_id as dependancy of qty_remaining,
and don't do the calculation without it.
opw-3092723
closesodoo/odoo#107434
X-original-commit: 0b10241c0bcbecda73dae04c8a5f1ceb8033a388
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
This commit changes popover widget such that instead of altering the
popover component during app lifecycle to make dynamic
popover templates, use `t-call` to call template passed in props.
closesodoo/odoo#107286
X-original-commit: f1a9de85c19a53c9516cac44de6cbaf53d850842
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Previously, _intervals_duration (called by _compute_duration)
sometimes loose the last mrp.workcenter.productivity.
A fix has been made.
First, mrp.workcenter.productivity.loss _convert_to_duration
calculates according to the loss type, we have to take that in account.
Second, mrp.workcenter.productivity _close badly generates
performance timers.
For example, test_mrp_employee_analytic_account generated
- productive for 1st employee from 10:00 to 11:00
- performance for 2nd employee from 10:00 to 11:00
- performance for 2nd employee from 11:00 to 11:00 (! duration = 0)
Now, the timers are
- productive for 1st employee from 10:00 to 11:00
- productive for 2nd employee from 10:00 to 11:00
which is correct.
closesodoo/odoo#106908
Task: 2985735
X-original-commit: 8638ec145ab83e4afafa39a5c9e987e8d772bfd1
Related: odoo/enterprise#34533
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Jean-François Aubert <ajf@odoo.com>
Fix workorder times problems:
- sum in workorders list view
(displays numeric value rather than mins:secs)
- timers sometimes starts at -00:01
- almost all tablet view actions reset the timer (click burger, ...)
- clicking pause stops the timer at the next second
- seconds are lost in employee timers
Task: 2985735
X-original-commit: 7dceef12771890f9fb9fa554e70414c622053ced
Part-of: odoo/odoo#106908
Only active boms should be returned by the domain even if
they match a product id.
closesodoo/odoo#106615
X-original-commit: 2a73890d304476833d76bac9a36ef92f12f267a3
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
First correction: replace call to `read_group` to `_read_group` in order
to avoid useless joints on table product_template and ir_translation
when the grouping key is a Many2One.
Second correction: add an index on workorder's `state` field. The
get_conflicted_workorder_ids() method search for ready workorders that
are in conflict relate to their planning. The state value is searched to
many times to not index it
closesodoo/odoo#106582
Task: 2852423
X-original-commit: b5019eec76845316e554f2dd11a6d8bbf6fea433
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
mrp
===
- no time has been recorded on operations then give warning with apply button
- do not allow to mass edit UOM in any manufacturing state
- set value of lot/serial from MO and set read only on unbuild from MO
- remove "archive operation" icon
repair
======
Currently it is not possible to select a return on a repair order unless save it first. so after this commit user can able to select it without save it.
only show picking related to selected product
closesodoo/odoo#106571
Task: 2845380
X-original-commit: dd60647ce41547ecd00bbde45ddf564a7ada91c7
Related: odoo/enterprise#34403
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Issue: In the MO view, the src location for components was editable and
the dest location for byproducts was editable when neither of these
should be.
Due to the same field appearing twice in the same x2many field list,
there were 2 issues:
1. something changed (probably during OWL refactoring) that made it so
the 2nd invisible field instance of the field was overriding the
"readonly='1'" property of the 1st instance when it was in the view
(i.e. when multi-locations is active) [in previous versions this did
not happen]
2. because of the change by https://github.com/odoo/odoo/commit/168cbe66bee7824bdf389de5c6c680342e27bc6d
we ensure that these two required fields are always correctly set (to
the MO's values as per the default when multi-loc is active) when the
MO's moves are created.
Part of general bugfix task: 2985735
closesodoo/odoo#106542
X-original-commit: 1bb2c44d32e669a9b936da90cbd80721b2c897ef
Related: odoo/enterprise#34396
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”:
- route: MTO + manufacture
- uom: unit
- BOM:
- qty: 1 dozen
- component: 12 units of “C1”
- Create a SO:
- Product: 12 unit of “p1”
- uom: unit
- Confirm the SO
Problem:
The UOM set on the product is used instead of the BOM UoM on the created
manufacturing order.
wrong MO:
- 12 unit of "P1"
expcted MO:
- 1 dozen of "P1"
opw-3048190
closesodoo/odoo#106351
X-original-commit: 8c5fb8b71538462422c8f166b772b5e316ecd6b5
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
When marking a WO as done, if the serial number defined is related to an
unbuilt product, an error will be raised and the user will not be able
to mark the WO as done
To reproduce the issue:
1. Create a BoM for product P with one operation
- P is tracked by SN
2. Produce one P with serial S
3. Unbuild it
4. Create and confirm a second MO with 1 x P
5. Start the WO
6. On tablet view, set the finished lot to S
7. Mark the WO as done
Error: a UserError is raised because "This serial number [...] has
already been produced". However, this serial number has been unbuilt so
the worker should be able to use it again
When marking the WO as done, we check the uniqueness of the defined
serial number. But:
- The check is not accurate enough, hence the above error
- The lot of the WO is a computed/inverse field based on lot of the MO
- Once the WO closed, we can still change the lot of the MO
- When marking the MO as done, a better method checks the SN uniqueness
(does not fail in the above case)
Therefore, the checking on WO side is useless. We should let the MO side
handle this.
Moreover, let's say that there is already one P in stock with serial S2.
On tablet view, if the worker set the lot to S2, there should be a
warning so he can be aware of the situation. This is already the case on
MO side:
https://github.com/odoo/odoo/blob/45e37b2ad7bdcfd9f9f7e1dabbd0a99c9a0b5cdc/addons/mrp/models/mrp_production.py#L694-L705
(This commit is linked to a similar commit OE side, same opw)
OPW-3002424
closesodoo/odoo#106152
X-original-commit: 60a4c37c781ceb20123cb99603ddd2890b1c806c
Related: odoo/enterprise#34183
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Fields `product_qty_available` and `product_virtual_available` on
stock_move are related on quantities fields of move's product_id. On
large database, those two fields will slow down every transactions that
updates stock move state (confirmation, validation, ...).
`state` on stock.move is a dependent field of computed field `qty_available` on
product.product which is dependent field of related field
`product_virtual_available` on stock move. This relation tree implies
that updating the state on one particular stock move will mark its
product (qty_available) as 'to be recomputed' and thus **every** stock
moves (product_virtual_available) of this product as to be recomputed.
On database will 100k+ stock move per product. Fetching all stock move
of some products take 90% of a manufacturing order validation time. This
is problematic knowing those two quantity fields are only used in the
stock move tree form so computed anyway at the view rendering.
This commit change the `depends` of those two related field to mark them
as to be recomputed only if the product_id change.
closesodoo/odoo#106070
Opw: 3047017
X-original-commit: 189e825e567e4c633d721ce9f0fee906535edf06
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Purpose is to cleanup code: stop using help parameter name (use help_message as
help is a keyword), try to call super(), ...
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#105992
Steps to reproduce the bug:
- Create a storable product ”P1” with 2 BoM:
- BoM 1:
Type: manufacture
Component: C1
- BoM 2:
Type: manufacture
Component: C2
- Create a MO:
- Add the product “P1”
- The BoM 1 is automatically set and the component “C1” is added
- Save the MO
- Edit The MO:
- set the BoM 2 instead of BoM 1
Problem:
The component C2 is added, but the component “C1” linked to BoM 1 is
not deleted
To delete the existing lines, we check if the product has changed,
but we do not check if the BoM has changed:
https://github.com/odoo/odoo/blob/16.0/addons/mrp/models/mrp_production.py#L694
Solution:
clear “move_raws” if BoM change.
No need to check if the product has changed to clear component,because
if the product changes, the bom changes too
opw-3069283
closesodoo/odoo#105983
X-original-commit: 916449eb382715f341b05666cfec336e30c5db36
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
It is not possible to consume a component tracked by serial that comes
back from a scrap location
To reproduce the issue:
1. In Settings, enable "Multi Routes"
2. Create two storable products P_compo, P_finished
- P_compo is tracked by serial number
3. Update the on-hand qty of P_compo:
- 1 x P_compo with serial SN
4. Process a manufacturing order MO:
- Product: P_finished
- Compo: 1 x P_compo with SN
5. Unbuild P_finished
- It brings SN back to stock
5. Scrap one P_compo with SN
6. Unscrap it (thanks to an internal transfer)
7. Repeat step 4
Error: a user error is raised: "The serial number SN used for component
P_compo has already been consumed"
When checking the SN uniqueness of a component, we don't consider the
case where a product came back from a srap location
OPW-3055252
closesodoo/odoo#105926
X-original-commit: 476dbb6f2138294200ba7bfef96553e5d89b1a0e
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This is more efficient than calling it record by record.
closesodoo/odoo#105143
X-original-commit: 9bbcee2bca8a69e8388097e2e5070ed620dcebe2
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
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>
Touati Djamel (otd)