Before this patch, writing on the `date_expected` field on the raw moves did not
update the `date_planned_start` (but writing on `date_planned_start` did write on
the raw AND finished moves `date_expected`).
This proved to be wrong: having the same `date_expected` on both raw and finished
moves did not make sense (the manufacturing order is not instantaneous). It also
makes difficult to make the rescheduling work: the rescheduling is done on the stock
moves and thus updates `date_expected` on the raw moves. If this information is not
transmitted to the manufacturing order, we won't be able to continue the rescheduling
on the finished moves (the idea is to update the raw moves which will update the
date_planned_start which will update the date_planned_finished which will update the
finished moves)
To have a more sane system, the `date_planned_start` and `date_planned_finished` are
computed (with an inverse) on the raw and finished moves `date_expected` (similar to
what's done on the picking model). There's a tweak though: as `run_manufacture`
creates first the order with a `date_planned_finished` and then confirm it (which will only
create the finished move at this moment), there's no place to write `date_planned_finished`.
The compute thus defaults on `date_deadline` which is stored and the finished moves
will be created later on with this value.
We implement the same logic `_onchange_date_planned_start` in `write` so that it doesn't
only rely on the onchange mechanism and the rescheduling can work when changing the
`date_expected` on a child mo for example.
task-1970595
Before this -
If we have follwing configuration -
Manufacturing -> Propagate Cancel -> True
Buy -> Propagate Cancel -> True
* BOM of a Car -
1) Component 1 -> Iron (MTO & Buy)
Now create a SO of product Car and confirm it.
It will create a MO (Car) and then PO (Iron).
Now if PO is cancelled, it will cancel its
move_dest_ids and on change of it MO will be
cancelled but delivery move will remain ongoing.
When action cancel is called on a move raw, it will
check if the production order is also cancelled.
If the MO is cancel, in this case cancel also its
move finished.
Task-2117832
closesodoo/odoo#42209
X-original-commit: 9522e51a3b290c91f23658a4fb781003ff1fd8d2
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
The inventory button was shown or hide depending of the product valuation.
As the valuation was previously stored on the stock moves and posting
split the stock moves. Fifo and Avco valuation was not well computed.
The migration to stock valuation layer fixed this behavior. This
commit shows the post inventory button as soon as there are some
finished move to be posted.
task : 54665
closesodoo/odoo#41781
X-original-commit: 5dfa3f817d3a9f47a863a587569a862a40c7d159
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
The commit 75460e697a was introduced in
v12, when the workorder stored their consume data on stock.move.lines.
Their was an issue when posting intermediary inventory on productions
using workorder. As those 'dummy' stock.move.lines did not have their lot
field filled, an error at line validation was raised.
In v13, the workorders use workorder lines. The lots and quantity are
transfered on real stock move lines only at the end of the production.
Posting intermediary inventory did not failed anymore in case of partial
production
Task : 54665
X-original-commit: a41239b378a1cae394d18f43e991ec8bceeac826
Use case:
Plan a production of 10 units on 2 workorders. Produce 4 units of lot1.
Record the production and produce the 6 next ones with the same lot1. On
the second workorder, the suggested quantity is 4 and not 10.
This issue is due to the fact that we fill the next workorder quantity
only at the first production batch and we don't check that the same lot
can be used again.
This commit call the mathod to update the quantity on the next workorder
if the first lot is produced again.
closesodoo/odoo#41189
Opw: 2127665
X-original-commit: e15fc6ac994edabc8907c13295c883cff9320d10
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Updating the quantity to produce in a production order will recompute
each raw move's unit factor. The issue was this computation did not
take care of the previously product quantity. The unit factor was wrong
and so the next created workorder lines get the wrong quantity.
Example:
- 1 components for 1 finished product (unit_factor = 1)
- Create a production for 2 finished product -> quantity to consume = 2
- Produce 1 then change quantity to produce to 3 -> quantity to consume = 3
and quantity done = 1 but unit factor became 1.5
closesodoo/odoo#40990
X-original-commit: 79976600df45afc6150150734eef405fd41a70a3
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
If a component is used in a production with another unit of measure
than it's one, the created stock move line could not convert the quantity
correctly.
If there is enough quantity in stock, the created move line takes the
quant uom but the quantity in the production ones.
ex: consume 1 dozen, the quantity on the stock move line is 1 unit
This commit always uses the wo line's UoM and quantity to create the
stock move line.
closesodoo/odoo#39222
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit, The addition of new stock move lines in a
finished production via the unlock button did not impact the
traceability report. This was due to the fact that the new sml
has not been linked to the finished_lot_id.
This commit extend the flexible consumption. On the workorder form view.
It's now possible to add directly new workorder line with any product
(even one not in any BoM line). For those new wo line. A confirmed stock
move is create in the record_production step.
Task : 2082448
If a Bill of Material is created without code (eg. when created as a new
group from a kanban view grouped by BoM) we would get a traceback
instead of an error.
With this changeset, we get a "You cannot create a new Bill of Material
from here." error if it is being tried.
opw-2124162
fix#38904closes#40289closesodoo/odoo#40457
X-original-commit: 32c13cd7d1387c0ea81a9bb5968d18c2b8f32051
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
If a warehouse is created without code (eg. when created as a new group
from a kanban view grouped by warehouse) we would get a traceback
instead of an error:
```
The operation cannot be completed:
- Create/update: a mandatory field is not set.
- Delete: another model requires the record being deleted. If possible, archive it instead.
Model: Warehouse (stock.warehouse), Field: Short Name (code)
```
opw-2124162
fix#40233closes#40267closesodoo/odoo#40382
X-original-commit: b6caa179e17199b29a9ca4009c53acb378423926
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- Create Product A:
Routes: MTO and Manufacture
Manufacturing Lead Time: 20 days
- Create Product B:
Routes: MTO and Buy
Add a supplier with Delivery Lead Time: 10 days
- Create a BOM: 1 unit of B to produce 1 unit of A
- Create a SO for A, validate
A MO is created with a Deadline set at SO order date - 20 days => OK
A PO is created with order date set at SO order date - 10 days => Not
OK, it should be - 30 days.
In v13, the raw materials expected date is the order date.
In v12, this date is computed as: order date minus Manufacturing Lead
Time
However, in both versions the PO order date is computed as the raw
materials expected date minus Delivery Lead Time of the supplier.
This comes from a change in the semantic of 'Planned Date' and 'Planned
End Date'. In v13, the Manufacturing Lead Time is only taken into
account in the Deadline, while in v12 it was taken into account in the
Planned Date. However, the expected date of the raw materials still
relies on the latter, not on the Deadline.
In order to solve this, we apply the 'Manufacturing Lead Time' of the
product and the company to 'Planned Date', 'Planned End Date' and
'Deadline' when the MO is created. Note that the solution is still not
ideal in case no routing is set on the BOM since 'Planned Date' and
'Planned End Date' won't be updated later in the process.
opw-2118951
closesodoo/odoo#40360
X-original-commit: b523f991572e32e69c5f8000a21553191ca54773
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Planning the workorders depends on the quantity to produce of those workorder
This will create as much as production batch needed regarding the workcenter
capacity.
This method is good except in case of product tracked by serial number. In that
case the quantity to produce on the workorders is force to 1 regardless of
the quantity to produce on the production
closesodoo/odoo#40226
X-original-commit: 3c4133ddac256c63802a99461db49cc9bd9fa1d6
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Before commit: - If there are multi level production order,
and user cancelled any one then,
there is no activity logged on related production order.
After this commit: - In multi level production order
(i.e. one production order creates another production order
to consume the raw material)
if user cancelled raw material production order then,
exception will be generated on main production order,
so that user can easily get the idea that
raw material for this production order is not available.
[ADD] sale_mrp: add testcase for cancellation of the multilevel production orders
task-1819526.
closesodoo/odoo#28708
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When a BoM is using a component with a quantity required set to 0,
tracebacks were occuring when computing the available quantities
for the kit.
Fixes#38807closesodoo/odoo#39267
X-original-commit: 7676269ba56c8e293ef4cd3dffbe7eccbad4a9d0
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Records were filtered so not every record was set in the for loop
Fixesodoo/odoo#38992Closesodoo/odoo#39071closesodoo/odoo#39234
X-original-commit: f7d5ba6f9ffccecffbb5b851bd2770ecef28520c
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The commit 0679d0d introduced a new
planning mechanism for the workorder. Two issues have been instroduced
since this patch.
1. Cancelling a workorder didn't free the time slot in the workcenter
calendar
2. Validation a workorder sooner than the planned date didn't update
the workcenter calendar to plan another production sooner.
This commit update the date_planned_start and date_planned_finished
at cancellation and validation to impact the workcenters calendar.
To keep the original planning dates, they are now tracked
This commit also fix the button_start() method that always rewrited the
date_start even if the production had already been started.
Task : 2082442
closesodoo/odoo#38947
X-original-commit: 4ca6c773a00320865142e4efb3645f36c54ce9a2
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Since `check_company` is intended for relational fields.
closesodoo/odoo#38939
X-original-commit: bf2f3f6ce1430c2603fe7fe199a28296b2d7416f
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Usecase to repdroduce:
- Create a manufactured product with route manufacture and a RR
- Run the scheduler.
Orderpoint will prepare procurement values's date as string. Other
module could possibly also use string as date and a call to from_string
will not break anything if the value is already a date or a datetime.
closesodoo/odoo#38900
X-original-commit: e4c654f8e5e768288226c725a1018ae31e8f5606
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This commit redo the way workorders are planned on their workcenter
calendar. The resource_calendar_leaves introduced in 0679d0d is now linked
to the effetives dates (date_start and date_finished).
The planned dates copy their information onto effective date at the
workorder plannification or any modification before the actual production
(state = draft, pending or ready)
This way, the gantt view and calendar view display either the plannifaction
slot if the production isn't started yet and the effective production
time if it's done. The plannification is also impacted by validating
a production sooner than expected or cancelling it. In the first case,
the date_finished is set at 'now' and in the second case, all the dates
are emptied. The futur workorders will be planned on the newly recover
time slot.
This commit also fix the button_start() method that always rewrite the
date_start even if the production had already been started.
Task : 2082442
closesodoo/odoo#34038
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
With this commit, the manufacturer will now be noticed earlier in
the process if he produced/consumed a serial number already produced/consumed in a
previous production. Before this commit, an error was triggered as
well but only at the very last step of the production.
This leaded to two issues :
- The user had to unlock-edit-lock to update the wrong serial number
- On large production, it was difficult to figure out which was/were
the product(s) to fix.
The search on previous production is done each time the produce wizard is closed
or once the production is done on a workorder
Task 2002133
Install stock and purchase. Make a RFQ for just one product, coonfirm
and receive in one transfer. Click on the delivery (should be only 1).
The picking will display. Open studio, select view, activate list view.
Javascript traceback will popup. Moreover the view of the stock
module will be altered in a faulty way (can be recovered from "Window
Actions", looking for the stock.picking action with external id
"stock.action_picking_tree_all" and removing the last added tree from
"View Mode").
This is caused by studio not detecting all the active views, thus giving
the possibility to add an already active view, because when there is just
one picking all other views are filtered out.
Changing the way the form view is retrieved in case of a single picking
fix the issue.
opw-2076241
closesodoo/odoo#38093
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Small improvement in order to not trigger twice the write
function on state
close#34884closesodoo/odoo#38177
X-original-commit: d45d50b4f145a0bfb60465f7eb783a3c5fd85e6c
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- Create a workcenter with a capacity of 500 units
- Create a BOM with a routing generating one work order in the WC
created
- Create 3 MO with the following real durations:
MO 1: 1000 units produced in 420.95 seconds
MO 2: 1000 units produced in 120.28 seconds
MO 3: 1000 units produced in 60 seconds
- Create a MO for 1 unit
The Duration expected is computed as
The Time Cycle is computed as:
(420.95 + 120.28 + 60) / (1000 + 1000 + 1000) = 0.20041
The Total Expected is computed as:
0 + 0 + (1.0 * 0.20041) * (100.0 / 100.0) = 0.20041
0.20041 seconds is not realistic based on the previous MO real
durations.
This is because the Time Cycle doesn't take into account the workcenter
capacity. If we can produce 60 units in parallel in 60 seconds, that
doesn't mean we can produce 1 unit in 1 second. Therefore, the Time
Cycle should be multiplied by the WC capacity, which gives a Time Cycle:
500 * (420.95 + 120.28 + 60) / (3000) = 100.205
Which is much closer to the real duration.
opw-2070759
closesodoo/odoo#37548
X-original-commit: 9d3a73f64feb3b9e71c50a04adb6206b6393c757
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Planning workorder will generate workorder lines according to reservation
If some lines are already created into the workorder for the current product,
The line generation will increase the quantity of the existing one instead of creating
a new one. The issue occurs when the production have some stock move with the same
product.
This commit change the condition to find workorder line candidate. Instead of searching
line with same product, we now search line with same stock move.
closesodoo/odoo#37419
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Implement group_expand for workcenter_id so that all workcenters are
visible in the planning by workcenter gantt.
Implement some constraint on write because anything can be moved in the
gantt view.
When changing the workcenter of a workorder, make sure the leave is now
set on the new workcenter.
closesodoo/odoo#37386
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
On Mobile the byproduct One2many only empty line.
It's due to default kanban view using the _rec_name
in order to display the byproduct name. On byproduct the
_rec_name is not defined nor the field name so the kanban
is empty.
closesodoo/odoo#37403
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When a BoM was composed of a phantom BoM, there was mutliple bugs:
- if not routing was set on the phantom BoM, the components were never
consumed
- if no operation was set on the BoM, its components were to be consumed
on the last workorder of the BoM and of the phantom BoM.
closesodoo/odoo#37304
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Computing quantities of a kit product made only of consumable
failed as the quantities are not initialized.
This commit makes sure this kind of products don't have their quantities set up
in mrp and so are set to 0 in stock
closesodoo/odoo#37382
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The computation of kit quantities was not efficient. A loop on each product
of the recordset to consider performed. Each time a product was seen as 'not a kit',
a new computation on the complete recordset was done. This leads to a N^2 complexity
This commit only compute stock quantities for non kit product in one batch
opw-2070768
closesodoo/odoo#37205
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Steps to reproduce the bug:
- Create two operation types OP1, OP2 with code = mrp_manufacture
- Create a BOM B with operation type = OP2
- Create a MO with B
Bug:
The operation type set on the MO was OP1 instead of OP2
Technically:
The default value was always taken from function _get_default_picking_type
opw:2070370
closesodoo/odoo#37029
X-original-commit: 3c5338dce8db7606ac2ac0101473bcafe3bd4f76
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
If it isn't set manually, it defaults to now and the result is not
consistent with planned date end. We make it an hour before totally
subjectively.
closesodoo/odoo#37173
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this commit, the product/product template computed mrp quantity
fields wasn't computed by active company but for all companies.
So, set `compute_sudo` on false for the different computed mrp quantity
fields of products and product templates to avoid to search with sudo
active and to search by company.
Steps to reproduce the bug:
Let's consider two storable products P1 and P2 where P1 is tracked by serial number
- Create a BOM B for P1 where P2 is a component
- Create a serial numberv SN for P1 with no quantity
- Create a MO M1 for P1 and click on button "Produce"
- In the view MRP Product Produce, SN is selectable in the field lot_id
- Now change B and set a routing on it
- Create a new MO M2 for P1 and click on produce
- At least one WO has been created, click on the first one
Bug:
- SN is not selectable in the field final_lot_id
The domain set on the field final_lot_id:
"['|', '&', ('product_id', '=', product_id), ('product_id.tracking', '!=', 'serial'), ('use_next_on_work_order_id', '=', id)]"
didn't allow to chose SN.
With this fix, it's now possible to chose SN on the first WO created for M2
opw:2059745
closesodoo/odoo#36425
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The condition needs to be fined-tuned, so revert for now.
This reverts commit 40487aca5c.
closesodoo/odoo#36470
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Create a MO with a product with a normal bom B
- Save the MO
- Change the type of B to phantom
- Try to produce the MO
Bug:
It was impossible to cancel or confirm the MO.
It's not allowed to produce a MO with phantom bom.
opw:2061958
closesodoo/odoo#36329
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
It's due to MRP refactoring that confirm raw moves before finished
moves. It implies that in _assign picking, SFP with final product
will search a picking but the stock.move do not have a created_production_id
and it will be merged inside the intermediate SFP (it works before
because it was the intermediate SFP that was merged in the finished SFP).
_key_assign_picking is also added if multiple moves are confirmed w/
and w/h created_production_id, we won't merge them in the same picking.
closesodoo/odoo#36335
Signed-off-by: Christophe Simonis <chs@odoo.com>
Debauche Stéphane