[10][FIX] Variability factor increase red zone#57
[10][FIX] Variability factor increase red zone#57hparfr wants to merge 81 commits intoForgeFlow:10.0from
Conversation
…orderpoint_stock_info_unreserved
[10.0][FIX] ddmrp migration: add latest changes
…pply the moves that are within the DLT.
rousseldenis
left a comment
rousseldenis
left a comment
There was a problem hiding this comment.
LGTM. Seems make sense.
Weird that tests pass... Please provide a test to ensure result.
|
Ping @lreficent |
| @@ -54,11 +54,11 @@ def _compute_red_zone(self): | |||
| if rec.replenish_method in ['replenish', 'min_max']: | |||
There was a problem hiding this comment.
You have to split this, for replenish the code is good. For min_max as we discussed yesterday they changed the computation of red zone on the 2nd edition. Now it is RZ(min_max) = adu * dlt * (1 + variability factor)
There was a problem hiding this comment.
You have to split this, for replenish the code is good
Here I meant the current code without the changes on this PR
| "product_uom.rounding", "red_override") | ||
| def _compute_red_zone(self): | ||
| for rec in self: | ||
|
|
There was a problem hiding this comment.
@hparfr @lreficent Maybe a _get_lead_time_factor() method should be a good approach ?
There was a problem hiding this comment.
I don't think it will make sense now. It can be refactored later when some new buffers will be added. (like time buffer 👯♂️ )
There was a problem hiding this comment.
Ok, that's what I've in mind 😃
It was to 'decouple' a little bit code!
LoisRForgeFlow
force-pushed
the
10.0
branch
2 times, most recently
from
d504848 to
4d532f0
Compare
8 participants
Instead of reducing it.
Tested manually on minmax buffers.