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>
This allows to create a mrp.unbuild record without
the need to call the onchanges to set the uom and locations
or to set them manually during the `create` call.
For instance, this makes easier to create unbuild orders
using XMLRPC when you do not use multiple UOMs or multiple locations.
closesodoo/odoo#95557
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
With this revision, the expected duration is correctly set
when creating a production order with work orders without the need of
onchanges, through a form.
For instance, this allows an easier implementation to create a production
order with work orders through XMLRPC API calls,
as you will not need to manually set the expected duration value
or to call onchanges manually to set it.
For instance, without this change to remove the `default=60.0`,
the part added by this revision in the test `test_update_quantity_3`
would fail
```
2022-07-11 09:15:14,644 21 ERROR master odoo.addons.mrp.tests.test_order: FAIL: TestMrpOrder.test_update_quantity_3
Traceback (most recent call last):
File "/home/odoo/src/odoo/master/addons/mrp/tests/test_order.py", line 347, in test_update_quantity_3
self.assertEqual(production.workorder_ids.duration_expected, 90)
AssertionError: 60.0 != 90
```
while it just does the same thing than the existing `test_update_quantity_3` test
but without the use of a form / onchanges.
Part-of: odoo/odoo#95733
This allows to create a production order record without
the need to call the onchanges to set the product, uom or bom
or to set them manually during the `create` call.
For instance, this makes easier to create production orders
using XMLRPC when you do not use multiple UOMs.
closesodoo/odoo#95544
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
In the web client, in a real use case, it's not possible
to write on fields which are invisible,
as it's not possible to write on fields which are readonly.
This is a first step in the goal to change the behavior
of the `groups=` attribute in the back-end views,
to remove them for the view instead of making them invisible.
This is mainly to reduce the diff of the revision that will introduce
the mentioned above behavior change.
As nodes with `groups=` will be removed from the view
when the user doesn't have the group, it's no longer possible
to set a value on a field having a `groups=` the user doesn't have
in the `Form` test class, as the field will no longer be at all in the
view.
However, these unit tests shouldn't have been able to set values
on invisible fields in the first place.
This revision therefore aims to correct the unit tests setting value
on fields which were invisible because the user executing the
test was not part of the required group(s) for these fields
to be visible in the view.
closesodoo/odoo#94337
Related: odoo/enterprise#28936
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Convert the onchange on `product_id` to a compute field
This allows to create a `mrp.bom.byproduct` record without
the need to specify the uom during the creation nor calling the onchange
method. The uom defaults from the product uom.
This way, if the database is not configured to use multi UOMs,
the users do not have the specify the UOM to use.
For instance during an XMLRPC call to create a byproduct.
closesodoo/odoo#95270
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Rewrite _find_delivery_ids_by_lot to reduce the number
of recursive calls by grouping the producing move lines
together before each recursive calls. This reduces
the number of search calls, speeding up the whole method.
Add a unittest to check if the delivery_ids field
of a lot recordset is properly computed.
opw-2824464
X-original-commit: e7b9f14d4a9ce4ed61451b24b567f751fb4bcbe2
Part-of: odoo/odoo#95398
In some cases, replanning a work order does not change anything.
To reproduce the issue:
(Use demo data):
1. In Settings, enable "Work Orders"
2. Create two manufacturing orders (MO01, MO02) with 1 x [FURN_8522]
Table Top
3. Confirm MO01 and MO02
4. Set the same Scheduled Start Date (SSD) on the WO of each MO
- A warning should be displayed on the work order line because of
the conflict
5. Open the warning and click on "Replan"
Error: Nothing happens, the warning is still displayed and the scheduled
start date does not change.
For the warning symbol to be displayed, we check (through
`_compute_json_popover`) if two work orders are in conflict:
https://github.com/odoo/odoo/blob/8cb5aad6126e3f63ee4ef91115c8b4a6be571828/addons/mrp/models/mrp_workorder.py#L719-L722
So, we base this information on the `mrp.workorder`
However, the planning logic is based on another model:
`resource.calendar.leaves`. When planning a WO, we create a
`resource.calendar.leaves` and we link this slot to the WO thanks to the
field `leave_id`:
https://github.com/odoo/odoo/blob/4870606b00a758e63713e6e82c0cba9b1e7dd4aa/addons/mrp/models/mrp_production.py#L1238-L1248
Therefore, when replanning a WO, we ensure that the new slot does not
overlap any existing slot in the same workcenter. But, here is the
issue: when writing the start date (step 4), we try to replan the WO of
the MO only if this MO is already planned:
https://github.com/odoo/odoo/blob/4870606b00a758e63713e6e82c0cba9b1e7dd4aa/addons/mrp/models/mrp_production.py#L723-L724
Wich is not the case in the above steps. So, we don't (re)plan anything
=> we don't create any slot.
As a result: the warnings are displayed, which is correct, but when
trying to replan one of the WO (step 5, viathanks to
`_plan_workorders`): There isn't any slot starting from WO's start date
(there isn't any slot at all!), so we can create a new slot -> the start
time of the WO does not change -> considering their start times, there
is still a conflict between both WOs.
Comment: if after the step 5, the user tries to replan the other WO, it
will work: the first replanning fails but a slot has still been created.
Therefore, when replanning the second WO, the newly-created slot will be
detected, a second slot will be created after the first one and the
start date of the second WO will be postpone (according to the second
slot).
(!) Note that nothing creates any slot if we directly define the start
time of the WO during the MO creation (step 2). So this use case will
fail too.
We should ensure a perfect coherence between both models
`resource.calendar.leaves` and `mrp.workorder`.
OPW-2887413
closesodoo/odoo#95087
X-original-commit: 9d4d8d24792933e53a4ca422ccedde8ddc93cdf4
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When unbuilding a product, the selected source location is not applied
on the SM.
To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create two storable products P_compo, P_finished
3. Update the qty of P_compo: 1 in WH/Stock
4. Create a BoM:
- Product: P_finished
- Components: 1 x P_compo
5. Process a manufacturing order MO with 1 x P_finished
6. Transfer the P_finished from WH/Stock to WH/Stock/Shelf 1
7. Create an unbuild order UO:
- Manufacturing Order: MO
- Source Location: WH/Stock/Shelf 1
- Destination Location: WH/Stock/Shelf 2
8. Confirm UO
9. Open the associated product moves
Error: The SML of P_finished is incorrect, its source location is
WH/Stock instead of WH/Stock/Shelf 1 (as a result, the quants are
incorrect too).
The issue only happens with P_finished. The destination of the
components is correctly defined:
https://github.com/odoo/odoo/blob/90a87d6ecd420c61ea8db8a6c571db477ee7220e/addons/mrp/models/mrp_unbuild.py#L229
(i.e., we use the destination location of the unbuild order)
OPW-2869454
closesodoo/odoo#94367
X-original-commit: 45ec5871a1ee6e3a31e790323f08df20715f4171
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When a MO is generated in order to supply another one, the smart buttons
"Source MO"/"Child MO" are still invisible.
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Enable MTO route
3. Edit the warehouse: 3-steps manufacturing
4. Create 3 stored products Super, Sub and Compo:
- Sub has two routes: MTO and Manufacture
5. Create two BoMs:
- For 1 x Super:
- 1 x Sub
- For 1 x Sub:
- 1 x Compo
6. Create and confirm a MO with 1 x Super
Error: On confirmation, a second MO is created to produce one Sub, which
is correct. However, neither the first MO nor the generated one has a
link with the other one (through the smart button "Source MO"/"Child
MO")
When confirming the MO, a SM is created to bring one Sub to the
pre-production location. Thanks to MTO route, this will generate another
SM that brings one Sub from post-production to stock location (this will
lead to the creation of the second MO). However, the other SM (1 x Sub
from Post to Stock) doesn't have the same procurement group. This is the
reason why it is not found by the `_compute` methods.
OPW-2730830
closesodoo/odoo#94334
X-original-commit: 81e5ce05f2f79eb19489f00fb867143189fb38df
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.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
opw-2849397
closesodoo/odoo#93035
X-original-commit: 83afc17890b9a7b41e21aa5db738b04a13680cd4
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Currently MRP only allows sequential scheduling of work orders.
This commit allows to specify the dependencies for work orders to be
scheduled in parallel or in a complex diagram.
By enabling the feature in the settings and at the bom level,
you can specify dependencies between operations:
on the operation form, select the operations on which the
current one depends.
The dependencies will be reflected in work orders during planning.
The workorders Gantt view has been adapted for you to visualize
and manipulate the dependencies.
Please note:
- work orders without predecessors will be started first
- they can all be done in parallel
- when all work orders of this step are finished, their successors
will start
- and so on, step by step
Also, with the feature activated at the bom level and no dependency,
the parallel scheme will be applied (all operations at first step).
Finally, without activation at the bom level, the dependencies will
be created in order to satisfy the current sequential model.
Task: 2691328
Part-of: odoo/odoo#87131
In some cases, `test_replenishment` fails "for no reason".
Two notions are needed to understand the issue:
The class of the method `test_replenishment` is a `TransactionCase`. So,
once initialized, a SQL transaction is started and is the same for all
tests:
https://github.com/odoo/odoo/blob/3d9a835379d07142748a366285894a5d0f6ded71/odoo/tests/common.py#L693-L696
Also, in a SQL request, the method `now()` does not really return the
current date:
> Notice that NOW() and its related functions return the start time of
the current transaction. In other words, the return values of the
function calls are the same within a transaction.
(https://www.postgresqltutorial.com/postgresql-date-functions/postgresql-now/)
So, suppose it's the end of day D01 and we start all the tests of the
class `TestBoM`. A SQL transaction is created and the tests are executed
one by one so it takes time: it is now the next day D02 and
`test_replenishment` is executed. At some point, it leads to:
https://github.com/odoo/odoo/blob/9ca9bcc51fa289ddb0548f81a795755d196e31ca/addons/stock/models/stock_orderpoint.py#L328-L333
i.e., we are reading the report `'report.stock.quantity'` at date
"`today()` + 3 months", which means "D02 + 3 months". However, the
report is a SQL view and is defined on an interval of "today +- 3
months". Here is the issue: we use `now()` to get the value of today.
For instance:
https://github.com/odoo/odoo/blob/2f0ad2c150e65806c5f0f3ca66f702cc74619074/addons/stock/report/report_stock_quantity.py#L96-L104
As explained above, `now()` returns the start time of the current
transaction: D01. Therefore, the report is defined until D01 + 3 months.
As a result, D02 + 3 months is outside of the range, the `read_group`
does not return anything, there isn't any need and the orderpoint is not
created -> the test will fail.
closesodoo/odoo#91602
X-original-commit: f3e4eeb8412fba5ee36679eece4cba9f51df543d
Signed-off-by: Arnold Moyaux <arm@odoo.com>
When updating the MO quantity, the reservation of the components doesn't
respect the reservation method of the operation type.
To reproduce the issue:
(Use demo data)
1. Edit the operation type "Manufacturing":
- Reservation Method: Manually
2. Create and confirm a MO for 1 x [FURN_8855] Drawer
- Note: the components are not reserved, as expected
3. Update the quantity to produce (2 x Drawer)
Error: The components are reserved
The new conditions are directly based on the conditions to reserve a SM
when confirming it:
https://github.com/odoo/odoo/blob/e55988fc4d8090f84157a026b7ecc7ea0dc146a7/addons/stock/models/stock_move.py#L1242-L1248
OPW-2822205
closesodoo/odoo#90728
X-original-commit: 76168d0f95203c97e60955c2df396b3bb81aa4f3
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce:
- Create two extra warehouses (B and C):
* Warehouse B: Resupply from San Francisco
* Warehouse C: Resupply from San Francisco
- Create a new Product:
* Storable
* Inventory > Routes: select only Warehouse B and Warehouse C
- Create a new Move:
* From WHC to a Customer
* Confirm the order
Issue:
In replenishment, the defined prefered route will be Warehouse B
Cause:
When the replenishment view is loaded, in
https://github.com/odoo/odoo/blob/5757502a79c920e1aa4c7ca1c581c533907ce674/addons/stock/models/stock_orderpoint.py#L427
The preferred route (route_id) is defined as the first element of the routes defined for the produc which is wrong.
Solution:
Filter the route_ids by selecting the route for which the supplied warehouse is equal to the warehouse selected for the orderpoint.
Note:
1) The test in "test_bom" has been modified because it was using the wrong flow (a route should have been set by default)
2) In Master we only use the _set_default_route method
opw-2815462
closesodoo/odoo#90560
X-original-commit: 15b04d616a5196192a96e6bf2114698b34654348
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
Steps to reproduce the bug:
- Create a MO with work orders
- Confirm the MO
- Under the tab Work Orders > click on the button start multiple times quickly
Problem:
Several `mrp.workcentre.productivity` are created for the work order,
whereas normally the workorder can have only one timer started (without date_end).
Solution:
- If the workorder already has a timer running, return true to stop the process
- Add a constraint to block the user when he tries for example to create with an rpc call several `mrp.workcenter.productivity`
without an end date for the same workoder
opw-2802436
closesodoo/odoo#90094
X-original-commit: dd22195a75ec437e42424ee95ca9a41feeb48b0b
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 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>
kir-odoo