mrp_should_consume

A manufacturing order is rarely produced all at once. You set out to make five, you actually finish three today, and the question every component line has to answer is whether the material consumed so far matches what those three should have taken.

The bill of materials knows the ratio, and the server computes the expected figure. This widget puts it beside the consumed quantity, so the line reads as a comparison rather than as a number without context.

It only does that while the comparison means something. On a draft order nothing has been consumed, and on a finished or canceled one the expectation is history, so in those states the widget shows the quantity alone.

Component variance is where manufacturing margin quietly leaks. A line consistently consuming more than the bill of materials expects is either a recipe that is wrong or a process that is wasteful, and both are invisible if the operator only ever sees one number.

Putting the expectation on the line moves that check to the moment of consumption, where it can still be acted on, rather than into a variance report read weeks later.

The state gating is worth explaining to operators: the second figure disappearing on a completed order is intentional, not a display fault.

The usual usage

<field name="quantity" widget="mrp_should_consume"/>

The consumed quantity, with the expected figure beside it while the order is in progress.

The companion field

<field name="should_consume_qty" column_invisible="True"/>

Read by literal name and formatted with its own precision.

When it shows one number

# order state in draft, done or cancel
# the expected figure is hidden

The comparison only appears while production is under way.

The source opens with a worked example that is worth quoting in substance: two components make one finished product, the order is for five, the quantity being produced is three, and the widget shows three against five. That is the entire concept.

Which states show the comparison is decided once when the component starts, from the order's state. Draft, done and canceled all suppress it. Because that decision is made at setup rather than in a getter, a state change while the row is on screen does not toggle the display until the list is redrawn.

The formatting detail matters more than it looks. The expected figure is formatted using the companion field's own definition rather than the consumed field's, with any node options merged in. Two quantities on the same line can therefore render with different precision, which is correct when the fields declare different digits.

The last piece is cosmetic but deliberate: after mounting and after every patch, the widget adds the standard number field classes to the input element, so the paired rendering still looks like an ordinary numeric cell rather than a custom control.

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 this page after the release.

Behavior is unchanged. The comparison, the state gating and the separate formatting of the expected figure all behave the same on the development branch.