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
This reverts commit 61a8971db5.
This rev. is from a 7.0 forward port b4d602fdd3379a0310ec0b9a56f9b88226
This is no longer needed in 8.0, with the new WMS
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
When consuming product, the main_production_move is set as the source of production (used for consumed_for parameter)
However the method action_consume now (since 661a204) returns the new moves (when spliting) instead of the original one. This means that the tracebility would fail.
[IMP] Recheck should be type object and procure_method read only when not in draft
[FIX] Inversion of moves in the correct way and assigning production_id
As the moves are split the other way, the original move needs to be done. Also the production_id for linking the
new to be produced moves and the production order must be written on those.
[IMP] Clean
A previous refactoring brought a bom_line_ids field on the mrp.bom, thus
deprecating the _child_compute method. But the previous refactoring did
not go through all the views, breaking everything that relied on the
_child_compute (tree view, report). As the bom_line_ids refers to the
mrp.bom.line model (introduced by this previous refactoring, note:
_child_compute returned mrp.bom record) and that we can't make a treeview
showing different model, this patch introduce a function field _get_child_bom_lines
on the mrp.line model, allowing to go through the bom_line_ids of a mrp.bom.line
if this mrp.bom.line refers to a mrp.bom.
[IMP] Rename bom_line_ids to child_line_ids in mrp_bom_line to avoid confusion
Module description of procurement was deprecated (talking about mrp, ...) and in product_extended
it described things not implemented in the module.
In _bom_find, we passed a UoM which was not used in Saas-4 and it would not be logical that you
need to select a BoM that matches the UoM, so I removed it.
In the demo data, there was still a push rule which triggered a move from output to pack. The copy=False
is correct for production_id when you would have these push rules.
For the properties: we want to allow to take a bom which has no properties, but only when there is no other
BoM matching the properties we pass.
Update module descriptions
[IMP] production_id copy + no round
[IMP] _bom_find without uom, property correction
Simplify the action_consume of the consumption lines after the corrections
by Kevin Wang. Also the UoMs are revised as the action_consume uses the default UoM
of the product.
We have to avoid circular boms where a child bom should not contain the product that
represents the parent bom, but it is possible for example to use another product of the parent bom in
the child bom.
As the consume line move has no procurement rule, its origin will have no description. So, when there is
none it will also check the description of the previous move (when passed to procurement for example) This way
the chained moves or purchase order for example will have the MO-number as origin and not nothing.
[IMP] Change assignation
[IMP] UoM changes continuation
[IMP] Make sure we can use 2 times the same product in a BoM
[IMP] Source document for consume lines to procurement
[IMP] Add purchase order origin on picking
[WIP] Picking type on move for location on routing
[IMP] Provide extra function for custom buttons on picking
[IMP] Action assign optim
[IMP] Push apply should take invoice_state into account. Propagation of cancel of stock moves should depend on procurement rule
When searching for a bom based on a product.product, the method used to return any bom linked to the template (so searching for bom for variant A could return bom for variant B if both share the same product.template).
This will allow to return bom not linked to a variant without returning the one of another variant (opw 609358)
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes