d433e50f2f
An operator weighing a basket types 0.87 kg where the member ordered 1 kg, and a few hours later the line is back at 1 kg. Raising the quantity never reverts. The asymmetry is the reservation engine: below the demand the move goes back to `partially_available` (`_recompute_state`), which is exactly the state `_action_assign` looks for, while above it stays `assigned` and matches no domain. Two things call `_action_assign` on their own: the `Procurement: run scheduler` cron, and `_trigger_assign`, which runs every time another transfer of the same product is validated -- the second explains the "a few hours" better than a daily cron. Both respect one flag only, `picked`, and nobody was setting it: the checkbox is `optional="hide"` on the transfer form and absent from the detailed operation lists. So an onchange on `quantity` marks the record as picked. Onchanges only run from the interface, never from the reservation engine, so a manual edit is told apart from a reservation without guessing at contexts, and if the onchange ever stops firing the behaviour degrades to today's instead of freezing reservations across the system. `picked` also keeps `_free_reservation` from stealing the quantity when stock runs short elsewhere. The three lists where a quantity can be typed now load the field, since the client only sends back what the arch declares. When the typed quantity is below the demand, the demand follows it down. The move stays `assigned` and no backorder is asked for a weight that will never be completed. Only downwards: above the demand nothing needs adjusting. A line left at zero keeps its demand, so a transfer still offers its usual backorder choice for what was not delivered, and chained moves are only frozen -- lowering their demand would leave the next step of the route asking for more than this one delivers. `_pre_action_done_hook` needs the counterpart. Core auto-picks a transfer only when *no* move is picked yet, so freezing one weighed line would push the untouched ones to a backorder, or cancel them if the user answers "no backorder", with the goods already in the basket. Picking everything that carries a quantity keeps validation exactly as operators know it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
31 lines
1.2 KiB
Python
31 lines
1.2 KiB
Python
# Copyright 2026 Criptomart
|
|
# License AGPL-3.0 or later (http://www.gnu.org/licenses/agpl).
|
|
|
|
from odoo import models
|
|
from odoo.tools import float_is_zero
|
|
|
|
|
|
class StockPicking(models.Model):
|
|
_inherit = "stock.picking"
|
|
|
|
def _pre_action_done_hook(self):
|
|
"""Validate every line holding a quantity, picked by hand or not.
|
|
|
|
Core only auto-picks a transfer when *no* move is picked yet, so as
|
|
soon as an operator freezes one weighed line the untouched ones would
|
|
be pushed to a backorder -- or cancelled, if the user answers "no
|
|
backorder" -- even though their goods are in the basket. Picking
|
|
everything that carries a quantity keeps the behaviour operators know.
|
|
"""
|
|
for picking in self.filtered(lambda p: p.state not in ("done", "cancel")):
|
|
moves = picking.move_ids.filtered(
|
|
lambda move: not move.picked
|
|
and not move.scrapped
|
|
and move.state not in ("done", "cancel")
|
|
and not float_is_zero(
|
|
move.quantity, precision_rounding=move.product_uom.rounding
|
|
)
|
|
)
|
|
if moves:
|
|
moves.picked = True
|
|
return super()._pre_action_done_hook()
|