* 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>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@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:
- Go to Inventory→ Configuration→ Warehouse Management →Operations Types
- Go inside “Manufacturing”, and disable the checkbox
“Create New Lots/Serial Numbers for Components” under the traceability
section
- create a MO with a traceable component
- Confirm the MO
Problem:
You can create a new SN for the component without any warning,
while the user is supposed to be blocked by a user error:
https://github.com/odoo/odoo/blob/master/addons/mrp/models/stock_lot.py#L11-L16
The solution:
We need to add the `active_mo_id` key in the context so that the user
error will be triggered
opw-2900256
closesodoo/odoo#96648
X-original-commit: 6d0ddc388d1c389e1911a6bb1c59c252870da1a7
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
On the commit 69dcdd4, the order='create_date desc'
was removed and the way of getting the MO for the notification changed. Now, the context is used, it should be written_after instead of written_date.
(The MO created is correct, only the notification is wrong)
OPW-2877457
closesodoo/odoo#96856
X-original-commit: b80287b265a4c01babedcbb58459c35d36a48066
Signed-off-by: William Henrotin (whe) <whe@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>
Stpes to reproduce the bug:
- Create a storable product “P1”:
- tracking: Serial number
- BOM: 1 unit of C1
- Create the MO 1:
- produce 1 unit of P1:
- Create the SN1
- Create the MO 2:
- produce 1 unit of P1:
- Create the SN2
- Create an Unbuild order:
- Select the MO1
Problem:
You have the possibility to select any Serial number linked
to the product “P1”, whereas only SNs created in this MO can be selected
opw-2834529
closesodoo/odoo#95956
X-original-commit: 167b1668450c5af44bc1d36d1c7d59921bc2b811
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>
Currently, when a BOM is archived via the ECO mechanism, its operations are
still selectable via the `copy existing operation` action on the BOM.
In this commit, we have added domain in `copy existing operation` action.
TaskID - 2845022
closesodoo/odoo#95548
X-original-commit: 272cd5358e8b78bc273d4aa72b8c42649f1f5171
Signed-off-by: Tiffany Chang <tic@odoo.com>
> Media query mixins parameters have changed for a more logical approach
> media-breakpoint-down() uses the breakpoint itself instead of the next
> breakpoint (e.g., media-breakpoint-down(lg) instead of
> media-breakpoint-down(md) targets viewports smaller than lg).
> Similarly, the second parameter in media-breakpoint-between() also
> uses the breakpoint itself instead of the next breakpoint (e.g.,
> media-between(sm, lg) instead of media-breakpoint-between(sm, md)
> targets viewports between sm and lg).
https://getbootstrap.com/docs/5.1/migration/#sass
Task ID: 2766483
Part-of: odoo/odoo#95450
From [1]:
> Dropped all .badge-* color classes for background utilities
> (e.g., use .bg-primary instead of .badge-primary).
We now have to manage constrast for some badge. It's why we
add 'text-dark' at some point.
Note:
Due to the backport of 'text-bg-#{theme}', we can use this to
avoid to use 'text-dark'.
Ref:
[1] https://getbootstrap.com/docs/5.1/migration/#badges
Task ID: 2766483
Part-of: odoo/odoo#95450
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
Purpose of this commit to fix the UI in Manufacture app.
So, in this commit done following changes As suggested in Task:
- Able to expand next activity column of MO list view
- Added tooltip of default capacity field on work center
- Added quantity tooltip of BOM
TaskID - 2689994
closesodoo/odoo#95315
X-original-commit: 463a81eb325f624e8947f1b3444947f8ba1dc24b
Related: odoo/enterprise#29113
Signed-off-by: Tiffany Chang <tic@odoo.com>
Now the way of access to an action is using the method `_for_xml_id` of
the model `ir.actions.actions` and not reading the action itself because
they need the access of the group "Administration/Settings" which not
all the users have it, so we were having an error with users that have
the permissions to see MRP Picking Types but they didn't have the group
mentioned above.
closesodoo/odoo#95312
X-original-commit: 1554fc9f8a98f4723b4f3cc1a8c0bd772c317ce5
Signed-off-by: Tiffany Chang <tic@odoo.com>
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>
This commit makes various adapations in addons with respect to
the introduction of the owl kanban view. Mainly, some selectors
in scss and in tests needed to be adapted. Moreover, in some tests
that we haven't adapted yet, we must ensure that legacy form and
list views are still used (useLegacyViews).
It also contains some adaptations in kanban templates, e.g. the
replacement of moment by luxon, the removal of underscore...
Part-of: odoo/odoo#92475
It could happen that there are other objects than stock.move linked to
the manufacture order. This is currently creating an error when
concatenating the objects. As we are only keeping stock.move objects to
log the exception on those, we should filter them before the concatenate
operation to avoid the error.
closesodoo/odoo#94893
X-original-commit: 1cdb682163e24fc01677cdcd0e1b83592443fffc
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Alex Thuyls (alt) <alt@odoo.com>
Co-authored-by: vancleeff <mvw@odoo.com>
Settings user is not able to access Bill of Material (mrp.bom) records
unless they have additional groups (account, inventory, manufacturing, ...)
This commit makes sure the operation is done in sudo so that any setting user
is able to save the settings.
Part-of: odoo/odoo#91909
For bugfix purposes, app administration groups have been given to
(implied by) the "Settings" group because without those rights,
opening/saving the settings crashed.
1) Do not load hidden view content
This commit uses the conditional inheritance of views
(depending on user groups) to avoid loading unnecessary view
& record content client-side.
This improves performance for admins without the specific application
admin rights, but also fixes the main bugfix problem,
caused by the webclient querying name_get for the records in relational
fields content.
Example:
sale_management adds a res.config.settings field to specify
the default sale.order.template for the current company.
If a 'Settings' user without 'sale.group_sale_manager' opens the
settings, he won't see this setting, but if a default template is
specified for the current company, the webclient will still request
the name_get of this template to the server, because the field
was present in the view, only hidden with a groups attribute.
With this commit change in sale, the field won't be in the view unless
you have the Sale manager group, avoiding the error/traceback/bug.
2) Remove implied application administration groups
Do not force the specific application groups on all 'Settings' user,
they globally do not need those rights, and if they need it, they
can add it to their account themselves.
3) Add a test to make sure settings user are able to manage settings.
4) Enforce 'settings' -> 'access rights' -> 'internal user' groups
As the previous test highlighted some 'false positives' because
it considered a settings user unable to read `crm.team`
and `stock.warehouse` records, we also took the opportunity to enforce
the fact that 'Settings' & 'Access rights' users must be internal users.
It makes no sense for a portal/public user to have access to the
settings, and didn't work anyway.
Part-of: odoo/odoo#91909
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>
- Change some section and column headers to make content clearer based on MO status
- Add in columns/field for in progress MOs for easier tracking of MO status
- Update words to match field names more closely (i.e. Actual Duration, To Consume, etc.)
Task ID - 2688146
closesodoo/odoo#93066
Signed-off-by: Tiffany Chang <tic@odoo.com>
This commit achieves two things:
1) Avoid calling super() on an empty recordset, in case all products
are kits. Even on an empty recordset, some queries would be fired.
This commit avoids them.
2) Use prefetch to read kit components quantity fields, to make use
of the recorset optimizations that ends up saving sql queries.
Otherwise, component quantities were computed on-demand one by one.
closesodoo/odoo#94225
X-original-commit: ef4ae7f62d6b690b4745b4145ce25ff02b6b29f6
Signed-off-by: William Henrotin (whe) <whe@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>
When creating a backorder for a manufacturing order, date_deadline for
its raw_moves are lost in the process, as the field is set to copy
False. But the split of a manufacturing order is not a usual copy paste.
In this specific case, we need to keep the date_deadline as well, or
resulting moves wouldn't be able to be merged with moves in
pre/post-production pickings from the original manufacturing order.
Task-2797359
X-original-commit: b50db19fa0da58dc0734c8cd494795743eaf0984
Part-of: odoo/odoo#93233
Since https://github.com/odoo/odoo/pull/86682, when a user opens
the replenishment view, the Days to Purchase are not taken into
consideration when calculating the forecast of a product.
This was due to the fact that the Days to Purchase are now taken from the
orderpoint and not from the company settings. This is fixed by taking
the company setting if no value from the orderpoint is sent to the
method.
closesodoo/odoo#93252
Task-id: 2871408
X-original-commit: ac1df1949e4523aff65543f1381300fc7de3b4e4
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: npi-odoo <npi@odoo.com>
Since 362f6b6d5b, the control panel of an
action can be rendered only the first time the dom is mounted. Any
further remount won't rerenders do anything. The bom report needs to add
some buttons and a searchView. Previously, those widgets was mounted in
the set_html _after_ the first mount of the controlPanel. This report is
an extend of the stock traceability which also adds some buttons. In
this case the buttons are rendered correctly because they are added
_before_ the first controlPanel mount.
This commit makes the extra widgets to be rendered in the control panel
generated in a new specific method overridable in the bom report file
closesodoo/odoo#93245
X-original-commit: 39306370a3a7c5767a29bba216ffe61ab8c69544
Signed-off-by: William Henrotin (whe) <whe@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
Steps to reproduce the product:
- Enable “Work Orders” option in MRP settings
- Create a storable product “P1” with BOM:
- BOM type: Manufacture this product
- operations: “OP1”
- Components: product “C1” consumed in the operation “OP1
- Create an ECO for “P1”:
- Type: New Product Introduction
- Apply on; Bill Of materials
- Click on “Start Revision”
Problem:
A BOM change will be created for the component “C1” where it will be added and removed.
When creating an ECO, a copy of the original BOM will be created,
and then we compare the BOM lines of the two BOMs if they are identical (product, qty and operation)
but as the operation has been duplicated therefore created with a different ID,
the two lines will not be identical and a distorted change in the BOM will be detected
Solution:
It is better to compare the fields of the operations instead of their ID to detect if a change has been made in the BOM
opw-2823253
opw-2809586
opw-2833083
closesodoo/odoo#92670
X-original-commit: 5c16aa22c70f8a0a377a55b912307ab07222c643
Related: odoo/enterprise#27943
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When manfacture in 2 steps is setup on warehouse, transfers are created
when confirming an MO, manual moves added did not have a warehouse and thus not
included in the picking. The default warehouse is set to the source location
warehouse in MO.
closesodoo/odoo#91879
Related: odoo/enterprise#27577
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Victor Feyens