Before this commit, in the mrp_production form view, the quantity items
were spread out.
After this commit, they are closer together.
closesodoo/odoo#102582
X-original-commit: 3aa74fd15ed951974485fadd6a362fdaf374b202
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The status badge on workorder kanban card was hidden behind a dropdown
widget because of a wrongly used class.
X-original-commit: 491546a5c3ce6203763a7d829b44107e66ff3f42
Part-of: odoo/odoo#102398
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>
This commit converts `popover_widget`, `stock_rescheduling_popover`
and `mrp_workorder_popover` to OWL
closesodoo/odoo#101987
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The event listeners were added to the upload object instead of the xhr
object making them being called before they were supposed to.
closesodoo/odoo#102061
X-original-commit: 804467d7b0a583ab36a47212d482b41d29ca2203
Related: odoo/enterprise#32247
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Use case to reproduce:
- Create a product with manufacture and MTO route
- Set the warehouse in 3 steps manufacturing
- Confirm a SO for 5 units
- Update the quantity to 4 units
Current behavior
Each picking has a quantity to 4 units. Except for the post
production to stock that still for 5 units but a return is
created.
Expected behavior
Each picking has 4 units
It happens due to `_run_pull` that will create a new procurement
group in post production location (the purpose is to avoid a merge
between semi-finished product and finished product). But in the case
of a negative procurement, we want to decrease a picking and not
create a production order. So create a new procurement group with the
next MO sequence will aslo create another issue because
`_run_manufacture` will skip the MO creation since the quantity is
negative and it will be a gap in the sequence number.
Instead of creating a new procurement group, search for an existing
in sibbling moves, so `_search_picking_for_assignation` could find
a picking to merge the negative procurement and decrease an existing
move.
closesodoo/odoo#100439
X-original-commit: c5e8adaa2b364e3ff4625e080df4c523a9673668
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This PR https://github.com/odoo/odoo/pull/97805 wrongly assumed that
self contained a single workorder. This would raise an error if there
were multiple records in self.
Solution:
Modify calls on `self` to `workorder` (as we already iterate through
them)
closesodoo/odoo#101775
X-original-commit: 26cb902e603d6d576957d1d329d3eef4e76af5f8
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
When creating a MO with some WO from a mobile, the quality checks are
not created
To reproduce the issue:
(Need quality_control)
1. Create two storable products P_compo, P_finished
2. Create a BoM:
- Product: P_finished
- Components: 1 x P_compo
- Operations: create a new operation OP
3. Add a step to OP:
- Type: Pass - Fail
4. Switch into mobile mode
5. Create a MO for 1 x P_finished
6. Confirm it
7. Open the WO
Error: the tablet view skipped the pass-fail step, the user can already
mark the MO as done and close it
When confirming the MO, it leads to the quality checks creation. To do
so, we iterate on the `quality_point_ids` of the WO to generate these
quality checks:
https://github.com/odoo/enterprise/blob/7ff0f43df777027bf8544be3ac95e76feb7da957/mrp_workorder/models/mrp_workorder.py#L406
But, the WO has not any quality point, which is incorrect: it should
have the one related to the step created on the operation P. This field
is a computed one and is based on the quality points defined on the
operation linked to the WO:
https://github.com/odoo/enterprise/blob/7ff0f43df777027bf8544be3ac95e76feb7da957/mrp_workorder/models/mrp_workorder.py#L70-L73
But again, there is an issue: the WO has not any defined operation
(which is incorrect, it should be linked to OP). And this is because of
the WO creation from the kanban view: the field `operation_id` is
missing so it is not defined during the WO creation.
OPW-2984037
closesodoo/odoo#101346
X-original-commit: 751f1253d4a32491d210aceb4767084088c314ad
Signed-off-by: Adrien Widart <awt@odoo.com>
With the change to 'always edit' on form views by default, several
'oe_read_only' fields had to be modified to play nice with the fact
that in most cases, there is no read_only mode
closesodoo/odoo#101188
X-original-commit: 868992abeeda983768323e1126b5643eff8fdb33
Related: odoo/enterprise#31810
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
When drag and dropping a work order in the Work Orders Planning, the
end time wasn't recomputed. This can make the end time inconsistent with
the duration when the work order spans across a non-working time.
Steps to reproduce:
1. Install Manufacturing
2. Go to Settings > Manufacturing > Operations and enable Work Orders
3. Go to Manufacturing > Master Data > Routings and edit routing
'Primary Assembly' to last 120:00 minutes
4. Go to Manufacturing > Operations > Manufacturing Orders and create
one with values:
- Product: Table Top
- Plan From: today's date at 11:00:00
5. Save, mark as todo and plan the manufacturing order
6. Go to Manufacturing > Planning > Planning by Workcenter and trigger
the day view
7. Move the work order to 8 am
8. The work order still lasts for 3 hours (according to its start and
finish time) even though its expected duration is 2 hours
Solution:
Recompute `date_planned_finished` when we move a work order in the
planning (`date_planned_start` and `date_planned_finished` are passed in
values), and recompute `expected_duration` when we extend it (only one
of them is passed depending on the way we extend the work order).
(`duration_expected` is never passed in values when we manipulate a work
order through the planning)
Problem:
`date_planned_finished` wasn't recomputed when moving the work order in
the planning
opw-2893622
closesodoo/odoo#100988
X-original-commit: 2515482d5a706c65a7d8e27028f43987f17e6e67
Related: odoo/enterprise#31720
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@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>
Steps to reproduce:
- install the mrp_plm module (Product Lifecycle Management app);
- create a product with a long name;
- create a bill of material for that product;
- create a manufacturing order and select that bill of material;
- confirm the manufacturing order.
Issue:
The value of the bill of material field overflows into the second column.
Cause:
There is a problem in the use of classes in the .xml file (o_row and d-flex).
Solution:
Change the classes used (Bootstrap and Odoo classes) to have the correct rendering.
opw-2966863
closesodoo/odoo#100305
X-original-commit: 7a7c6870a2006edab8ffe62c016e5eb0681a46f8
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Create analytic accounting entries for employee times logs on workorder.
Compute BoM costs based on employee hourly cost and employee number
required on mrp operations.
closesodoo/odoo#91565
Task: 2427466
Related: odoo/enterprise#23032
Related: odoo/upgrade#3556
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This patch is part of a complete rework of the workorder tablet view and general
work order processing experience. It's mainly done in the Enterprise
repo. In community: the changes are the follows:
- The workorder kanban view remodeled
- Prepare workorder productivity timer to work with employee
Task: 2427466
Part-of: odoo/odoo#91565
This views has multiple custom features such as file upload, attachment
viewer and download.
A lot of files have been rendered obsolete and have been deleted,
notably `file_upload_mixin` which has been replaced by the
file_upload service and hooks.
closesodoo/odoo#99769
Related: odoo/enterprise#31145
Signed-off-by: Yannick Tivisse (yti) <yti@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>
- Add columns setup/cleanup time to Specific Capatities of Workcenter
- Take into account these 2 fields when compute expected duration in WO
task-2925474
Part-of: odoo/odoo#97588
Auto mark manual_consumption as True as soon as the component is use in
an operation and make the field read-only
task-2925474
Part-of: odoo/odoo#97588
The commit modifies the following:
- add tooltip : 'Displays the consumed Lot/Serial Numbers consumed.'
- Change the column Serial Numbers to also display lot number
- Make the column read-only
task-2925474
Part-of: odoo/odoo#97588
Currently, the kanban view show qty_production. However, the Listview
show the qty_remaining. So this commit match the field for 2 views (both
should show qty_remaining)
task-2925474
Part-of: odoo/odoo#97588
When mass producing from several reserved lots, we display a warning
message that the lot reservation is 'multiple'. This commit displays
that message in red.
task-2925474
Part-of: odoo/odoo#97588
Since d7716f071d, the onchanges to create the stock moves in mrp
production have been replaced by computes.
There was a hack in the create() method to trigger the onchanges in case
of import. As those onchanges do not exist anymore, this hack needs to
be remove too.
The compute methods are called naturally in imports.
closesodoo/odoo#99434
Signed-off-by: Arnold Moyaux (arm) <arm@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>
The move line form view is too technical for the average user so instead we
can to auto-magically open the reference document instead (picking or MO
only for now).
We do the same with stock valuation layers as well, but this feature
will not be available until its custom JS is converted to OWL
"product moves" part of b2b task: 2882539
closesodoo/odoo#97109
Related: odoo/enterprise#29974
Related: odoo/upgrade#3819
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
- reorder/rename/remove menu contents for "Inventory" and "Reporting",
including:
- removed "Forecasted Inventory" menuitem since this view is no longer
considered useful (code for view to be removed in separate commit)
- removed "Stock Moves" (moves report) menuitem
- renamed "Product Move" (move lines report) menuitem => "Moves
History", this will also be reflected in any "History" buttons that
open this view from other views.
- made "Inventory Report" menuitem visible only when applicable (i.e.
multi-location or consignment is active/debug mpde)
- made "Run Scheduler" menuitem only available in debug mode (
main_flow_tour updated to skip scheduler click since general flow is
expected to still the same/work)
Goal of renaming/ordering of menuitems is to clean them up and make them
more intuitive for users.
- "Run Scheduler" in mrp menus has also been made debug only viewable as
well to mirror the inventory change.
"menu" part of b2b task: 2882539
ENT PR: odoo/enterprise#29974
Part-of: odoo/odoo#97109
The goal of this revision is to get rid of the `groups_id` field of the model `ir.ui.view`.
- This feature wasn't really known or used by most developers,
and not straight-forward to understand.
Removing it allows one less complicated thing to learn for developers.
Besides, thanks to odoo/odoo#95729,
changing the behavior of the `groups=` attribute,
we can easily get rid of this `groups_id` feature
by simply adding `groups=` in the elements of the views
using the `groups_id` field, it will have the same effect:
adding the elements in the view only for the users part of the specified 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.
Part-of: odoo/odoo#98551
Since the new Overview report can compute the lead days and availability
delays from a BoM and all of its components and/or subassemblies, we can
use this data to compute the days that would be required to resupply all
components from a BoM.
So we add a button to compute it directly on the product form.
Task-2628323
Part-of: odoo/odoo#93194
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
The legacy field MrpFieldOne2ManyWithCopy added a control create
that performed an action when clicked.
In the new listRenderer we have added the possibility to define control
action buttons. So it is no longer necessary to create a custom field
for this use case.
Part-of: odoo/odoo#97558
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>
Purpose
======
When creating a specific Operation Type of type 'Manufacture' the default
operation type is not the correct one on object creation.
So in this commit, we set default `Operation Type` in picking when Type of
Operation is `Manufacture`.
taskID - 2939078
closesodoo/odoo#98145
X-original-commit: b28c44a38698018ebbbc420f6567c17b2b97c279
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Go to Inventory→ Configuration→ Warehouse Management →Operations Types
- Go inside “Receipts”, and enable the checkbox “Create New Lots/Serial
Numbers for Components” and `Use Existing Lots/Serial Numbers`under the
traceability section
- Create a receipt transfers with a traceable product
- Mark as to do the transfer
- Try to add a SN for the product
Problem:
Traceback is triggered: “key error: raw_material_production_id”
because we use this field to add it in the context from the parent in
the `stock.move.line` view:
https://github.com/odoo/odoo/blob/15.0/addons/mrp/views/stock_move_views .xml#L53
But this field is not present in all views of the `stock.move` model
Solution:
To avoid adding this field in all the `stock.move` views, it is better
to add it in the context from the `python` code
closesodoo/odoo#98110
X-original-commit: 545713ae0a559e7f2747dd3cb4211ab752e1ef0c
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce:
- Inventory app > Settings > enable barcode scanner
- Manufacturing app > Create a new manufacturing order
- Under components, add a product that has a barcode
- Save > Print > Production order
The barcodes of the products on the report all encode the
same (incorrect) value, which is the manufacturing order name.
This commit changes the barcode value to the corresponding
barcode string of the products.
opw-2930848
closesodoo/odoo#97968
X-original-commit: 71d4d977d42e69e8e3d7e069098707b84812ee07
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: stcc-odoo <stcc@odoo.com>
Installing mrp on a large database will take lots of time computing the
unit_factor of stock_moves created in stock. As this value is only
needed in mrp, this commit bypass the computation for moves that have
been generated before the mrp installation
closesodoo/odoo#97750
Task: 2918852
X-original-commit: a2f064446b1e232efc3e6924879f63b79e0bc986
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Part of the overall v16 SCSS optimization/restyle, task-2704984.
task-2896849
closesodoo/odoo#94767
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Lucas Perais