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>
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
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>
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
# Issue:
With User1, create a MO with work orders, and start one Work Order.
With User2, go to the MO, and start the same Work Order
=> Nothing happen, we currently prevent the workorders to have more than 1 open Time Tracking.
OPW-2845080
closesodoo/odoo#91123
X-original-commit: 8cb5aad6126e3f63ee4ef91115c8b4a6be571828
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: DavidFesquet <dafr@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>
Impacted versions: 15.0
Steps to reproduce (starting from ENTERPRISE 15.2):
- enable Work Orders
- create new BoM for a new product
- add 1 operation w/ 1 step (e.g. Instructions)
- add 1 component to BoM with operation_id (Consumed in Operation) = the operation
- Create and confirm a MO with new BoM + 2 Quantity to Produce
- Produce 1 product via the tablet view flow (i.e. complete instruction step + Validate 1 component in "Register Consumed Materials" step + Mark As Done)
Current behaviour:
Backorder is correctly created, but its workorder is missing the "Register Consumed Materials" step
Expected behaviour:
Step is correctly created
Note: same issue occurs with Byproducts having an operation_id (i.e. "Produced in Operation")
Issue is due to when _split_productions() first creates the backorders, they are created without move_raw_ids and move_finished_ids (see: _get_backorder_mo_vals()). When the backorders are created, they auto-create and auto-confirm their workorders. Since a quality point (e.g. operation step) exists for the workorder, the initial _action_confirm will _create_checks() for the quality point, but the "Register Consumed Materials" steps are created by the operation_id values in the move_raw_ids and move_finished_ids which haven't been set yet. This makes it so when the second _action_confirm() is called on the workorders (i.e. after their moves have been set) at the end of _split_productions(), the _create_checks() will be skipped because it assumes all the quality points have been created since one already exists.
Task: 2800975
Community PR: https://github.com/odoo/odoo/pull/87681
Enterprise PR: https://github.com/odoo/enterprise/pull/26437closesodoo/odoo#89486
X-original-commit: 67524eb948b7e122f33abf344b28b59bd81eb88d
Related: odoo/enterprise#26534
Signed-off-by: Tiffany Chang <tic@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>
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>
Workorder _action_confirm works in batch and is designed to
link workorders and moves per production.
Original code breaks the 'per production' constraint by linking
moves from all productions to workorders of the last one when
called on workorders from multiple productions.
closesodoo/odoo#86698
Task: 2797201
X-original-commit: b25f1e005987641a208de30162808005ad6e705a
Signed-off-by: Arnold Moyaux <arm@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 a work order that is ready or waiting, try manually changing the scheduled start or end date > save
Problem:
Traceback is triggered because when we modify the date, we check if the start date is before the end date. But we cannot compare a False with a date
opw-2768054
closesodoo/odoo#85991
X-original-commit: 1768a072fd40d14dc8c402c3ccad9a6733460c03
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@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>
When start_nextworkorder, if the WO is already cancelled, we
should try to check next one the this WO.
Task-2678388
closesodoo/odoo#83566
X-original-commit: 30fcfcc6c6ebb6fe9620d29475e1a7b6f1a46923
Related: odoo/enterprise#23819
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
There were some discrepencies when adding to/removing from WO Real
Duration:
- When adding time that is brings the total Duration over the expected
duration, the time should be split between the "productive" and
"performance" (i.e. reduced speed) times. This is already happening
when using start/pause buttons, so now it is consistent.
- Use 'id' instead of "Start Date" to determine which time_ids
to reduce/remove since adding a large enough "real duration" value
compared to previous time_id(s) could result in an earlier "Start
Date" for a newer time_id (i.e. results in which one is adjusted/
deleted = confusing). Using "End Date" was considered, but same
non-sequential issue can occur during time split from point above.
- Correctly determine if the "productivity" should be 'productive' or
not (i.e. 'performance') based on total WO duration (not duration
of newly added time_id)
Refinement of Part 4 of Task: 2667151
closesodoo/odoo#80319
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Unlinking a workorder which was in the middle of a chain of workorder created two subchains which both created a product when reaching their new respective ends.
The issue was solve by assuring that when we a link is remove from a workorder chain, their adjacent workorders are linked together using next_workorder_id
opw-2669514
closesodoo/odoo#82553
X-original-commit: a826608044f2a0b50c2ad9ed0228717f9ec66522
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit rename product_uom_qty into reserved_uom_qty and product_qty
into reserved_qty on stock move line to stop mistake them with the stock
move quantities fields.
Task: 2648449
Part-of: odoo/odoo#80434
Issue: When creating a manufacturing order and setting a scheduled date
when no workcenter is set, a traceback shows up
Steps to reproduce :
1) Install Manufacturing
2) Enable work centers
3) Create a manufacturing order, in the work order tab, add a new line
and set a Scheduled Start Date, confirm the date
-> Traceback
opw-2633940
closesodoo/odoo#76117
X-original-commit: ebf54c802664e6c2143785b950667c136944fcbf
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
This commit adds a new field to work orders to store the hourly cost of
its work center at the time of its completion. This is to avoid
inconsistent cost calculations when a work center's hourly cost is
changed after the WO is completed.
Part 2 (fix) of task: 2440068
Enterprise PR: odoo/enterprise#20169
Upgrade PR: odoo/upgrade#2727
Part-of: odoo/odoo#74951
Issue: When preparing a work order for a product on which the bill of material had a line with duration set to 00:00, the work order expected_duration for that line was set to 60:00
Steps to reproduce :
1) Enable Work Orders under Manufacturing Settings
2) Create a Bill of Material for a new product "test"
3) On the BoM Form, go to Operation, add a line
4) Set an operation, a work center and for Duration Computation, set it to manually and 00:00 minutes and save
5) Create a manufacturing order for that product, check the Work Orders tab of the Manufacturing order form, the duration is set to 60:00
Why is that a bug:
Since we can set a duration of 00:00 in the Bill of Material, it means the work order can take 00:00 as expected duration, however it was set to 60.0 since 00:00 is evaluated as 0, which is considered `False` in a conditional assignment that was catching the case where the variable was `None`, which it can never be since it is a fields.Float that will be 0 in case of a `None` or `False`
opw-2603928
closesodoo/odoo#74660
X-original-commit: 331b4c3aa69b06316e762f79f17e882f40e1870e
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- The work order state changes based on the availability of the components
- So if all BOM components are available the state of the first WO is set to ready
- The color of ready in the WO tree editable view will stay blue as long as done reserves the green color
- If one or multiple components are not available, the state of the first WO is set to waiting
- The color of waiting in the WO tree editable view is set to orange
By default to launch takes workorder_ready_count so it counts only ready WOs
- The user can always process the WO without restrictions even if the WO state is waiting
Task-2426773
closesodoo/odoo#71250
Related: odoo/enterprise#18523
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Co-authored-by: nouraellm <nea@odoo.com>
Replace text fields to html fields as we have our own 'OdooEditor'.
Indeed, it gives more options to users in the way they format their
content without weighting too much on the UI
(tools appear on demand and not by default).
Models -> fields
1) maintenance.request -> description
2) maintenance.equipment -> note
3) maintenance.equipment.category -> note
4) mrp.workcenter -> note
5) mrp.workorder -> operation_notes
6) mrp.routing.workcenter -> note
7) repair.order -> internal_notes
8) repair.order -> quotation_notes
Task Id: 2499504
X-original-commit: 0cca26b5358cd9d69a65c6b93cfecb33d7e659c5
Before this commit, if any workorder is stared to produce, qty
producing was 0. After this commit, if product tracking is none
then system will suggest the remaining qty of workorder to produce
when user is start it.
TaskId - 2480775
closesodoo/odoo#70207
X-original-commit: 5bbc234d43a415be18fcfa42dad33b1577644719
Related: odoo/enterprise#18086
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Usecase to reproduce:
- BOM PROD 1 -> No operation -> KIT COMP 1
- BOM KIT COMP 1 -> at lease one operation
Create a MO and confirm it -> Traceback.
It happens because workorders_by_bom[production.bom_id] will try to
find the bom related to production order. However they don't exist but
it will create the entry [BOM PROD 1] = mrp.workorder()
The [0] will be call on each values of the list afterward and raise
the traceback
opw-2477269
closesodoo/odoo#69651
X-original-commit: edabb86a306c4dda088b39f163de5668b5d90392
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When marking an operation as done, the quantity produced may be zero.
Therefore, the duration computation will not work.
To reproduce the error:
1. In Settings, enable "Work Orders"
2. Create two products P_prod and P_compo
- P_compo is consumable and its cost is 100
3. In Manufacturing, edit/create a Work Center WC
- Cost per hour must be 60
4. Create a Bill of Materials BM
- Product: P_prod
- Component: P_compo
- Operation:
- Work Center: WC
- Duration Computation: Compute based on tracked time
- Based on last 3 work orders
- Default Duration: 10:00
5. In Structure & Cost, notice that BoM Cost is 110
- 100 (P_compo's cost)
- 10 (OP's cost based on default time)
6. Do the following 3 times:
- Create a MO with P_prod using BM, Confirm
- In Work Orders, click on Start, then Done
- Edit the Real Duration of OP: 20:00
- Mark as Done
7. Back to BM, open Structure & Cost again
Error: BoM Cost is 110, this is incorrect: OP's cost is still 10, it
should be 20 (from step 6).
The problem is the quantity produced for each operation. Since this
quantity is never defined, it remains at 0. Therefore, when computing
the duration, since there is no quantity, the module keeps the default
value.
This fix changes the behavior. When the user marks the operation as done
from the form view, the module defines the quantity produced using the
quantity in production (this quantity may have been defined by the user
through the tablet mode). If this value is also 0, the module will use
the quantity expected by the MO.
`('qty_produced', '>', 0)` is added to avoid lines with zero quantity
produced, which was possible before this fix. Otherwise, the duration
calculation will give wrong values.
OPW-2453996
closesodoo/odoo#68917
X-original-commit: 93be6c6cfcfb3c4e52790569632dbdcdb1a3ae54
Related: odoo/enterprise#17540
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
We introduced new Smart Putaway Rules.
Locations now can have a storage category, on each storage category,
we can specify the amount of products/packages(with certian package
type) that can be stored in the location.
On putaway rules, we can also set a storage category. Now when apply a
putaway rule, we will find a suitable child location of the out
location according to quantity/weight setting on the storage category.
Task 2341820
PR #63516
ENT PR odoo/enterprise#15363
UPG PR odoo/upgrade#2040
Related fields are by default readonly and they should be when it
is possible. A editable related field will write on the related
model and will cause extra unwanted write of data. These unwanted write
can cause performance issues in some case (see odoo/odoo#63865).
Then remove the `readonly=False` of some related fields
(where it is useless):
- In 'mrp.workorder' (mrp): `working_state` and `production_date`
should be readonly.
- In 'purchase.order' (purchase): `product_id` should be readonly.
- In 'purchase.order.line' (purchase): `state` should be readonly.
- In 'product.supplierinfo' (purchase_requisition):
`purchase_requisition_id` should be readonly.
- In 'purchase.requisition' (purchase_requisition):
`product_id` should be readonly.
- In 'product.template' (stock):
`route_from_categ_ids` should be readonly.
- In 'stock.move.line' (stock):
`is_initial_demand_editable` should be readonly.
- In 'stock.move' (stock):
`product_tmpl_id` should be readonly.
- In 'stock.production.lot' (stock):
`product_uom_id` should be readonly.
- In 'stock.quant' (stock):
`product_tmpl_id` should be readonly.
- In 'stock.rule' (stock):
`route_sequence` should be readonly.
- In 'stock.change.product.qty' (stock):
`product_variant_count` should be readonly.
- In 'stock.return.picking.line' (stock):
`uom_id` should be readonly and also because it
is forced by `_prepare_stock_return_picking_line_vals_from_move`,
it should be related to the product uom not the one on the move.
task-2424248
The feature was actually not working as expected. It has been fixed,
and a test now ensures it does work as expected. This commit also fixes
some invalid parameters, hopefully nothing critical.
closesodoo/odoo#60429
X-original-commit: 231bdca3f26d96f578503694e5aec062de2317ed
Related: odoo/enterprise#14285
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The Duration Per Unit should be averaged, not summed.
opw-2353041
closesodoo/odoo#59446
X-original-commit: 54b40f1eb096ea9531f1f9b0478937536c8292fc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit makes sure we do not try to update the quantity on a
finished stock move (during record production or confirming the produce
wizard) if there is no finished move available.
Closes#57227closesodoo/odoo#59430
X-original-commit: 141df3b398aee2bac10e3ce94e15bb4bd14d17af
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Before this commit, when copy a workorder, the real duration was copied
too, which is unwanted.
task-2328830
X-original-commit: 6063bf7576a0abf975c2668ebacb6ad68c24315e
- On `mrp.production`, remove `workorder_done_count`
unused since mrp v14
- On `mrp.workorder`, remove `use_create_components_lots`,
unused since ed7012e8fd
Co-authored-by: Feyensv <vfe@odoo.com>
When a user is accessing a work order in state ready, we are updating it and
rewriting date_planned_start field. We also update accordingly the associated
slot of the workcenter calendar (leave_id), but if the ressource of this slot
is linked to another user, a record rule on resource.calendar.leaves is preventing
the update, which should occur without error, even if the user does not have
Time Off / All Approver rights.
closesodoo/odoo#57120
X-original-commit: 790fb1820fbd49d07206963077216cc304ed2b0a
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
If there is no `date_end`, sorting will crash.
opw-2326262
closesodoo/odoo#56603
X-original-commit: e981c17dd93c756a5cf0384ab2dcc25ef58cb1b1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In case `date_planned_finished` is `False`.
opw-2326088
closesodoo/odoo#56578
X-original-commit: 5c7c6b42cc0e0fa5bdd78aeca48cdf4ba9f78cad
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit makes use of _origin.id instead of .id into
mrp.workorder.name_get(). name_get() can be called from a compute method
(via _plan_workorders) which implies virtual ids. Searching amongst real
ids with a virtual one was not possible back then.
Task : 2278147
closesodoo/odoo#56469
X-original-commit: 346ecc3a52a7d1c3a2c6409a6799f6b013c3b6da
Related: odoo/enterprise#12641
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
- Go to Manufacturing > Configuration and activate Work Orders
- Create a Product (i.e. Product X) and create a Bill of Materials for it (with a Routing)
- Go to Manufacturing > Operations > Manufacturing Orders and create one for Product X
- Mark as Todo and Plan
- Go to Manufacturing > Operations > Work Orders and open the created one
- In Time Tracking tab, edit Planned Start Date or Expected Duration
The Planned End Date is computed without using the working calendar of the work center.
The working calendar should be used as it was at creation.
opw-2314555
closesodoo/odoo#56290
X-original-commit: 7b70da788d3a222467d88b06324a41e6c6efe605
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
- Refactor `order_finished_lot_ids` compute, to be linked to the `lot_producing_id`
the the related production (less boiler plate). We can't remove it because
it is used in mrp_subcontracting, and keep the Many2Many, for the tag widget.
Remove the second field compute by this method, `finished_lots_exist` (never used).
- Remove unused field `needs_lots` (also it is a duplication
with `has_tracking` info) from `stock.move` (mrp)
- Remove unused field `done_move` from `stock.move.line` (mrp).
- Remove unused methods `_strict_consumption_check` and `_update_raw_move`.
- Remove unused variables.
odoo/upgrade#1594closesodoo/odoo#54996
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Issue: when we created a new operation from the MO form,
the default of the expected_duration wasn't take in account and
override to 0.0.
Fix: in `_get_duration_expected` If there isn't workcenter is set,
instead of return False, return the `duration_expected`
closesodoo/odoo#56127
Related: odoo/enterprise#12517
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
It was impossible to add a workorder after a finished one
due to a constraint in the write (can't change next_work_order_id).
Remove this obselete constraint.
task-2278147
This doesn't make sense anymore: when we record production on a WO, in
any cases everything is processed as we make backorders.
Part of: https://github.com/odoo/odoo/pull/54283
task-2278147
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
Replace wrong usages of any(list|recordset), by any(generator)
to speed up computations, avoiding list creations and/or looping twice on a recordset
for nothing.
any([generator]) => any(generator)
any(filtered) => any(generator)
closesodoo/odoo#55768
Related: odoo/enterprise#12360
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Fabien Pinckaers