sml_x2_many

Recording what was actually picked means saying which stock was taken: from which location, in which lot, in which package. Typed as free text that is slow and error prone, because the person filling it in has to know what is actually there.

This widget changes the add action on the detailed operations list. Instead of creating an empty move line, it opens a selection of the quants that genuinely hold the product, restricted to locations under the operation's source and to quants with stock on hand. You pick from what exists, and the move line is built from your choice.

It also does the arithmetic that makes repeated picking work. Lines you have already entered but not yet saved have not reduced anything in the database, so the widget subtracts them before deciding what to offer: a quant fully used up by your unsaved lines is not offered again, and a partially used one is.

The gain is accuracy at the point of entry. Warehouse staff pick from a list of what is physically there rather than recalling location codes and lot numbers, which removes an entire class of correction later, and the corrections in inventory are the expensive kind because they move stock valuations.

The unsaved-quantity handling is what makes it usable for a real pick. Splitting a move across three lots means adding three lines in one sitting, and without that adjustment the second and third selections would show stock the first line had already taken. Getting that right is the difference between a feature people use and one they work around.

The fallback matters too. When the move is not configured to show quants, the add action behaves exactly like a normal list, so the same view serves both operations where picking from stock makes sense and those where it does not.

The core usage

<field name="move_line_ids" widget="sml_x2_many"/>

No options. The behavior is decided by the move's own data and by the context the view supplies.

The fields and context it reads

# on the move
show_quant        # gates the whole quant behavior
product_id        # restricts the selection
# from context
default_location_id  # restricts to locations under it

Without the gate field the add action behaves like a standard list; without the location in context the selection is not restricted by location.

The plain list instead

<field name="move_line_ids">
  <list editable="bottom"> ... </list>
</field>

Adds an empty row and asks the user to fill in location, lot and package by hand.

The add action starts with a gate. If the move does not say quants should be shown, it delegates straight to the standard behavior and nothing else in the widget runs. That single check is what lets the same widget sit on every move line list.

When the gate is open, the widget first recomputes what it calls its dirty quant data: the quantities entered in the current, unsaved lines, grouped by the quant they came from. Those quantities have not touched the database, so the quant records still show them as available, and without this step the same stock would be offered twice.

It then builds the domain: the move's product, locations under the source location from context, and a positive quantity. When the on-hand switch is on, which it is by default, an additional condition restricts the selection to stock physically present. The unsaved quantities are then folded in, splitting the quants into those fully consumed, which are excluded, and those partially consumed, which remain.

The dialog itself is a select-or-create using a named simplified quant list, with a title naming the product, and a context marking it as a single product selection. Choosing rows creates the corresponding move lines; choosing to create instead opens the quant form, and the newly created quant is then selected, so even the create path ends with a real quant behind the line.

A small courtesy in the create path: the widget remembers which element had focus and restores it when the dialog closes, so keyboard entry continues where it left off.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The development branch is unstable and this may still change; we re-verify the page after release.

Byte-identical. The file on the development branch matches Odoo 19 exactly, including the unsaved-quantity handling and the hardcoded view references. Nothing about this widget changes in Odoo 20.