Method action_produce does not support the case where the same product appears
on multiple lines. We do this to avoid major changes in a stable version.
opw-644093
Relax the constraint on BoM to allow to have two different lines with the same
product. As the error message says, the purpose of the constraint was to forbid
having the manufactured product as one of the components but had this side
effect.
Such scenario of the same product twice makes sense when using the date
attributes on the lines (e.g. changing quantities)
opw 621468
Upstream traceability on produced goods (serial number on finished product) was
broken due to wrong values in cache for production.move_lines2 after production.
Refresh the value of production after each action_consume to make such the state
of the cache is correct. opw 609450
Similar fix for manufactruing order not going in done state in some specific
configrations (e.g. some components being phantom BOM).
Again due to wrong cache state after consumption. opw 610515
Fixes#1296
The method test_if_product, used in the workflow to test that the mrp production is for a product (!= service), used to call the method _action_compute_lines in order to compute the production lines and determine from them the production type.
The thing is, the method _action_compute_lines, despite the fact it returns the lines of the production, actually creates the lines. So, just to test if the production was of product type, the productin lines were created, in database.
This rev. introduces a _prepare_lines method, which returns the computed production lines, without actually creating them in database, so the test_if_product method can test if the production is of product type without creating the production lines.
Therefore, production lines are now computed and created during the action_compute method, instead of computing them when the production was tested to get the production type.
Computing the lines before the action_compute has as side effect to not set the scheduled date of the work orders in module mrp_operations, at MO confirmation (as, on confirmation, the action_compute method is called only for productions for which the lines are not yet computed, and mrp_operations overide action_compute to set the scheduled date)
opw-620189
if the bom is phantom and has no line, we attempt to find a new bom with the default product uom
This is possible that we find the same bom that the current one
In such a case, we must not explode, to avoid recursion.
The field bom_id is required on a manufacturing order and deleting a mrp.bom would block the current mo.
Restrict the suppression for manufacturing order in progress.
Fixes#3417
When validating a SO containing a `make to stock` + `manufacture` product
(with bom + orderpoint), we have the following stock moves:
* Product move
* Manufacturing order
Selling 1 such product would yield 2 as incoming quantity, an
inconsistency that this commit solves by setting the location_id of the
product move to the MO's location_dest_id (in the same fashion that
the create_pickings method does in an mts/buy case)
opw-616229
This had as side-effect to not allow splitting BOMs
(a manufacturing order for 1 unit of a BOM producing 10 units consumed the lines like it was 10 units, not 1)
This fix was to avoid having a fraction of a unit (for instance, 0.5 unit).
But, finally, it is preferable to allow splitting units:
1. Most users do not use several uoms, and in this case, the unit is the default uom (hidden).
2. At the moment, it is allowed to ask a manufacturing order splitting up the unit uom
(It is allowed to ask the production of 0.5 USB Adapter, for instance)
Thus, we should allow the splitting up of the unit uom in the lines too.
bzr revid: dle@openerp.com-20140124120102-we2yxio553ws2yz4
During the workflow signalling refactoring the signal for
confirming the procurements was sent to the wrong model,
thus having no effect at all.
In addition the MRP tests were incorrectly disabled and
did not cover this case properly. They were re-enabled
and corrected to cover it.
bzr revid: odo@openerp.com-20130801132150-gfp1saryq48249pu
During the workflow signalling refactoring the signal for
confirming the procurements was sent to the wrong model,
thus having no effect at all.
In addition the MRP tests were incorrectly disabled and
did not cover this case properly. They were re-enabled
and corrected to cover it.
bzr revid: odo@openerp.com-20130801125820-ubpq9wsew6q5w2hf
Christophe Simonis
Nicolas Martinelli
Martin Trigaux
Denis Ledoux
Ravi Gohil
Akash Balar
Julien Legros
Najlaâ El Khayat
Denis Ledoux
Martin Trigaux
Olivier Dony
Rifakat
Paramjit Singh Sahota
Christophe Simonis
Bharat R. Devnani (OpenERP)