[WIP][WMS][12.0] Available to Promise Release #709
Conversation
guewen
force-pushed
the
12.0-wms-virtual-reservation
branch
4 times, most recently
from
b817595
to
2264735
Compare
There was a problem hiding this comment.
I know it is a wip no worries, just a small comment.
Also, I try to understand well the use of the module, and I wonder about the make to order process.
If you configure one product with make to order and buy route.
On sale order validation, the delivery order will be created and marked as need_rule_pull.
So the purchase order for the make to order product won't be created.
Then, the delivery order should be releases once the products are virtually reserved, which won't ever happen for the make to order product, right?
| def _compute_need_rule_pull(self): | ||
| for picking in self: | ||
| picking.need_rule_pull = any( | ||
| move.need_rule_pull for move in picking |
There was a problem hiding this comment.
should be move.need_rule_pull for move in picking.move_lines
|
@florian-dacosta spot on! I'll find a correction for the make to order issue, thanks :) |
Glue for stock_virtual_reservation and sale
* we want to work with the virtual available as we cannot delivery what is already outgoing * call action_assign even if the state is already assigned, because it may change the quantity
So we can activate the release only on some routes, while leaving other routes work as normal (eg. MTO). Still have to figure out if the ordered available to promise quantity is correct in this case.
guewen
changed the title
guewen
force-pushed
the
12.0-wms-virtual-reservation
branch
from
ca7b953
to
836668f
Compare
guewen
force-pushed
the
12.0-wms-virtual-reservation
branch
from
a580542
to
651d86e
Compare
| and not self.location_id.should_bypass_reservation() | ||
| ) | ||
|
|
||
| def _ordered_available_to_promise(self): |
There was a problem hiding this comment.
Why is this method not part of _compute_ordered_available_to_promise ? Retrieving the value can be done by reading the field.
There was a problem hiding this comment.
As we can't have proper depends, if values change in the transaction, the field will not be recomputed.
We could add invalidations everywhere, not sure that's useful. The field is good for the view, but the code better has to recompute the value on every access. I should add a docstring about this.
| ("product_id", "=", self.product_id.id), | ||
| ("date_priority", "<=", self.date_priority), | ||
| ("warehouse_id", "=", self.warehouse_id.id), | ||
| ] |
There was a problem hiding this comment.
Ideally we should exclude all the moves planned in the future that you can resupply on time. For example, there is no reason a delivery planned 3 months is blocking quantity while you can resupply in 7 days.
Simple solution would be configuring an horizon for considering blocking moves. A more complex and accurate solution would be by looking at the warehouse product orderpoint planned date.
To support sales order commitment dates, something must be done
There was a problem hiding this comment.
We go for the horizon solution here
| continue | ||
| # do not use the computed field, because it will keep | ||
| # a value in cache that we cannot invalidate declaratively | ||
| available_quantity = move._ordered_available_to_promise() |
There was a problem hiding this comment.
use the field "move._ordered_available_to_promise" instead
There was a problem hiding this comment.
There is the explanation in the comment just above why the field is not used ;)
I can rephrase if not understandable enough.
| ("product_id", "=", self.product_id.id), | ||
| ("date_priority", "<=", self.date_priority), | ||
| ("warehouse_id", "=", self.warehouse_id.id), | ||
| ] |
There was a problem hiding this comment.
We go for the horizon solution here
|
Work continued on 13.0 on #799 |
Implements: #710