diff options
| author | Simon Lejeune <sle@openerp.com> | 2018-05-03 16:53:02 +0200 |
|---|---|---|
| committer | Simon Lejeune <sle@openerp.com> | 2018-05-04 11:52:36 +0200 |
| commit | 3d8c0df8bf4732a8e7b8394c9f46fb72e46285c0 (patch) | |
| tree | bdf1bced14c4cad92a983ecf23439c5fff62b53e /addons/web/static/src/js/views/basic | |
| parent | 6e15a9cd24eb5825ea615512a4ee834f131a60f7 (diff) | |
[FIX] stock: quant: reserve and unreserve on duplicated quants
In a situation where there's a negative quant next to a positive one,
they should be merged when the scheduler runs or when the user open its
inventory view. However, if in the meantime the user reserves and
unreserves, there may be some issues.
The system will only reserve on positive quant ;
the system will unreserve on the first encountered quant (even negative)
The issue is the second part of the early break condition:
float_is_zero(available_quantity, precision_rounding=rounding):
The issue here is `available_quantity`. In a reservation scenario, it
represents the maximum quantity we can reserve across quant. It is
useful so we do not lose time loopin over quants where nothing will be
available. In an unreserve scenario however, it represented the same
thing, which is wrong. In the case you reserved all the quantities,
`available_quantity` will be 0 we'll loop only on the first quant where
we won't do anything.
As the code doesn't check the success or failure of the unreserve, move
lines were unlinked while the reserved quantity on the quants were not
updated, resulting in the desynchronization of the move lines/ reserved
quantities.
This continues the work done at [1] to track down the "cannot unreserve
more than" errors.
[1] cce6030c0da77a5739af01d57cd53822fc3ab394
Diffstat (limited to 'addons/web/static/src/js/views/basic')
0 files changed, 0 insertions, 0 deletions
