lead_days_widget

When Odoo decides when to reorder a product, it adds up several delays: how long the supplier takes, the security days you add on top, the time the warehouse needs to receive and put away, and any purchase lead time configured globally. The result is a single number that drives the reordering date, and on its own it explains nothing.

The replenishment information dialog breaks that number down, and this widget renders the breakdown. The server computes the components and their total into a JSON payload, stores it in a text field, and the widget parses it and hands it to a template.

That is genuinely all it does. The widget is five lines: a template name and a shared base that parses the field. Everything a user sees, the labels, which components are present and how they add up, is decided in Python.

Reordering rules are trusted only when people can see why they fire when they do. A buyer who thinks the system orders too early, or too late, is usually reacting to a lead time component they did not know was configured, most often the security days or a warehouse handling delay.

Putting the breakdown in front of them turns that from an argument into a configuration conversation. It is also the fastest way to audit a supplier setup: if the supplier delay is wrong, it shows here rather than in a report nobody runs.

For anyone building similar explanations, the pattern is worth copying. Computing a small JSON payload server side and rendering it with a minimal widget keeps all the business logic in Python, where it can be tested, and keeps the browser side trivial.

The core usage

<field name="json_lead_days" nolabel="1"
       colspan="2" widget="lead_days_widget"/>

No options. The field holds the JSON the server computed for that replenishment rule.

What the field has to contain

{
  "lead_days_date": "2026-09-14",
  "lead_days_description": "...",
  "...": "whatever the template reads"
}

The exact keys are the template's contract with the server-side computation, not something the widget imposes.

Its sibling in the same file

<field name="json_replenishment_graph"
       widget="replenishment_graph_widget"/>

Built on the same base, rendering a chart instead of a panel.

The shared base is worth describing because two widgets depend on it and neither adds much. It is a component with the standard field props, an empty template name, and a single getter that parses the field's value as JSON. The descriptor gives it a display name and declares a single supported type.

Each concrete widget then supplies its own template name and, in the graph's case, a lot of chart code. This one supplies only a template name, which is why the file's Lead Days section is five lines long.

Two consequences follow from the base being this thin. There is no error handling: an empty field, a null, or a malformed string all raise from the parse, so the calling view has to guarantee the payload. And the getter re-parses on every access, so the panel does follow a recomputed value, unlike several other JSON-driven widgets in Odoo that parse once at setup.

The registration style is the only thing that has moved across versions. Odoo 16 registered the component class directly, which meant the declared type and display name were attached to the class; Odoo 17 introduced the descriptor object still used today. Neither change affects views.

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.

Unchanged. The Lead Days part of the file is identical on the development branch. The changes in that file all belong to the graph widget, which moves to a shared chart hook.