Related enterprise PR: odoo/enterprise#39669
Steps to reproduce:
Install mrp_workorder
Create Product P1, Workcenter W1
Edit W1 > Specific capacities > Add line: Product = P1, Start time = 5, End time = 5
Create BoM > Product: P1, Operations tab > Add line: Workcenter = WC1, Default duration = 60:00 min > Save
Click on overview stat button
Issue:
The created operation has expected time of 60:00, instead of 70:00. The workcenter start and stop times are considered in this calculation, so the workcenter capacities should be considered too.
Solution:
Use `_get_expected_duration` to compute the expected duration.
opw-3229485
closesodoo/odoo#121060
X-original-commit: 7b5a30fb3e51434154050052ec39ed299c6094d3
Related: odoo/enterprise#40905
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce:
Step 1: Create new MO
Step 2: In page by-products click three dots to show column cost_share
in tree by-products
Step 3: Create new Byproduct and input cost share >100% or <0% or input
two byproducts
where their cost share adds up to more than 100%
Expected result:
Validation error: total byproduct cost_share cannot exceed 100
or Validation error: cost_share values must be positive
Actual result:
Values saves without issue
Issue is due to `move_byproduct_ids` being removed in the mrp_production
overrides of
`write()` or `create()` and having the `_compute_move_byproduct_ids`
populate its values.
This removal is causing the constrains to not be enforced, therefore we
set the constrains
field to `move_finished_ids` since changing of this value will ensure
that the values are
correctly checked.
Note: There will be a decrease in performance since this means the
constrains will be
called whenever the MO's product to produce is changed, but hopefully it
will be
minimal since there is no simple fix for this issue.
closesodoo/odoo#120797
X-original-commit: 9d6ff93d0f5b39e939f632486a97093b59d335ef
Signed-off-by: Tiffany Chang <tic@odoo.com>
The finished move of a production order should be deleted if we change
the product to avoid having draft stock move detached from any business
documents
closesodoo/odoo#118957
Task: 3172098
X-original-commit: 4478560d7769a8a795a94aead875e02d1394dd71
Signed-off-by: Adrien Widart <awt@odoo.com>
To reproduce:
1. Manually create lot "0000001" for a lot product
2. Create a MO for this product and click generate-serial button.
Validation error raised since we are trying to generate lot/sn "0000001"
again.
When useing action_generate_serial, ir.sequence always try create a
lot/sn in form "00000dd". If user already created the same one, the
generation will fail.
We already tried to avoid this issue for sn in _get_next_serial() by
finding the latest sn and create new one base on it.
To fix, we also allow _get_next_serial to be applied to lot.
Part of Tast-3187003
closesodoo/odoo#118481
X-original-commit: dc69748ea2698077782d839cf7da48e987f17ffc
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
Steps to reproduce the bug:
- Go to the warehouse settings:
- enable “3 steps for manufacturing”
- Create a storable product “P1” with 2 BoM
- Create an orderpoint:
- Preferred route: Manufacturing
- Product: “P1”
- BoM: select the second BoM
- To order: 1
- Click on the “Order once” button
Problem:
The manufacturing order is created with the first BoM instead of the
second.
As we are in 3 steps, the “run_pull” function is triggered first, with
values prepared from the orderpoint so the bom is well set:
https://github.com/odoo/odoo/blob/16.0/addons/stock/models/stock_orderpoint.py#L515-L523
Then the “run_manufacture” function is triggered but with vals prepared
from the move, not from the orderpoint, so we lose the BoM information
that the user has selected:
https://github.com/odoo/odoo/blob/16.0/addons/stock/models/stock_move.py#L1334-L1340
opw-3217945
closesodoo/odoo#117732
X-original-commit: 2371cd29e1c0cfa54b682b2100b9db7f5633a7b4
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Add the group 'mrp.group_mrp_routings' on the main user to make field
'workorder_ids' visible in the form view of 'mrp.production'. Many
tests use that view, and require the subviews of that field to be
present in order to create records.
closesodoo/odoo#116779
Related: odoo/enterprise#38858
Related: odoo/documentation#3968
Signed-off-by: Raphael Collet <rco@odoo.com>
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Create a second warehouse WH02
- Let WH01 be the existing one
3. Create two storable products P_compo, P_finished
4. Create a BoM:
- Product: P_finished
- Components: 1 x P_compo
- Operation Type: "WH02: Manufacturing"
5. Create a MO:
- Product: P_finished
Error: Once the product is set, nothing defines the BoM (and
therefore the components, picking type, and so on)
When opening the MO form, the picking type is directly defined with
"WH01: Manufacturing". Therefore, when looking for a BoM, we use
that picking type as criteria -> we will not find the BoM of step 4
Notes about the fix:
- Small behaviour change: once the picking type is set, it does not
change automaticaly (whatever the BoM is)
OPW-3122384
closesodoo/odoo#116515
X-original-commit: 93381af48e20a10c3fded88f010f89cd03cc5131
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
No need a common file for 3 tests. On top of it contains
global variable and a lot of indirection, making it impossible
to read.
Also before the quant reservation commit, a savepoint was call
during the action_assign and trigger a flush and recompute all.
Since it has been remove, it's computed during the first read on
it, that's during the mark as done and since the MO state is not
draft it will keep the default value (False). Call it after create
to trigger the computation at the right time.
+ a bit of linting
closesodoo/odoo#115328
Related: odoo/enterprise#38207
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
A lot of issue with "It is not possible to unreserve more products of ... than you have in stock".
It's the result of a desynchronisation between
`stock.move.line`.`reserved_qty` and `stock.quant`.`reserved_quantity` fields.
It should never happens in theory. However we already faced it a lot due
to bugs/custom code/server actions... It's not trivial to fix because
the issue come from data corruption. So it is hard to spot the different
main issues.
In order to avoid it, this commit try to modify the structure of stock
module. Before the operations was made in this order:
- The `stock.move` checks the quantity available on `stock.quant`
- The `stock.move` write the quantity reserved on the `stock.quant` and
save it in a variable
- The `stock.move` create a `stock.move.line` with the quanity reserved.
The main issue is that a `stock.move.line` could be easily created with
a reserved quantity while the `stock.quant` are not update nor checked.
After this commit the operations will be:
- The `stock.move` checks the quantity available
- The `stock.move` dispatch the available quantity among the `stock.move.line`
based on create or write calls.
- The `stock.move.line` reserve the quantity on `stock.quant`
- If the quantity is bigger than available, we write the max available on
`stock.move.line`
The idea is to respect the different layers
`stock.move` <-> `stock.move.line` <-> `stock.quant`.
Avoid the interactions bewteen `stock.move` and `stock.quant`
This behavior is already well managed in other use cases.
E.g. the real quantity itself, `_do_unreserve` of `stock.move`,...
opw - a lot
Part-of: odoo/odoo#115328
Fix the isuue that manual consumption is not correctly calculated when
backorder/split/merge.
closesodoo/odoo#115429
X-original-commit: d72ddd80d8a6aaa808c07db685972a1c05e8d6a4
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
Since starting a workorder and marking it as done replaces the
planned dates with the actual ones,
there is no need to keep dates which will always end up being the same.
task: 3108291
see odoo/enterprise#36102
see odoo/upgrade#4247closesodoo/odoo#110550
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
when plan workorder, cancelled/done workorders are taken in to account
when they block current workorder. In this fix, we ignore then when plan
workorder.
Task-3126569
closesodoo/odoo#114940
X-original-commit: 1b629659cb651c62fdd2c880ae591f9a9bb2e1eb
Related: odoo/enterprise#38020
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Currently, if the user change qty_done on any raw moves without
changing qty_producing on the MO, it's not possible to validate the
order. In this commit, we make it possible to validate the order as an
immediate production.
When qty_producing is 0 and validate the MO:
1. manual consumption moves: current consumed qty will be kept when
process the MO.
2. non-manual consumption moves: For tracked components, if
use_auto_consume_compoents_lots checked, and there is enough products
reserved, the qty_done will be filled, otherwise, an error will be
raise to ask user to fill in lot/sn. For non-tracked components,
qty_done will be filled.
Task-3116125
Part-of: odoo/odoo#113538
Previously we set a component on MO to be manual consumption by comparing
the To Consume and Consumed, if they are not the same, we consider it a
manual consumption. Now if any input activity in the Consumed cell, we
will consider it a manual consumption.
Note that in the code, we make the css class change happended in the
list renderer instead of the field widget. We do that because we want to
change the background color of the whole cell not just the text of the
field.
Task-3116125
Part-of: odoo/odoo#113538
This commit only adds the missing test from the original PR
since the feature was added back in without the test
opw-3032052
closesodoo/odoo#113562
X-original-commit: 542516b6b07c44e08b21271fbc9129c446e12c1b
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
When validating a confirmed picking, if in the meantime the user
added an SML with a kit, the done picking will have some not-done SM
for each kit component.
To reproduce the issue:
1. Inventory > Operation Types, edit Receipts:
- Show Detailed Operations: True
2. Create three products:
- P_kit
- P_compo
- P_other
3. Create a kit BoM
- Product: P_kit
- Components: P_compo
4. Create a planned receipt R
- Operations:
- 1 x P_other
5. Mark R as todo
6. Add two detailed operations:
- 1 x P_other
- 1 x P_kit
7. Validate R
Error: The SM for P_kit has been replaced with its component, which
is correct. However, the done quantity of the new SM is 0, it should
be 1
At some point, because the done quantity of SM_kit is gerater than
the demand, we create an extra move:
https://github.com/odoo/odoo/blob/24f2e3f73498e5eb180a6793de6c25efd414aadb/addons/stock/models/stock_move.py#L1529-L1534
So, the goal is to create a second SM_kit_02 with the expected
demand. Then, we merge this new SM_kit_02 with SM_kit:
https://github.com/odoo/odoo/blob/24f2e3f73498e5eb180a6793de6c25efd414aadb/addons/stock/models/stock_move.py#L1491-L1493https://github.com/odoo/odoo/blob/5f8da70b5b1f313e9b676846e55e84621f55e734/addons/mrp/models/stock_move.py#L239-L242
As shown above, we explode SM_kit_02 which gives SM_compo. However,
we don't explode SM_kit. Thefore, we will not be able to merge
SM_compo with SM_kit. In such situation, we should also explode
`merge_into`.
For the explode method to work with SM_kit, we need to change few
lines: as said at step 4, the receipt is not an immediate one.
However, we still have a case here where the SM has a quantity done
without any demand and only the done quantity matters (as we are
validating the receipt)
OPW-3015933
X-original-commit: 35a5b83b93fceac4073689edd74d680bed09a143
Part-of: odoo/odoo#112814
Refactoring of report_stock_forecasted to owl
Since it wasn't really a report (no print action),
it changed from a report to a client action.
Task: 2885757
See Upgrade : odoo/upgrade#3926
See Enterprise : odoo/enterprise#32116closesodoo/odoo#101247
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”:
- Variant: Color: Black and white
- BOM 1:
- product variant: P1 - White
- Type: Kit
- Consumable: C1
- BOM 2:
- product variant: P1 - Black
- Type: Kit
- Consumable: C1
- Create another kit product “P2” without variants
- Create an SO:
- Add “P1 - white”, “P1 - black”, “P2”
- Confirm the SO
- Go to the delivery → validate it Print the delivery slip
Problem:
only product "P2" is displayed in the report.
The `product_id.name` is used as `move.name`:
https://github.com/odoo/odoo/blob/16.0/addons/sale_stock/models/sale_order_line.py#L333
but then only compare it with the name of the `product_template` set in
the bill of material to filter the moves.
Solution:
Check if the `move.name` is equal to the `product_id.display_name`
set in the bill of materialale au product_id set dans la bill of
material.
opw-3051639
opw-3047822
closesodoo/odoo#110837
X-original-commit: eae5cf84625f8155bc72b63eaed28819698810cf
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
When changing quantities of raw moves after MO confirm,
procurement is run to fulfill updated need.
Since procurement creates new moves, some fixes were also done to allow
moves to be merged with older ones, including:
1) `date_planned_start` of merged MO included microsecond which
blocked merging new moves created by procurement with orig moves.
Removed microseconds.
2) `_set_date_deadline` did not allow a simple date update to moves with
orig or dest moves. Added context to hard set all moves in self to specific
deadline.
3) `_update_candidate_moves_list` when merging moves, did not return candidates
from pickings that were merged to same MO. Usually just mattered when decreasing
quantity. Added explicit check for sibling pickings in MO
closesodoo/odoo#93712
Task: 2859547
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When redirecting the SML of byproducts, the capacity constraints of
the locations are not considered.
To reproduce the issue:
1. In Settings, enable:
- By-Products
- Storage Locations
- Storage Categories
2. Create three storable products P01, P02, P_comp
3. Create a storage category SG:
- Max Weight: 1000
- Capacity by Products:
- 2 x P02
4. Create two locations L01, L02:
- Parent Location: WH/Stock
- Storage Category: SG
5. Create a putaway rule:
- From: WH/Stock
- Product: P02
- To: WH/Stock
- Having Category: SG
6. Create a BoM:
- Product: P01
- Components: 1 x P_compo
- By-products: 1 x P02
7. Update on hand qty of P02:
- 1 x P02 at L01
8. Create and confirm a MO with 2 x P01
9. Set the producing qty to 2
10. Open the detailed operations of P02
Error: The destination location is L01, this would break the
capacity constraint. The location should be L02
When setting the producing qty, we also set the done quantities of
the finished moves and we redirect them thanks to the putaway rules:
https://github.com/odoo/odoo/blob/cc6e31efe6fdd9dee16de1565afe9e1b502de45d/addons/stock/models/stock_move.py#L1885-L1888
However, the SML created only has the `qty_done` defined and, when
applying the putaway rules, we consider the `product_uom_qty` which
is equal to 0 in such a case.
So, when trying to redirect the SML of P02, we check if the capacity
constraint of L01 would be exceeded with the quantity of the SML.
But, as explained above, that quantity will be 0, so we conclude
that the capacity constraint is ok and we return L01 as best solution.
This is the reason why this commit suggests the use of the maximum
between done quantity and reserved quantity. This logic is already
used in the putaway application process, when we check the forecasted
quantity by location:
https://github.com/odoo/odoo/blob/a217ba27600c64c9104f8c1f003afd74ad06bd05/addons/stock/models/stock_location.py#L297-L301
OPW-3100322
closesodoo/odoo#109669
X-original-commit: 4ee8f974f993d2bbea7d9fc00779ebb1c1fa047d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Before this commit, the byproduct and putaway feature do not work
together. More specifically, changing the quantity to produce on a
manufacturing order will create automatically a byproduct move line (or
update the existing one with the new quantity) but never look for a
putaway rule to apply.
This commit makes use of `_set_quantity_done()` method on `stock.move`
that *do* call the putaway strategy mechanism
X-original-commit: d4a968412e68cc9da3ec2d9725caa90830287c48
Part-of: odoo/odoo#109669
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>
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>
Just change double the by single. This fixes various typos in error and
code comments.
closesodoo/odoo#107266
X-original-commit: 09dfedfc19c2bc34c2bb394dcc4bc609c5ac0107
Related: odoo/enterprise#34681
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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>
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>
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>
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>
Steps to reproduce
==================
- Create a BOM
- Add a line with a product of type product
- Set the quantity to 0
- Save and click on overview
-> ServerError: Division by 0
Cause of the issue
==================
Lines with a quantity of 0 should be excluded from the computation
opw-3053167
closesodoo/odoo#104980
X-original-commit: b0f5170252ed73d31543b8d1dcf114ae6f0b65bc
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
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>
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>
Since [1], a global time off is created in the demo data. Its date is
"today + 8 days". In `mrp`, the test `test_workcenter_timezone` tries to
plan some work orders for the next Monday:
https://github.com/odoo/odoo/blob/06e33207cdc6608e629a316fdddc35a15e08a3ad/addons/mrp/tests/test_order.py#L1882-L1883
So, if you install the demo data of `hr_holdiays` on Sunday and run the
test the day after, the global time off will prevent the slot
reservation by the work orders (and so it will lead to a failed test).
[1] e9bc5b9f36closesodoo/odoo#99665
X-original-commit: efa48d90839b7bd8b5638f352d7846339e360ac2
Signed-off-by: Adrien Widart <awt@odoo.com>
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>
Steps to reproduce:
- Manufacturing app > Operations > Manufacturing orders > Create
- Set product to [FURN_7800] Desk Combination > Save > Confirm
- Click on scrap, choose any product > Done
- Edit the manufacturing order > set the quantity to 1/1 > Save
An error pops up: You cannot change the UoM for a stock move that has
been set to 'Done'.
This happens because the scrapped product has its destination location
wrongly set to the production location of the manufacturing order.
Because of this, it is considered as a component of the manufacturing
order. The scrap is also confirmed right after creation, so its state
is set to 'done'. Finally, when confirming a manufacturing order, all
of its component moves are also confirmed, hence the error.
This commit prevents the override of the scrap's destination location,
so that it is not wrongly considered a component anymore.
The commit also adds tests for the override method, added in
commit 0b247ab17ccc5be0c2058ef92ccf3502c97e0bb3
opw-2945182
closesodoo/odoo#99218
X-original-commit: 81820d4df5f23d9b6b2701e513ada89b528a865a
Signed-off-by: Adrien Widart <awt@odoo.com>
Changes "Structure & Cost" report to "Overview", as the goal for this
report is improved.
The point is to have on a single report all components and sub-assemblies
that make it up, in parallel with the route and lead times associated to
each. This way it becomes easier to identify issues, such as:
- Missing routes.
- Longer lead times on a specific sub-assembly.
- Unavailable component in the foreseable future.
- ...
Also did the conversion to OWL, changing drastically the structure of
the report.
Task-2628323
Part-of: odoo/odoo#93194
This revision is to make uniform the behavior of the `groups` attribute
on the Python model fields
and on the node in the view architecture.
In both cases, remove the node from the view completely.
Before this revision,
in a back-end view:
- In the Python model, if a field has the `groups` attribute set
and the user is not part of
the groups, the field is removed, completely, from the view.
- In the view architecture, if a node has the `groups` attribute set
and the user is not part of
the groups, the node is made invisible (not completely removed, just
made invisible).
in a front-end view:
- if a node has a "groups" or "t-groups" set and the user
is not part of the groups, the node is removed from the view.
So it's 2/3 cases removing nodes restricted to a group.
and 1/3 case making invisible nodes restricted to a group.
It's simpler to have a uniform behavior for the 3 cases,
simpler to understandard for developers.
In addition, this will help for the goal to cache back-end views.
It makes possible to convert views using the `groups_id` field
by moving the content of these views directly
in the view to which they add content which is suppose to be completely
removed when the user has not the according group.
By getting rid of the `groups_id` many2many field on `ir.ui.view`,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the `groups_id` groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
closesodoo/odoo#95729
Related: odoo/enterprise#29592
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
* commons & setup refactoring:
* convert setUp to setUpClass
* move setups where needed (stock/mrp commons or specific test
classes)
* create test data in batch (faster, less sql queries & batched
operations)
* move most tests post-install to allow runbot splits
* by default, run tests without mail logic
* by default, run tests in a consistent environment (fixed currency
imposed in the BaseCommon)
* refactor existing tests to use new commons data (while trying to keep
diff reduced)
* add dedicated test file to test the common data
* use mute_logger to reduce useless test logs (less spam to scroll in
logs, less data on runbot builds, ...)
Part-of: odoo/odoo#96791
The render API was confusing as mixing the access to the report and
the rendering env.
The ambiguity was present for code such as
`report.sudo()._render(record_ids)` where it was not clear if the
`sudo()` is needed to access to `report` or to `record_ids`. For low
priviledge users (such as portal or public), it was common to use
`report.with_user(SUPERUSER_ID)._render(record_ids)`.
This PR changes the render methods signature to be `api.model`. The
`report_ref` can be:
- ir.actions.report external id
- ir.actions.report id
- ir.actions.report recod
- `report_name` value
This will allow to call the report methods with any user and no longer
need to use `with_user(1)` to render reports as public user.
Task-id 2670865
closesodoo/odoo#91341
Related: odoo/upgrade#3650
Related: odoo/enterprise#27323
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”:
- routes:
- MTO
- Manufacturing
- Create a SO:
- Select the product “P1”
- Confirm the SO
Problem:
The created MO is in confirmed state instead of draft.
This blocks the user, for example imagine that he has configured
the product with a first BOM without components and 2 others with
components. when the MO is created, the first bom will be selected,
and as the MO will be confirmed, the user will not be able to
select another BOM
Solution:
Since the MTO rule is not linked to an order point, we could be more
flexible, so the production created via `_run_manufacture()` without
bom or with a bom without component and operation via the MTO mechanism
will not be confirmed
opw-2897267
closesodoo/odoo#97099
X-original-commit: c623478aba040c0493e6da8a67c9742880572199
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce the bug:
- Enable 'Multi-Step Routes' option in Inventory settings
- Edit warehouse and update Manufacture = 'Pick components, manufacture and then store products (3 steps)'
- Create a storable product 'P1' with BOM:
- BOM type: Manufacture this product
- operations: “OP1”
- Components: product 'C1' consumed in the operation 'OP1'
- Set Reordering rules for product 'P1'
- Run Scheduler and MO will be generated with order points
- Edit MO and add Producing Quantity less than to produce
- Validate the MO and create backorder.
Current behaviour:
- child/parent MO were getting visible when backorder was created in 2/3 Step Production.
Expected behaviour:
- No child/parent MO visible until child/parent relations are there
closesodoo/odoo#96533
Task: 2846768
X-original-commit: 14431b2497dcf4aaf778ef1b06e023101b00a4e2
Signed-off-by: Tiffany Chang <tic@odoo.com>
_split_productions wrongly compute duration expected for backorders.
Setting quantity on production adapt many things including workorders,
so adapt original production after copy_data for backorders.
closesodoo/odoo#96179
Task: 2884562
X-original-commit: 71b8531881ff6924762ec34db3f2ddf858383218
Signed-off-by: Tiffany Chang <tic@odoo.com>
When creating a new manufacturing order with `move_finished_ids`
passed in the values, but `byproduct_id` is not amongst the move values,
the creation of the manufacturing crashed.
```
File "/home/odoo/src/odoo/master/addons/mrp/models/mrp_production.py", line 811, in create
vals['move_finished_ids'] = list(filter(lambda move: move[2]['byproduct_id'] is False, vals['move_finished_ids']))
File "/home/odoo/src/odoo/master/addons/mrp/models/mrp_production.py", line 811, in <lambda>
vals['move_finished_ids'] = list(filter(lambda move: move[2]['byproduct_id'] is False, vals['move_finished_ids']))
KeyError: 'byproduct_id'
```
By reading the implementation of the byproduct moves field:
```py
@api.depends('move_finished_ids')
def _compute_move_byproduct_ids(self):
for order in self:
order.move_byproduct_ids = order.move_finished_ids.filtered(lambda m: m.product_id != order.product_id)
```
it seems a better implementation to filter the move on the fact their
product is different than the manufacturing order to determine whether
they are byproduct or finished product moves.
Take the opportunity to write a unit test testing the tricky behavior
of the create override when both `move_finished_ids` and `move_byproduct_ids`
are passed in the create values.
This is related to revision
odoo/odoo@6c087f2043closesodoo/odoo#96044
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”
- Tracking: by serial number
- BOM:
- Component: C1
- Create a storable product “P2”
- BOM:
- Component: P1
- Create a MO to produce one unit of P1:
- serial number: SN1
- Confirm and mark as done
- Unbuild the manufactured product
- Manufacture the same product using the same serial number again
- Create a new MO to produce one unit of “P2”:
- Component P1 → select SN1
- Try to confirm and validate the MO
Problem:
Get User Error: The serial number “SN1” used for component “P1”
has already been consumed
We do a search in the `stock.move.line` to find if the SN has already
been used in a previous MO, but there is no specific condition to get
only those used in an MO so the unbuild order is in the same condition
and therefore the SN is considered as it has already been used
opw-2883450
closesodoo/odoo#95935
X-original-commit: 5ac7f4d6fa5551ba7c6da49a52edf0a7df2d0745
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
stcc-odoo