summaryrefslogtreecommitdiff
path: root/addons/web/static/src/js/views/basic/basic_model.js
diff options
context:
space:
mode:
authorSimon Lejeune <sle@openerp.com>2018-05-03 16:53:02 +0200
committerSimon Lejeune <sle@openerp.com>2018-05-04 11:52:36 +0200
commit3d8c0df8bf4732a8e7b8394c9f46fb72e46285c0 (patch)
treebdf1bced14c4cad92a983ecf23439c5fff62b53e /addons/web/static/src/js/views/basic/basic_model.js
parent6e15a9cd24eb5825ea615512a4ee834f131a60f7 (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/basic_model.js')
0 files changed, 0 insertions, 0 deletions