Current behavior:
When creating a BOM with quantity different than 1 (here 12) with operation duration 1 minute and work center capacity 23
The BoM Structure & Cost report only changes the time for the operation when the quantity is > 276
However, when planning a MO the expected duration changes to 2 minutes when the quantity is > 23
Expected behavior:
Expected duration should be the same in the MO and BoM report
Steps to reproduce:
- BOM with quantity different than 1 (here 12)
- operation duration 1 minute
- work center capacity 23
- go in BoM report
closesodoo/odoo#80048
X-original-commit: cf90943875da25456cde4faf967ce27d886c0851
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In multi steps configurations, the additional products of a MO could be
missing in the associated picking
To reproduce the issue:
(Use demo data)
1. In Settings, enable "Multi-Step Routes"
2. Update the current warehouse:
- Manufacture: 2 steps
3. Create a MO for product "Table Top"
4. Edit the MO:
- Add 1 x Screw in the components
5. Confirm the MO
6. Open the generated Picking
Error: The operations only contains one line for "Wood Panel". There
should be a second line for the "Screw"
When adding the new component, a new stock move is created but the
latter does not have any `group_id` defined. This is the reason why the
generated picking does not include this stock move.
OPW-2671995
closesodoo/odoo#79894
X-original-commit: 720f29fc6b7626ae734187242870a27065441ac2
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Updating the producing quantity may wrongly change the consumed quantity
of tracked products
To reproduce the issue:
1. Create two storable products P1, P2:
- P2 is tracked by lots
2. Update P2's quantity >= 10
3. Create a BoM:
- Product: P1
- Components: 1 x P2
4. Create and confirm a MO for 10 x P1
5. Check availability
6. Edit the MO and set the consumed quantity of P2 to 10
7. Edit the MO and set the producing quantity to 8
Error: The consumed quantity of P2 becomes 1
When saving the MO, it also writes the `lot_ids` on `move_raw_ids` while
it shouldn't. As a result, it triggers method `_set_lot_ids` for no
reason and lead to an undesirable behavior.
OPW-2667412
closesodoo/odoo#79757
X-original-commit: 66a1e96f88b3b06f40f9fd8035fca61d4e2a4e3a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Current behavior :
When a bom is created with uom set as dozens the report
operations time is not correct. For exemple if the operation
time is 10 minutes. The operation time for a dozen should be
120, but at the moment it's 10 minutes
Steps to reproduce:
Have a product in units.
Create a bill of materials in dozens.
Have a operation where the workstation that has a capacity of 1.
Look at the Bill of material cost and structure even though it uses a dozen it shows
the operation time for one unit.
opw-2669899
closesodoo/odoo#79624
X-original-commit: 11f905737ea73aaf26dc792639abf66549a31864
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
In a previous commit, the reception report label was refactored to be
better, making this report obsolete. For migration purposes, we remove
it in this separate commit.
Previous COM PR refactoring: odoo/odoo#76411closesodoo/odoo#76147
Task: 2632884
Related: odoo/upgrade#2815
Signed-off-by: Arnold Moyaux <arm@odoo.com>
stock.orderpoint._post_process_scheduler confirms
productions after procurements have been run.
This was introduced to avoid conflict between
procurements, conflicts that can happen e.g. in
the purchase_mrp module.
However, currently action_confirm might
also be called on done or cancelled productions.
That can happen if there are already been lots
of procurements for the same product/orderpoint,
i.e. MO with the same values have been created multiple times.
To avoid this, add ('state', '=', 'draft' in the search_domain.
opw-2666960
closesodoo/odoo#79437
X-original-commit: 11c7b92f90804a4d73833e22c071e1665058fbdb
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Current Behaviour :
When mass producing with SN, the default number of SN to generate is set to 0.
Behaviour after the PR :
When mass producing with SN, the default number of SN to generate is the number of item to produce.
opw-2680306
closesodoo/odoo#79431
X-original-commit: 38e5d002acc2e516987acc0afe38648473fff708
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Previously the reception report > "print labels" would only print the
picking name (or SO if provided) + delivery address (if provided) when
not for a MO. Label has been updated to include the product name.
During this update a few other related improvements were made:
- make the label based on stock.move (so extending is no longer
needed in MRP)
- formatting of label is improved so now address will be truncated
instead of wrapping (and potentially losing lines at end of address)
- line padding is reduced so we can fit more lines in the label
- "Print Labels" button at source level will now be enabled when its
corresponding "Assign All" button is pushed (previously only the
"Print Label"s of each moves' line was enabled.
Part of Task: 2632884
X-original-commit: 9774c1ab1d68cf095b64a82b56f100d747fc8a56
Part-of: odoo/odoo#79408
The component status of a MO is not correctly computed
To reproduce the issue:
(Use demo data)
1. Create and confirm a MO for 1 x [FURN_9666] Table
2. Unlock and edit the target of To Consume Qty:
- For [FURN_8522] Table Top: 0.1
- For [FURN_2333] Table Leg: 0.1
Error: The Component Status of the MO becomes "Available" while Table
Top and Table Leg are not available.
Due to the signature of `float_compare`:
https://github.com/odoo/odoo/blob/56f8c1c0487bf95325ca859e2f266d1beed28ad4/odoo/tools/float_utils.py#L127
`move.product_id.uom_id.rounding` is implicitly given to
`precision_digits`, which is incorrect.
OPW-2669931
closesodoo/odoo#79362
X-original-commit: c7077dedd63ad317517ad383855821e6570b963d
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
In 1e93c161ca454313436b65427542db961f6ddcdd we trigger RR when
confirming a MO. Same thing should be done if we changed the product qty
for a confirmed MO.
Task-2653116
closesodoo/odoo#79332
X-original-commit: 22eb5c38ff45f4e5cd5d2025d31960efa051ad6b
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Steps to reproduce the bug:
- install mrp_workorder
- Create a new work center which will work every day from 8:00-9:00
- Create a BOM with component and operation, which takes 24 minutes in your work center
- Create 4 MO for this bom
- Set manually scheduled date > 1 MO should have a different date than others, e.g:
- 3 MO → 01/dec/2021 08:00
- 1 MO → 02/dec/2021 08:00
- Plan the MO which has different date than others
The ```planned_end_date``` is not calculated correctly
Current behavior before PR:
MO_1 : 01/dec/2021 08:00 → 01/dec/2021 08:24
MO_2 : 01/dec/2021 08:24 → 01/dec/2021 08:48
MO_3 : 02/dec/2021 08:00 → 02/dec/2021 08:24
MO_4 : 02/dec/2021 08:24 → 02/dec/2021 08:24
Problem
The MO_4 should only last 20 minutes, while it lasts 23 hours and 48 minutes.
opw-2648065
closesodoo/odoo#79184
X-original-commit: b02cdbbe36ead262331fc74ec3039c8ded313d3d
Related: odoo/enterprise#21992
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
If a work center is used in any routing, a warning will be displayed when it will be archived
opw-2658596
closesodoo/odoo#79185
X-original-commit: a05f4e05b9f4df88948ac3dfc1522828b63bfb64
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce:
1. Create Manufacturing Order with quantity >1 of Serial Tracked product
2. Press Mark done. (One Product will be immediated produced with a new
SN auto-created)
3. Create Backorder
4. Press Mark done on the backorder
Expected Result:
Backorder will also be able to immediate produce and auto-create a new SN
Actual Result:
Usererror because env is still referring to original MO and tries to
produce the same SN again.
closesodoo/odoo#79151Fixes: odoo/odoo#78134
X-original-commit: 58cd10eb7277312d7d6c5e9da7b52dcbdb114734
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Previous PR: odoo/odoo#69483 changed the default 'product_uom_qty' from
0 to 1. This was intended for Planned Transfers that are still draft to
default the demand to 1. Unfortunately this made it so new lines added
to confirmed MOs would default their "To Consume" to 1 even when the MO
is locked and the form says 0 (value would auto-switch to 1 after
saving). This commit makes it so the added lines correctly save as 0
again.
closesodoo/odoo#79041
Task: 2677212
X-original-commit: 56a05aeed64b36ca34ff6466c2b890951bdfbc61
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
"Material Availability" vs "Component Availability" label means
the same thing but it shouldn't.
- Rename these and add a help string for both fields.
- Change decoration to be green if the MO Readiness is
'ready'.
- The logic of `_compute_*_availability` doesn't take in account the
'ready' `(reservation_)state` to distinct clearly both fields
(`(reservation)_state` vs `*_availability`)
task-2668922
closesodoo/odoo#79033
X-original-commit: acc385137a6a59f3632d91a7fcabd5ab42e8bc7f
Signed-off-by: Tiffany Chang <tic@odoo.com>
The recomputation of stock move state is often done with already
the correct state (for instance in the case of move line deletion only
one of the deletion will change the state).
This commit check the move state before changing it only when it's
necessary.
Task: 2507143
X-original-commit: 80033446a091ff3ba98c58ba44ad665bfba30c98
Part-of: odoo/odoo#78547
Co-authored-by: Remy Voet <ryv@odoo.com>
Current Behaviour :
1. Enable Work Orders
2. Add an operation to a BOM
3. Disable Work Orders
4. Create a manufacturing order for this product and finish the manufacturing.
5. Print the production order
What is the current behavior that you observe?
The production order has the operations in it even though the work order option has been disabled. This is because disabling the work order option just hides the operations and does not remove it from the BOM.
What would be your expected behavior in this case?
The printed production should not show the operation.
opw-2660545
closesodoo/odoo#78544
X-original-commit: d73752c5fe983ce6a9147721e732396394a77cc4
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Issue: When replacing a tracked part while doing a repair, we
are changing the tracking number, but when checking for uniqueness,
we don't take that change into consideration
Steps to reproduce :
1) Manufacture product A with SN "A1" out of product B with SN "B2"
2) Make Repair Order for "A1" to replace "B2" with Product B (SN "B1").
3) Create Manufacturing Order product A (A2), select product B with SN
"B2" as one of the components.
4) Mark as done
-> Bug : "The serial number <B2> used for component <B> has already
been consumed".
Why is that a bug:
When checking for uniqueness we should take into consideration the
parts being replaced
opw-2625687
closesodoo/odoo#78407
X-original-commit: 79c673f9d15185be540dd535d7ebe10c8f138bf1
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Steps to reproduce:
- Set the Decimal Accuracy at 5 digits for Product UoM
- Create a product X
- Create a kit BOM for X with a component Y, and qty 0.08600
- Create a Sale Order for 10 product X, confirm and deliver all
Issue
- On the SO, quantity delevered is 9.00000 instead of 10.00000, same
issue occur with the same flow with a Purchase Order.
Cause
As the quantity per kit was rounded when calling _compute_qty,
the calcul of quantity ratio was not well computed.
Solution
Avoid rounding the quantity per kit, as the quantity ratio is rounded
a few steps after.
opw-2590126
closesodoo/odoo#78516
X-original-commit: 2a2b198ea6ce1d0553c606404e6db1117dc1c4a2
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: guva-odoo <guva-odoo@users.noreply.github.com>
PR odoo/odoo#76376 made it so operations (of a BoM) can now be
(un)archived in the list view. This commit makes it so we can also do
the same in the form view as well as see the "Archived" ribbon in the
form view.
Part 3 of Task: 2660820
closesodoo/odoo#78094
X-original-commit: e995860157becf34300365ac09e12ae57512e22a
Related: odoo/enterprise#21569
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
In a lot of test class, we use `setUp` instead of
`setUpClass`. `setUp` is execute for each test method and `setUpClass`
will be execute only once by Class (and use savepoint + rollback).
Then change setUp into setUpClass reduce the time to make all tests
and avoid to repeat this error for the future.
closesodoo/odoo#78082
Related: odoo/enterprise#21563
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
The generate serial number button uses the stock.lot.serial sequence by default
(default value for name of stock.production.lot)
Serial Mass Produce (and other parts) allow to generate serial numbers
starting from a user supplied initial value.
This fix makes the button generate the next serial number
according to the last generated.
task 2647238
closesodoo/odoo#78258
X-original-commit: b80259dff3aaafb9d11af9d936f5106bdf5ed781
Related: odoo/enterprise#21641
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Jean-François Aubert <ajf-odoo@users.noreply.github.com>
Allow the quantity decrease of Sale Order line of a MTO product.
When increasing de quantities, the related pickings, RFQ / PO are
increased as well, but it wasn't the case if decreasing the quantity.
It should allow the cascade of the decrease in the related pickings as
it would work for the increase. Also modifies a related Purchase Order
if it wasn't yet validated (and thus still a RFQ).
merge_moves was modified so it would allow the merge of negative moves
with positive ones, while trying to "deplete" as much quantity as
possible for each mergeable move.
But negative moves don't always have all required properties to be
compared to the positive ones (some keys might be missing, such as
'created_production_id'). That means we will merge strictly the positive
moves at first as it was done before. But then we try to merge them "less
strictly", using less keys to compare.
Let's say we have those moves (and all other relevant keys matches) :
- move_1 : {qty : 5, created_production_id: 1}
- move_2 : {qty : 3, created_production_id: 2}
- move_3 : {qty : -6, created_production_id: False}
move_1 and move_2 cannot be merged as they don't share the same
created_production_id. But to merge move_3, we'll need to merge it into
move_1 and move_2. It will then deplete move_1 and decrease move_2.
Which will leave us with :
- move_1 : {qty : 0, created_production_id: 1}
- move_2 : {qty : 2, created_production_id: 2}
move_3 will be unliked as its purpose is done.
Task-2513592
Part-of: odoo/odoo#78070
In PR: #74540 the MO.date_planned_start default was updated to
round up to the next hour. It was later decided this would be too
confusing so this commit reverts it back to the original default of now
(i.e. without any hour rounding)
closesodoo/odoo#77956
X-original-commit: 44c66cce8e545afd7b38c7fc81425fa69023798e
Related: odoo/enterprise#21506
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
- update MO list status colors: draft = blue, in progress = yellow +
make the WO status colors match (waiting = blue, in progress = yellow)
and make draft MO lines all blue (to follow current design standard)
- cleanup Activity in tree view (no label in tree + "Next Activity" in
column selection dropdown)
- make units of analytic accounting for WO = hours
- make quantity for move_raw_ids products (i.e. components for MOs)
always have positive analytic_account_line.unit_amount (i.e. when
changing a done move's quantity + changing a quantity twice made this
value negative)
- make "Copy Operations" on BOM open the list view in "current" instead
of "new" due to lack of hook to prevent form view (i.e. open BoM in
current view) changing when clicking on lines in the new window's
operations (also ends up being a better UX anyways since being able to
view the operations form view is desired).
Task: 2648460
X-original-commit: 65a2d478197f5b856212225319500ca61b161809
Part-of: odoo/odoo#77897
Instead of using sort + groupby of itertools (which group only
consecutive), use only the groupby of odoo.tools which
decrease the complexity of the code and avoid unmatched keys
between sort keys and groupby keys
task-2648449
Part-of: odoo/odoo#76761
Improve 'Component Availability' and 'Product Availability':
Add these fields in form and tree view (the performance issues
is addressed in next commits and these fields will be load lazily)
task-2579011
Part-of: odoo/odoo#77092
The `_compute_json_popover` of (`mrp.production`)
was slowing down the tree view of MO (because it loaded
every move due to `production.move_raw_ids` even if there
isn't `delay_alert_date`.
Make it more lazier: we gain a speed up
when the there aren't any delay_alert_date
(always when the setup is simple)
To read 150 MO (7500 moves behind):
Before: 0.099 ± 0.002 SQL sec, 0.224 ± 0.005 Python sec (37 SQL requests)
After: 0.060 ± 0.0008 SQL sec, 0.096 ± 0.002 Python sec (29 SQL requests)
Also, unify the code with `stock.picking`.
task-2579011
Part-of: odoo/odoo#77092
This commit removes the action_confirm from the run_manufacture to do it
only after all the orderpoints have been processed.
In case a production, created in run_manufacture, triggers procurements
for one of its component. And those procurements have the same
parameters than another one still not run because after the manufacture
one in the queue. This new procurement will replenish its quantity plus
the other procurement's one.
That means too much quantity will be replenished.
closesodoo/odoo#77026
X-original-commit: a7bb9f1ac392c00be5bdd133fc5c73b9803c8b4b
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Issue: The button # To Process in mrp/views/stock_picking_views.xml
at line 33 uses the domain state confirmed, draft, planned, or progress
But the default filter, which is called "to do", show those 4 states +
to_close (in mrp/views/mrp_production_views.xml line 309)
Side-Note: Issue also present in 14.0, so starting the bug fix from
here. 12.0 doesn't seem to have a to_close state but the count and
filter domain also do not match
Steps to reproduce in 14.0
On Runbot, go to Inventory click on the "# to process" button on a
Manufacturing card.
- Choose any MO and create a work order. On this work order, click
"Start", then "Done".
- The MO is now in the "To Close" stage.
- Go back to Inventory Overview. The number to process has gone down by
one.
- Click on the "# to process" button, you will see that the "To Close"
MO appears in the list but is not counted by the button.
(written by dido)
For 13.0 I haven't been able to find steps to reproduce but the button
has not changed between the two versions
opw-2636447
closesodoo/odoo#76834
X-original-commit: 7f3b65bb42444ccb02bfb80931b52a94924fcdb0
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Byproduct moves with same cost_share can be merge but only if there is
no other move with different cost_share in the list of move. This commit
allow merge move with same cost_share in any cases.
closesodoo/odoo#76709
X-original-commit: 41bd26f6522cf9f4e11962399504030c36512c39
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
It is currently impossible to create a MO from a mobile if there are
some work orders
To reproduce the issue:
1. In Settings, enable "Work Orders"
2. Create two products P_finished, P_compo
3. Create a BoM:
- Product: P_finished
- Components:
- 1 x P_compo
- Operations:
- Create a new one
4. Switch to mobile mode
5. Create a MO with P_finished
Error: When saving the MO, a Validation Error is raised "The operation
cannot be completed: - Create/update: a mandatory field is not set.
[...] Model: Work Order (mrp.workorder), Field: Unit of Measure
(product_uom_id)"
For a work order to be created, the request needs to provide one
additional field: `product_uom_id`. When setting the
product P_finished, `product_uom_id` is returned but not included
in the save request (because the field is declared as `readonly`)
OPW-2557181
closesodoo/odoo#76572
X-original-commit: 57c5e06f4f6de60ebc8b933ed327613588256273
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Component move with same product are not merge at confirmation as it
could be multiple different production steps.
opw-2583848
closesodoo/odoo#76401
X-original-commit: 390fce62462962e9a0131a082317e2e60e34041a
Related: odoo/enterprise#20801
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Commit 04f3cac527 makes picking_type_id compute on stock_move_line to
get the picking type of either the picking or the manufacturing order.
Right after, commit dd53f5323f set picking_type_id related of the
picking one to be able to search on it. (in this later scope,
manufacturing part was not needed, hence the related instead of compute.
This commit mix the two idea by having a new search function on the
computed fields to filter stock move line depending on their picking
type.
X-original-commit: d535108f96d62f217dda7cbb676f9d60b7477f4f
Part-of: odoo/odoo#76294
no need to make rounding during computing qty_available
STEPS (see the test):
* create product with uom dozens
* create product with uom units
* create bom kit to convert one to another
* set qty on hand to 1 for product dozens
* check qty for product units
BEFORE: qty=11
AFTER: qty=12
---
opw-2632782
closesodoo/odoo#76242
X-original-commit: 26b28408d8970baa8cbf59ffaff90cab1e579410
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Because the "Replenishment" can unlink a lot (thousand of
`stock.warehouse.orderpoint`).
and psql needs to check every Many2one `orderpoint_id` constraint
and without index it takes too much time.
opw-2637321
closesodoo/odoo#76116
X-original-commit: 864d90a064f093bd6ba24d8464ee491a443a320e
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Issue: When creating a manufacturing order and setting a scheduled date
when no workcenter is set, a traceback shows up
Steps to reproduce :
1) Install Manufacturing
2) Enable work centers
3) Create a manufacturing order, in the work order tab, add a new line
and set a Scheduled Start Date, confirm the date
-> Traceback
opw-2633940
closesodoo/odoo#76117
X-original-commit: ebf54c802664e6c2143785b950667c136944fcbf
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
roen-odoo