[14.0][ADD] sale_stock_mto_as_mts_orderpoint_mrp #1701
Conversation
mmequignon
force-pushed
the
14.0-create_OP_for_components
branch
from
8d8c4bc
to
a26685a
Compare
done |
mmequignon
force-pushed
the
14.0-create_OP_for_components
branch
3 times, most recently
from
3a93fde
to
5c00c61
Compare
jbaudoux
changed the title
mmequignon
force-pushed
the
14.0-create_OP_for_components
branch
2 times, most recently
from
97c9494
to
d996ef7
Compare
|
@jbaudoux @mt-software-de |
There was a problem hiding this comment.
Algorithm seems now to be properly there.
Needs some final cleanup.
Have a look at how it has been cleaned up in v16. Note that in v16, it's still lacking the support of the mto route on the SO line (but it's also strange to create a permanent orderpoint for this case). The orderpoint is created when the route is set on the product. And orderpoints are triggered automatically in v16.
| @api.model | ||
| def _get_mto_orderpoint(self, warehouse, product): |
There was a problem hiding this comment.
Moved it to product.product and try to be close to v16 implementation https://github.com/OCA/stock-logistics-orderpoint/blob/16.0/stock_orderpoint_mto_as_mts/models/product_product.py#L26
You could backport the content of product_product.py from v16.
The main difference in v16 is that the trigger is automatic and you don't need to call the wizard
mmequignon
force-pushed
the
14.0-create_OP_for_components
branch
3 times, most recently
from
2724387
to
abc4bf2
Compare
mmequignon
force-pushed
the
14.0-create_OP_for_components
branch
from
abc4bf2
to
b9717c5
Compare
jbaudoux
changed the title
|
@mmequignon can you rebuild the generated files as you renamed the module. You may also add BCIM as co author in the manifest. Thanks |
| if bom_lines != move_bom_lines: | ||
| continue | ||
|
|
||
| is_mto = bom_product._is_mto() or all(bom_moves.is_from_mto_route) |
There was a problem hiding this comment.
| is_mto = bom_product._is_mto() or all(bom_moves.is_from_mto_route) | |
| is_mto = bom_product._is_mto() or all(bom_move.is_from_mto_route for bom_move in bom_moves) |
There was a problem hiding this comment.
I think we should point out, that this can only work for simple bom kits. (Where no component is a kit it self)
A more complex bom structure like.
Product 1
-
Component 1.1
-
Component 1.2 (kit)
-- Component 1.2.1
-- Component 1.2.2
This can never order all of the necessary products.
Since there will be 1 move (1.1) linked to bom 1
and 2 moves (1.2.1, 1.2.2) linked to bom 1.2.
The move from bom 1 can not be reordered by mto because of this if bom_lines != move_bom_lines:
it would be just possible to reorder Component 1.2 .
No description provided.