-
-
Notifications
You must be signed in to change notification settings - Fork 649
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[14.0][ADD] sale_stock_mto_as_mts_orderpoint_mrp #1701
base: 14.0
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this addon named
sale_stock_mto_as_mts_orderpoint_mrp
8d8c4bc
to
a26685a
Compare
done |
3a93fde
to
5c00c61
Compare
97c9494
to
d996ef7
Compare
@jbaudoux @mt-software-de |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
2724387
to
abc4bf2
Compare
abc4bf2
to
b9717c5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lgtm
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.