Steps to reproduce the bug:
- Create a manufacturing order to produce “Table”
- Confirm and plan the MO
- Start the work order
- Cancel the MO
Problem:
- The work order is cancelled, but the timers continue to run.
- "Block", "Unblock" and “Unplan" button should be hidden when MO is cancelled
opw-2817842
closesodoo/odoo#89442
X-original-commit: 5682015958d03f4a65969afe3fce9b9b05e5b505
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
This task will:
- Clean the code (e.g. the production's moves are now created directly)
- Have the same behavior when creating object in the UI or directly in
backend
It's mainly on the `mrp.production` object and most of the computed
stored field are used as default value or act like an onchange on draft
production. Once the production order is validated, it's only modify
by direct write
Task-2709753
closesodoo/odoo#83576
Related: odoo/enterprise#24405
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Add test for use case fixed by d43e9cb9ad8d1c0c020209de0e8f6ffdcbc960a1
closesodoo/odoo#89237
X-original-commit: 21be0d8e96b9fb6e9fd6476a664ce89b017a7767
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Usecase to reproduce:
With BoM structure
- Product A (RR 1-20)
|
Product B (MTO)
|
Product C (RR 5-50)
|
Product D (Buy)
Launch the RR. The MO are:
Current Behavior
- Product A 20
- Product B 20
- Product C 50
- Product C 70
Expected Behavior
- Product A 20
- Product B 20
- Product C 50
It happens because the MO are created as draft during the
`_run_manufacture` and are confirm at the end of
`_procure_orderpoint_confirm` in '_post_process_scheduler`.
However at the first MO for product A, it creates a MO for product B
and since it consumes product c, it checks if the orderpoint should be
trigger. MO for product C still "draft" and the orderpoint forecast is
now -20, so it will create a new procurement for product C with 70 units
To fix it we take the MO draft linked to the orderpoint for the
forecasted quantity.
closesodoo/odoo#89079
X-original-commit: 199a0dd0f013655a3c2345a41bc7c721e09bfc68
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In some cases, it is not possible to produce a tracked product that has
been used as a component of another product.
To reproduce the issue:
1. Create three products A, B, C:
- A storable
- B storable and tracked by lot
- C consumable
2. Update on-hand qty of B
- 10 x lot L01
- 5 x lot L02
3. Create two bills of materials
- Product: A
- Components: 1 x B
- Product: B
- Components: 1 x C
4. Produce 15 x A (MO01)
- Note: it should use 10 L01 and 5 L02
5. Produce 15 x B with lot L03 (MO02)
Error: When marking MO02 as done, a user error is displayed: "Cannot set
the done quantity from this stock move, work directly with the move
lines." The user should be able to mark the MO as done.
When confirming MO02, it confirms the associated SMs. Since the
conditions are respected, we try to assign both consumed and finished
moves. Because of step 4, there are two quants for the product B in the
production location (one for L01 and another for L02). Therefore, when
reserving the qty of the finished move, two SML are generated. As a
result, when marking MO02 as done, we write the `quantity_done` on the
finished move. This triggers the inverse method and leads to
`_multi_line_quantity_done_set`, where the error is raised because the
done quantities are not defined on each SML:
https://github.com/odoo/odoo/blob/1354081e43b71edbd434dccc6df6d0881c672a81/addons/stock/models/stock_move.py#L363-L364
Thanks to `_set_quantity_done`, we can write these done quantities on
each SML (and then the incorrect lots will be replaced by the producing
lot).
OPW-2752436
closesodoo/odoo#89015
X-original-commit: 65efb3ec5416fab6bb9ba0a015565b2abb3928cd
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce the bug:
- Create the workcenter_1:
- Time Efficiency: 100%
- Capacity: 2
- Setup Time: 1
- Cleanup Time: 1
- Create the workcenter_2:
- Time Efficiency: 100%
- Capacity: 4
- Setup Time: 10
- Cleanup Time: 5
- Alternative Work centers: workcenter_1
- Create a storable product “P1” with BOM:
- Add any product as component
- Add operation:
- Duration: 60
- Work center: Workcenter_2
- Create a MO:
- select “P1” as Product
- Qty to produce: 4
- Confirm and Plan
Problem:
The workcenter_1 is chosen while work_center_2 is faster it can manufacture the 4 units at the same time
while workcenter_1 must do two cycles
As the Time Efficiency = 100%, so:
Total duration = (Setup Time + Cleanup Time) + duration_by_unit * nb_cycle
Work_center_1 = (1 + 1) + 60 * 2 = 122
Work_center_2 = (10 + 5) + 60 = 75
The calculation is bad because we use the number of cycles necessary for the work_center defined in the BOM
in the calculation for the alternative work center
opw-2821749
closesodoo/odoo#88945
X-original-commit: deb87a6abf8b8ccc4328eaac21430eedc2536361
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Currently, when changing qty_producing on a MO, consumed number of each
component will always be updated. In this commit, we add a new boolean
field manual_consumption to bom.line. If checked, that line won't be
updated when changing qty_producing.
The same but invisible field manual_consumption is also added to each
line on MO. It will use the value on BOM as defualt value. When user
manually set the consued qty, it will be checked automatically. Also,
when user manually update the SML, the field on SM will also be set to
true.
Task-2687494
closesodoo/odoo#80118
Related: odoo/enterprise#25607
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Current behavior:
When you use a workcenter with start and stop time in a BoM the start/stop time is applied for each quantity in the BoM report and workorder. For example if you have 3 quantities the start/stop time
will be applied 3 times.
Steps to reproduce:
- Create a product to manufacture (With atleast 1 operation)
- Create a workcenter that has positive Start/Stop time values
- Start and stop time are multiplied by the quantity in the BoM report
opw-2779381
closesodoo/odoo#86321
X-original-commit: 3bb32903f90fa86eb28b4551b07a5817f8e9f528
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Re-integrate code from 37681e9d2e24663691b4be022f34c29c7126d9f6
lost with f11fcf6bb4
allowing different quantities to be recorded on work orders
and generate back orders with correct quantities on back work orders
(cancelled if no remaining quantity).
closesodoo/odoo#84502
Task: 2751230
Related: odoo/enterprise#24624
Signed-off-by: Steve Van Essche <svs@odoo.com>
Steps to reproduce the bug:
- Go to inventory > configuration > Operation types > Manufacturing
- Set "Reservation Method" to "Manually”
- Create a storable product “A”:
- Update on-hand quantity to 10
- Create a storable product “B”:
- Create a bill of materials and add the product B as component
- Create and confirm a MO with 2 * product B
- Product A is not reserved for this MO (works as expected)
- Validate the production of 1 unit and create a backorder
Problem:
product A is reserved for the backorder because there is no verification of the reservation method before assigning it.
Solution:
No need to assign here, because when an MO is confirmed, move_raw/move_finished are confirmed too: https://github.com/odoo/odoo/blob/89ddaa49b901787f58a3fa9efb4115d5f2038611/addons/mrp/models/mrp_production.py#L1172
And when a stock_move is confirmed, it is assigned or not by checking the reservation_method:
https://github.com/odoo/odoo/blob/dda9700d8236091626cbd78efc0ca4116e1e1acd/addons/stock/models/stock_move.py#L1239-L1245
opw-2744513
closesodoo/odoo#85508
X-original-commit: 5926bb178236a74999a7868f0acf4ee86b61d7b8
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
When unbuilding a MO, if the latter has several lines (in its
components) for the same tracked product, it won't work.
To reproduce the issue:
1. Create two storable products P_compo and P_finished
- P_compo is tracked by USN
2. Update P_compo's quantity to 2
3. Create a MO:
- Product: Finished
- Quantity: 1
- Components:
- 1 x P_compo
- 1 x P_compo
4. Process the MO
5. Unbuild the MO
Error: a validation error is displayed while it should not "The serial
number has already been assigned: Product: P_Compo, Serial Number: C01"
The for-loop in `action_unbuild` do not handle the case where there are
several SMs for the same product. In the above case, there are two
component lines for P_compo, so there are two SM in `MO.move_raw_ids`.
When unbuilding the MO, the module creates and processes two SMs (SM01,
SM02) that "produce" two P_compo (stored in `produce_moves`).
When processing the first one in the for-loop, it takes the original
moves (so the `MO.move_raw_ids` with the same product) and uses them one
by one. Since SM01 needs one P_compo, it uses the first SM of
`MO.move_raw_ids` (and reuse the lot of that SM). Later on, when
processing SM02 in the for-loop, it does exactly the same thing: it
takes the original moves and uses the first one. Here is the issue: this
first SM has already been used and so does its lot, so this SM should
actually not be used again.
OPW-2715155
closesodoo/odoo#85354
X-original-commit: 8d2597965202a76ddeea8d8fed60b7ac014e2df8
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Usecase:
- Create a BoM with a product tracked by SN
- Create a MO with qty 5
- Mass produce
- Generate
-> All the `stock.move.line` in the move_raw_ids don't have
the qty done prefilled. The purpose of the feature is to create
and validate a lot of MO at once. Which is impossible if you have
to fill all the quantity manualy.
The choice of a new kwargs that directly set the qty_done is justified
by the performance.
-> For On a BoM with 10 components for a final product. For 1000 finished
product with SN
- If we do a loop on each `stock.move.line` to set
qty_done as the reserved quantity. It goes from 40s to 135s
- With the kwargs. It remaines 40s
closesodoo/odoo#83123
X-original-commit: 8ce5926b5a337dc97237f39492e094288b453743
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Set the warehouse with manufacturing 3 steps
Create a BoM with a Components that use a Sub BoM
Set Both product MTO + Manufacture
Create a MO
You have only 2 picking for the first MO with the SFP
that contains both the finished product and the intermediate
component. However they are created and moved at two different times
since you could not create the finished product withtout the
component, so there is no meaning to put them both in the same picking.
It happens because the _assign_picking will merge moves with the same
procurement group. In our case, it's the wanted behavior to have the
2 differents SFP linked to the same MO.
The idea between the fix is:
- We want to have the pick components picking merged.
- We want to have the store components split since they come from
different MO
So we create the different procurement groups during the _run_pull with
the picking type of store finished product. This way the pickings won't
be merged during _assign_picking
We will also propagate those groups to the newly created MO in order to
keep the picking type sequence and correct name.
FW PORT of
https://github.com/odoo/odoo/commit/bcfa03821b92bf52675db0e3b54d3cb19dfe3087
opw-2585525
closesodoo/odoo#85195
X-original-commit: a647e680a196f7e6d9147d51dd80f8c31e0e741b
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When printing a delivery slip, if the delivered product is a kit
composed with a subkit, the products of this subkit won't be listed
To reproduced the issue:
1. Create 5 consumable products: 'Compo 01', 'Compo 02', 'Compo 03',
'Sub Kit', 'Super Kit'
2. Create two phantom-type boms:
- Sub kit:
- 1 x Compo 02
- 1 x Compo 03
- Super Kit:
- 1 x Compo 01
- 1 x Sub Kit
3. Process a delivery with 1 x Super Kit (the picking must be done)
4. Print the delivery slip
Error: The report only contains two lines, i.e. the name of the kit
('Super Kit') and the name of the 'direct' component ('Compo 01)
The issue comes from the SML used to define `kit_move_lines` (XML side).
It uses `has_kits` which only contains the top level kits' SML:
https://github.com/odoo/odoo/blob/1b1067b0cf2a3de2773915ff8205084492b1bbe3/addons/mrp/report/report_deliveryslip.xml#L6-L9
This is the reason why the SML for Compo 02 and Compo 03 are not listed
OPW-2740247
closesodoo/odoo#84735
X-original-commit: 586f900433eb09ee04d0ed073acfdcfa0fc59d58
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
decimal places while we compute stock_quants.
closesodoo/odoo#84708
X-original-commit: fba9c9f32cb3d53841946588a999998f6c936e26
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
To reproduce the issue:
1. Produce a SN product P with lot L
2. Unbuild it
3. Produce 1xP with lot L
Error: When setting the lot, an error is displayed. When marking the MO
as done, a second error is displayed
Both domains in `_onchange_lot_producing` and in the beginning of
`_check_sn_uniqueness` are incorrect. We should centralize the
uniqueness checking thanks to all existing computations in
`_check_sn_uniqueness`. This way, unbuilt/scrapped moves will be
considered
OPW-2721205
closesodoo/odoo#84374
X-original-commit: 2540104e95cea7baaa22ccfce97759771dbbaf34
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
In 9f7e6d2bb6ae0a6b0257edf26a5aa069cd00d78e , when start a workorder, we
always suggest the qty to produce to be the full qty to produce on MO.
If the previous WO produced less than the full qty to produce on MO,
user won't aware of that when start the WO. We revert it in this committ
Task-2678388
closesodoo/odoo#83389
Related: odoo/enterprise#23961
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Split a manufacturing order in several parts
using the back order mechanism
Merge several manufacturing orders related to the same product/bom
by cancelling all of them and creating a new one
closesodoo/odoo#82427
Task: 2662566
Signed-off-by: Arnold Moyaux <arm@odoo.com>
It is sometimes impossible to unbuild a product because of decimal
values.
To reproduce the issue:
(Enable debug mode)
1. In Settings, enable "Units of Measure"
2. Set the decimal accuracy of "Product Unit of Measure" to 4
3. Set the rounding precision of "Units" to 0.001
4. Create two products P1, P2
5. Create a BoM:
- Product: P1
- Quantity: 3
- Type: Manufacture
- Components: 5 x P2
6. Process a MO with 3 x P1
7. Create an unbuild order UO:
- Manufacturing Order: MO
- Quantity: 1
8. Unbuild
Error: An error message is displayed "The quantity done for the product
"P2" doesn't respect the rounding precision[...]"
At some point, for each SM associated to the UO, the modules uses the
value of `product_uom_qty` to write the done quantity of the SM. The
rounding of `product_uom_qty` is based on "Product Unit of Measure" so
the component's SM has its quantity equal to `1.6667`. Moreover, writing
the done quantity trigger the creation of the associated SML. As a
result, the SML has its done quantity equal to `1.6667` while the
rounding of the associated UoM is `0.001`. When calling `_action_done`
on such a SML, it will raise an error because the value doesn't respect
the rounding.
Side note: the error message is incorrectly written, the indents in the
file are displayed on the front-end.
OPW-2710038
closesodoo/odoo#83369
X-original-commit: c11d772f39179c5dec5eb431b6f4bc02c680643a
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
There were some discrepencies when adding to/removing from WO Real
Duration:
- When adding time that is brings the total Duration over the expected
duration, the time should be split between the "productive" and
"performance" (i.e. reduced speed) times. This is already happening
when using start/pause buttons, so now it is consistent.
- Use 'id' instead of "Start Date" to determine which time_ids
to reduce/remove since adding a large enough "real duration" value
compared to previous time_id(s) could result in an earlier "Start
Date" for a newer time_id (i.e. results in which one is adjusted/
deleted = confusing). Using "End Date" was considered, but same
non-sequential issue can occur during time split from point above.
- Correctly determine if the "productivity" should be 'productive' or
not (i.e. 'performance') based on total WO duration (not duration
of newly added time_id)
Refinement of Part 4 of Task: 2667151
closesodoo/odoo#80319
Signed-off-by: Arnold Moyaux <arm@odoo.com>
There is 2 major issues with the production of multiple serials number
- Performance issue
- Duplicated code with classic backorder mechanism
The performance issues exist since backorders were create one by one
and `stock.move` and `stock.move.line` are always recomputed. They
are not created in batch neither.
_generate_backorders is removed and replace by _split_productions. The
functionality are the same. Technicaly it does the maximum in batch,
first it creates all the `mrp.production` then all the `stock.move`
and finaly, it splits the existing `stock.move.line` among the new
`stock.move`
It means that the reservation is not recompute anymore during a
backorder process and will remain the same than the splitted production
order.
Performance metrics (10 components):
| 2 | 10 100 1000
before | 0.47s | 2.84s | 32.25s | 580.53s
-----------------------------------------------
after | 0.13s | 0.36s | 2.60s | 35.17s
task 2633369
Part-of: odoo/odoo#77254
This commit rename product_uom_qty into reserved_uom_qty and product_qty
into reserved_qty on stock move line to stop mistake them with the stock
move quantities fields.
Task: 2648449
Part-of: odoo/odoo#80434
The stock convention on location name is always to name the destination
`location_dest_id`. It was not the
case on the stock rule model
Task: 2648449
Part-of: odoo/odoo#80434
Previously, when underconsumption occured, we split the move (in
post_inventory). And if backorder, the moves not done would be linked to
the new backorder MO (when backorder MO is created).
After 8883c06ada, we create backorder MOs
before _post_inventory, making it so the moves not done will not be
linked to the backorder MOs and reserved qtys are not released.
To fix, we set cancel_backorder to be true to cancel all the leftover
moves and release the reserved qty.
Task-2697611
closesodoo/odoo#80446
X-original-commit: cffb2b455d73f64d96f91b9e0301c346989eae63
Signed-off-by: Tiffany Chang <tic@odoo.com>
When cancelling a manufacturing order that does not include any
component, the associated moves won't be cancelled.
To reproduce the issue:
1. Create a storable product P
2. Create & Confirm a MO for 1 x P
3. Cancel the MO
4. Consult the form page of P
Error: The forecasted quantity of P is 1 instead of 0
The finished move associated to the MO hasn't been cancelled. Since [1],
we have the possibility to process MOs without any component, so the
cancellation process shouldn't be bypassed anymore.
[1] bf5e1debf9
OPW-2691422
closesodoo/odoo#80407
X-original-commit: 2adff866a598fc8fb872fb8127875fbb7cc7335c
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
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>
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>
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>
"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>
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>
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
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
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>
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>
In case a production order loses its procurement group. The backorder
generation process do not have access to the last backorder sequence
used. This commit set a default value to avoid any traceback.
The new backorder name will not be guaranteed exact related to the
production sequence but will be unique in any cases.
closesodoo/odoo#76091
X-original-commit: aae07e88a8166cf26a8c81bb8ee37d630fd6672c
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Allow to produce several serial numbers at once.
Only when BoM do not contain any component tracked by unique serial number
and lot ones are from 1 lot.
Also allow to copy/paste serial numbers.
This applies to manufacturing orders.
Task: 2444742
Part-of: odoo/odoo#71732
Review Work Order pop up design:
- add mo reference and Components tab at first
Manufacturing Readiness:
- set 'When all components are available' as default
closesodoo/odoo#75675
Task: 2527408
Related: odoo/enterprise#20515
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Issue: In work centers with a capacity different than 1, the expected
duration was wrongly computed
Steps to reproduce :
1) Install Manufacture, enable Work Centers in Settings
2) Create a Work Center, Capacity = 2
3) Create a Product, with Manufacture as route
4) Create a Bill of Material :
Add any component
Add a operation line :
Work Center = created at 2)
Duration Computation = based on tracked time last 1 WO
5) Create a Manufacturing Order for the product 3), confirm
6) Set the real duration to 00:10, mark as done
7) Check the BoM Structure & Cost of the BoM 4)
-> Operations is 00:20
Why is that a bug:
To compute the expected duration, in mrp_workorder.py L691 we already
take into consideration the capacity of the work center.
When computing the time_cycle, we must give a time_cycle for 1 product
made with capacity 1, so we must first normalize the qty_produced fetch
from the DB to make like if we only produced the quantity once but in
the same amount of time
Side-Note: This also solves an issue with the Duration Computation based
on tracked time. The `limit` keyword was applied after the `group by`
so we effectively grouped all the operation_ids together, summing
their quantities and then limiting on the different operation_ids
opw-2562983
closesodoo/odoo#75557
X-original-commit: c78a25f92716bd6014de381c34f3bc268d1528ae
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Nathan Marotte <nmarotte@users.noreply.github.com>
When a document (SO/MO) create a demand and this demand is directly
refill by an orderpoint, then write the source document that triggered
the orderpoint in addition in the origin field.
The purpose is to have an easy base tracking configuration even if
the priority and schedule date (and the final customer) could change
afterward (origin field still editable)
Part-of: odoo/odoo#75144
Missed the case of copying a cancelled MO needing its cancelled
move_finished_ids to still be copied during commit:
79efbd0e4707892041ee7c58c81c1d7edd033edd
Steps to reproduce:
Step 1: make a MO and cancel it
Step 2: duplicate the MO and try to mark as done
Expected result: qty is produced
Actual result: Validation Error about quantity to produce must be
positive (due to no move_finished_ids)
Follow up to task: 2618962
closesodoo/odoo#75569
X-original-commit: 56e7d4acc59a802c7613c1184858bda5bfb26748
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
If the prefix of the production sequence contains some dashes, it can
lead to undesirable behaviors
To reproduce the error:
(Enable debug mode)
1. Settings > Technical > Sequences & Identifiers > Sequences, edit "San
Francisco Sequence production":
- Prefix: "WH-MO-"
2. Create a MO
- Quantity: 2
3. Confirm, Edit:
- Quantity: 1/2
4. (Keep MO's name in mind and) Validate + Create backorder
Error: Backorder's name is "WH-MO-002" instead of "WH-MO-0000X-002".
Going back to the initial MO, its name became "WH-MO-001" (was
"WH-MO-0000X")
OPW-2618971
closesodoo/odoo#75270
X-original-commit: 076fe045f219dcb018b3b18215bfc3a0cfb3aa46
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
When combining a reordering rule, the 3-steps manufacture and
by-products option, the picking from the post-production to the stock
will not contain the residual products produced by the MO (by-products)
To reproduce the error:
1. In Settings, enable:
- By-Products
- Multi-Step Routes
2. Inventory > Configuration > Warehouse Management > Warehouses, edit
company's warehouse:
- Manufacture: 3 steps
3. Create 3 products P_compo, P_finished, P_secondary
- P_compo is consumable
- P_finished and P_secondary are storable
- Routes of P_finished: Manufacture
4. Create a reordering rule for P_finished:
- Min = Max = 1
5. Create a BoM:
- Product: P_finished
- Type: Manufacture
- Components: 1 x P_compo
- By-products: 1 x P_secondary
6. Inventory > Operations > Run Scheduler
7. Open the generated MO
8. Check Availability, Produce, Mark as Done
- Note that in the "Produce" wizard, we mention that one P_secondary
is also produced
- Also note that in "Finished Products" tab, there are 1 x
P_finished and 1 x P_secondary
9. Open the Transfers
Error: The picking Post-Production -> Stock does not exist
When creating the byproducts move
https://github.com/odoo/odoo/blob/ad62f877c174d56b90ec516cf24494d751383db9/addons/mrp/models/mrp_production.py#L587
the field `move_dest_ids` is present (is the move created after
evaluating the RR)
https://github.com/odoo/odoo/blob/ad62f877c174d56b90ec516cf24494d751383db9/addons/mrp/models/mrp_production.py#L580
so it is used, but this will cause the `_push_apply` to skip the
evaluation of the move
https://github.com/odoo/odoo/blob/f0eaa756c4947e2a595359959b34b14bfda81a07/addons/stock/models/stock_move.py#L678-L679
and `_assign_picking` will not run, as it normally do when creating the
manufacture
Thanks to this change, the picking Post-Production -> Stock will exist
and contain the residual products
OPW-2581762
closesodoo/odoo#75068
X-original-commit: 098af2fa85d2aebfc71b7e2342a1bbf05100e10d
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
On BoM, a component line can be filter out depending
of the product variant to manufacture
(with "Apply on Variant" field).
Extend this feature to operation and byproduct line.
task-2614126
closesodoo/odoo#74973
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Victor Feyens