The decimal precisions for the quantities, cost/supplier price
per unit of measure were not respected. It was always
set to 2 digits, whatever the configuration in the database
decimal precisions.
opw-653143
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.
This rev. 7307227 ensured to not (re-)set the state 'confirmed' to exploded moves with a more advanced state (for instance, 'assigned')
Nevertheless, the location chaining is performed on the move confirmation, through the action_confirm method of the stock.move model. Besides, the resulting moves of the _action_explode method had the state 'confirmed' on creation, the 'confirmed' state wasn't set by the method 'action_confirm', meaning that the moves were confirmed without having the location chaining done. Allowing moves to go through the action_confirm method even if the state was 'confirmed' or further triggered the location chaining.
Preventing already confirmed moves to go through the action_confirm method prevented the location chaining, thus.
We now create the resulting moves with the 'draft' state, and then confirm them through the procurement workflow signal 'button_confirm'. Thus, the resulting moves are confirmed by going through the action_confirm method, writing the confirmed state and triggering the location chaining at the same time. We then write the 'assigned' state if necessary.
opw-617235
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
For instance, setting a BOM Phantom with:
Finished product: stockable, MTO Manufacture
Components: stockable, MTS, Buy. Inventory set to 1000
Stock moves of components are directly set to assigned once the procurement confirmed thanks to JIT
The stock moves should not be set back to confirmed after they have been assigned
Denis Ledoux
Odoo Translation Bot
Martin Trigaux
Christophe Simonis
Nicolas Martinelli
Olivier Dony
Loïc BELLIER
Ravi Gohil
Akash Balar
Benoit Guillot
Julien Legros
Najlaâ El Khayat
Launchpad Translations on behalf of openerp
Anael Closson
Christophe Simonis
Lionel Sausin
Martin Trigaux
Foram Katharotiya (OpenERP)