When a product has been unbuilt and also (mistakenly) scrapped, it's
impossible to reuse the serial number in production again, even if the
product is unscrapped.
This fixes the sanity check in a similar way to the _check_sn_uniqueness
function, not just checking for removed stock move lines, but also unremoved
stock move lines. A test case is also added to check this scenario.
This is a similar fix to a previous commit we did
(4f07b260807053586ac6c01cf92ac3d5e37b1041) where we bumped into a
problem with the duplicate serial sanity check.
closesodoo/odoo#142574
X-original-commit: 1761b95d9fda5d5355f35effd1f345a25ded1197
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Create a storable product with two attribute “P1”:
- Color: Red and Blue
- Create a BoM:
- Product template: P1
- BoM lines:
- C1: 1 unit -> apply on variant P1 red
- C2: 1 unit -> apply on variant P1 blue
- Create a MO:
- 1 unit of P1 red
- Only the component C1 is added, which is correct.
- Change the product to P1 blue.
Problem:
The C1 component is not removed because to clear the move_raw_id,
we only check if the BoM is changed. However, in this case, it doesn't
change.
opw-3591800
closesodoo/odoo#142631
X-original-commit: 2a31cdb67338dd065b1aeb2d5e8c57724e8af236
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
After this commit, detailed operations is no longer a tab in the picking
but under a smart button in the form.
The field `show_operations` on picking type is no longer useful and will
be removed in a later PR targeting master
closesodoo/odoo#140898
Taskid: 3486636
Related: odoo/enterprise#50805
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
- Enable multi steps route for manufacturing (in Inventory settings)
- Crete and confirm an MO with a kit and a non kit manufactured components
(eg: table kit and desk combination)
- Validate the created transfer
- Print the delivery slip
Bug:
the manufactured product is absent from the delivery slip
Fix:
apply the correct filter on the move lines
opw-3502881
closesodoo/odoo#142380
X-original-commit: 8c57a4f039549f4bb02a6794eda90de66c74ad28
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
For Confirmed MOs, the date that should be used is the `date_start`, not the `date_deadline`:
- Confirmed MOs have StockMoves with `move.date == mo.date_start`
- When computing the qty_to_order, the move.date will be used
- When finding existing MO to add quantity
If `mo.date_deadline != mo.date_start`
Then we can end up in a situation where a Confirm MO is too late to take its quantity into account, but not too late to add the qty_to_order to it.
Then everytime you run the scheduler, this MO will be too late, so new quantity must be ordered, and the quantity will be added on this MO which is too late.
## TO REPRODUCE ##
- Create product P_M
- Create BoM
- Create Reordering Rule:
trigger: auto | min: 10 | max: 20 | route: manufacture
- Create & Confirm SO for 10 unit of P_M
=> new confirmed MO for P_M should have been created
- Update MO scheduled date to 2 days in the future
- Run Scheduler
=> New quantity added, you can run the scheduler as many times as you want, new quantity will always be added
OPW-3524854
closesodoo/odoo#142256
X-original-commit: 531fa573a3bb40bd3b82c2a21db5e82d51a2800a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David Fesquet (dafr) <dafr@odoo.com>
Before this commit in large database, the time to unlink some lot can take lot of time.
closesodoo/odoo#142105
X-original-commit: 654ee5c54db6d2cdf7a9d6797899d25a5b156059
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Opening the Overview of manufacturing orders containing work orders
without expected duration gives a division by zero.
closesodoo/odoo#141944
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Create a tracked product with BoM “P1”:
- component: add any storable product e.g “C1”
- byproduct: add any storable product e.g “B1”
- Update the stock of C1
- Update the stock of “P1” with two SN
- use the 2 SN of P1 as component in any MO and mark the MO as done
- Create a new MO to produce 2 units of P1
- Confirm the MO
- Click on “Mass produce”
- Generate two new SN
* First error : The byproduct quantity is not set
- Try to Mark as done the new MO
Problem:
A user error is raised: 'This serial number for product P1 has already
been produced'
When splitting the MO into two, a “stock.move.line” are created with
a qty_done = 1, leading to an error when verifying if the serial_number
of the move_finished has already been produced.
When clicking the "mark as done" button on the MO, the function
"_check_sn_uniqueness" is triggered and since the finished product is
tracked and there is a serial number set in the MO, the function
"_is_finished_sn_already_produced" is called:
https://github.com/odoo/odoo/blob/c84d80cc71ca0e7120dd293bfc56f9027bfdf9fc/addons/mrp/models/mrp_production.py#L2158-L2162
Within this function, we verify if the move lines of the finished move
have a lot and qty_done set. If this condition is met and we do not need
to exclude this move, an error is triggered.
https://github.com/odoo/odoo/blob/77ca3a830d0f61ee8a5ba31b3b79e80e85c08e79/addons/mrp/models/mrp_production.py#L2063https://github.com/odoo/odoo/blob/77ca3a830d0f61ee8a5ba31b3b79e80e85c08e79/addons/mrp/models/mrp_production.py#L2086
Solution:
Set "qty_done" to 1 only within the move lines of the components.
Opw-3566259
closesodoo/odoo#141521
X-original-commit: e0e6aed35d0f75c3ad01fbc329d7189f9e8d82f4
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce the bug:
- Create a kit product
- Create a storable product without BoM “P1”
- Create a MO to produce one unit of “P1”
- Add the kit product as component
- confirm the MO
Problem:
The Manufacturing Order is cancelled. This is because the MO contains
a kit product, and we need to generate moves based on its Bill of
Materials. However, at the same time, we cancel and remove the move
associated with the original product, which is no longer relevant.
But We remove it before creating the moves generated from the phantom
product. Consequently, since we cancel the move, the 'compute_state'
of the MO is triggered, and as there is only one 'move_finished' status
in 'cancel,' the status of the MO is set to 'cancel:
https://github.com/odoo/odoo/blob/5c238bbb18c682ff2d25f740aad604feb7bb5bbc/addons/mrp/models/mrp_production.py#L462-L463
Opw-3548464
closesodoo/odoo#140016
X-original-commit: baa0924974fee0115a0bce117141a8096455b88d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Only keep the forecast widget since it does the same with more data.
There's no point in showing the forecast for done or cancelled
production orders.
The purpose is to have an easy view at the beginning. Avoid to
add too much useless information for users
Also put it at the end so it's the same standard for
stock/mrp/repair
closesodoo/odoo#140955
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When `manual_consumption` field on sm is used in any onchange function,
the value will always be computed for the `new_id` record instead of
using the original value stored in database. This results in a different
value in some cases. In this commit, we chech if the compute function is
called from an onchange funtion or not, if so, we use the original value
instead of recomputation.
closesodoo/odoo#140753
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When a component is in manual consumption and without picked checked,
set qty button on the warning wizard doesn't work for it. This is
because we didn't set the move picked = True when click set qty button.
Fix it by set the value.
Part-of: odoo/odoo#140753
To reproduce:
1. Create an MO of Product with BOM
2. Manually set qty for a component
3. Produce all
Issue:
Two consumtion warning lines are shown, and numbers are wrong
Part-of: odoo/odoo#140753
It's not possible to copy paste in the lot_name directly. It has been
remove since the import button.
Also add by default a search on hand in the quant view from the
stock.move.line. We don't want to show quant already send to customer
location or without quantity
Part-of: odoo/odoo#141272
If there are pre-production rules, their delays should also be added to
the total delay of a manufacture route.
Task-3081481
closesodoo/odoo#137810
Related: odoo/enterprise#48516
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
For subcontracting, we need to consider both vendor lead time and
manufacturing lead time, and DTPMO (Days To Prepare MO) on the BOM.
Subcontracting delay =
max(Vendor lead time, Manufacturing lead time + DTPMO) + Days to Purchase + Purchase security lead time
Same thing applied to Bom overview, except:
1. Availability state will be computed based on the delay time of it's
components. DTPMO on the bom won't be take into account.
2. Lead time will use the DTPMO on the BOM. DTPMO will be added to
the lead time when it's a manufacturing bom or when it's a
subcontracting bom with Manufacturing Lead Time + DTPMO > Vendor Lead Time
Task-3081481
Part-of: odoo/odoo#137810
To reproduce:
- Set tracking mode on Table Leg to no tracking and add 100 to inventory
- Create MO for table with quantity more than one and confirm
- Click the "+" button to generate a serial
Current behavior: The reservation state of the MO goes to "available" in
orange, indicating its components are not all assigned.
Expected behavior: The reservation state of the MO stays "available" in
green, indicating the MO has all of its components assigned and is ready
to produce.
closesodoo/odoo#141130
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Does 2 things:
- ensure that the "free_qty" doesn't display a negative value (=>
consistent with MO overview + avoids neg "Ready to Produce" values)
- ensure that showOptions.availabilities is always a Boolean and never
"undefined" (=> avoid traceback when opening overview while in debug
mode)
closesodoo/odoo#140767
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Previous to this commit, the qty reserved was only considering the
currently reserved quantities in the MO, not the ones calculated and
displayed in the MO Overview (i.e. including the quantities reserved in
the picking during 2 step mrp). This would lead to showing reserved
quantities but a "Not Ready" status, which is confusing and
inconsistent.
Now we pass the calculated component quantities to the method that
calculates this state and ensure the calculation is consistent.
Steps to reproduce:
- enable 2 or 3 step mrp
- create an MO with a component that is in stock at the stock loc
- confirm MO and open "Overview"
Also change "Quantity" back to "Reserved" in the pdf version of the MO
Overview. This was a mistake change since this column name already
exists and "Reserved" will be hopefully less confusing for users.
Part-of: odoo/odoo#140767
Before this commit
===================
In MO if a line is deleted or line has its to consume quantity reduced so in
done state transfers return is creating.
After this commit
===================
Stopped creating the return on done state transfer when quantity is reduced or
a line is deleted.
closesodoo/odoo#133696
Task: 3283010
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Currently after confirmation on picking. The details operations button
is mixed in the trash icon. The view needs a refresh to be correct.
This is cleaned by moving all the buttons together and introducing the
custom column before the last buttons group.
Part-of: odoo/odoo#140663
From the backend manufacturing order view, it was no longer possible
to specify batches/serial numbers for by-products.
Now it is.
closesodoo/odoo#140446
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
*: account, hr_recruitment, project, lunch, mrp
By removing the absolute positioning on ".o_favorite" inside kanban
views, we allow it to align naturally with the rest of the elements,
thus removing the custom code that was needed for padding.
By doing so however the icon - which is now only visible on hovering the
card in the Project's kanban view - should remain visible at all times.
The behaviour would be the same as in other kanban views: an outlined
star when not active and a full yellow star when it is.
The margin on the kanban heading in the Manufacturing orders has been
removed to realign the top elements.
task-3462098
closesodoo/odoo#131559
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
This commit fixes:
- hide `read_duration` and `expected_duration` in MO list view.
- hide `component availability` byt default in bom overview,
unless if coming from mrp forecast.
task-3547356
closesodoo/odoo#140244
Related: odoo/enterprise#49802
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Fixes 2 use cases:
- barcode redirect after picking is validated (should return to menu
instead of refreshing the validated picking). Issue was due to missing
renaming of "on_close" to "onClose" after refactor occured
- ensure the auto-print action during MO validation always has a context
because the "Shop Floor/MES" expects any returned actions from
validation to always have a context to add the extra context parameter
of "skip_redirection" to it
closesodoo/odoo#140352
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
A "quantity_done" removal was missed in the MO Overview report, which
made it so the report would throw an error when opened for a done MO.
Also replace "Reserved" with "Quantity" in the overview so that
it is more consistent with pickings + is more intuitive since it is
currently confusing that when the qty produced is updated, then it
appears that the qty reserved changes (rather than a qty being done)
closesodoo/odoo#140246
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
1. Rename 'Reserved' on MO components to 'Quantity'
2. Hide `picked` field on MO compoents by default
3. Add tooltip for `picked` field on sm.
closesodoo/odoo#140150
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Commit a97b352e761b421f6205b03a9b87c79358c128cd removed MrpProductionComponentsX2ManyField
to use MrpProductionComponentsListRenderer for coloring quantity cells
for manual consumption. Correctly extend StockMoveX2ManyField in this
commit.
closesodoo/odoo#140141
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Simon Wydooghe