forecast_widget

On a delivery order or manufacturing order, each line answers one question: can this quantity ship? forecast_widget is the answer rendered as a pill badge on the line's forecast_availability field.

The decision tree, read directly from the component and its template, is short. If there is no forecast expected date and the forecast availability covers the demanded quantity, the badge is green and reads Available. If an expected date exists and the quantity will be covered, the badge shows Exp plus the date, orange normally, red when that expected date lands after the line's deadline. In every other case it is a red Not Available.

The number itself never renders. The float value drives the comparison against product_qty, and the badge communicates only the verdict.

This badge is the fastest stock triage tool in Odoo: a warehouse manager scans a delivery's lines and instantly separates what ships today, what ships late, and what is blocked. The orange state deserves attention in training, because it does not mean trouble. It means replenishment is already scheduled and the line will be covered by the shown date; red on the same badge means that date breaks the customer deadline.

The click-through matters just as much: clicking the badge opens the product's Forecasted Report, the same screen behind the Forecast smart button, pre-focused on the product. That turns a red line into an immediate answer to "why not, and when."

Two silent rules avoid confusion. Nothing happens when clicking a line that has never been saved, and since 19.0, nothing happens for non-storable products either, because consumables and services have no stock forecast to show.

How core applies it (delivery order lines)

<field name="forecast_availability" string="" widget="forecast_widget"
       column_invisible="parent.state in ('cancel', 'done') or parent.picking_type_code not in ['internal', 'outgoing']"/>

Core blanks the column label and hides the badge entirely on finished transfers and on receipts, where availability is meaningless.

Reusing it on a custom view

<field name="forecast_expected_date" column_invisible="True"/>
<field name="product_qty" column_invisible="True"/>
<field name="is_storable" column_invisible="True"/>
<field name="forecast_availability" widget="forecast_widget"/>

The invisible companions are the whole trick; see the deep dive for why.

Most specialized widgets declare fieldDependencies so the framework fetches the extra fields they read. forecast_widget declares none. It reaches into the row's data for forecast_expected_date, date_deadline, forecast_availability, product_qty, is_storable and state, and silently gets undefined for any of them the view did not load. Core views therefore carry those fields as invisible columns, and a custom view that forgets one gets a badge that is wrong rather than broken: a missing product_qty makes every line look unfulfilled, and a missing is_storable makes the click do nothing.

The fulfillment comparison has a subtle guard against float noise: both forecast_availability and product_qty are run through the float formatter with the field's precision and parsed back before comparing, so a stored 4.999999999 demanded as 5.0 compares equal at precision instead of flagging a phantom shortage.

Version history of the fine print: 16.0 and 17.0 also formatted a reserved_availability field, 18.0 read quantity instead, and 19.0 dropped that side value entirely. The is_storable click gate is 19.0-only, matching the field that replaced product types in 18.0.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The notes below come from diffing this file against the public development branch, which is unstable until feature freeze; we re-verify once the release ships.

Two small changes are visible. The click guard loses its resId check: _openReport only verifies is_storable, so clicking the badge on a not-yet-saved line would attempt to open the report rather than doing nothing. And the component stops capturing the line's state, which 19.0 stored but the template already used only indirectly. No option changes, no registration changes, and the badge logic itself is untouched.