account_resequence_widget

Journal entry numbers are supposed to be a gapless, ordered sequence, and occasionally they are not: entries posted out of order, a sequence changed mid-year, a batch imported with the wrong prefix. Odoo has a wizard that renumbers a selection of entries to fix that.

Renumbering posted accounting documents is a serious action, so the wizard shows exactly what it is about to do before you confirm. This widget is that preview: a list of the affected entries with their current number and the number they will get, in the order the renumbering will apply.

It reads that list from a text field holding a JSON string, computed by the wizard. Nothing on the panel is editable and nothing is clickable; the options that change the outcome are the other fields on the wizard, and the preview redraws as they change.

The reason to show a preview at all is that the operation is hard to reverse and easy to misjudge. Renumbering the wrong range, or renumbering with the wrong ordering, produces a set of accounting documents whose numbers no longer match anything a customer or an auditor has seen. A visible before and after list turns that from a leap of faith into a check.

Sequence integrity matters differently by country. In jurisdictions that require gapless numbering, being able to correct a sequence and show what was corrected is part of staying compliant. In others it is housekeeping. Either way the person clicking confirm should be able to read the consequence, which is what this widget is for.

The core usage

<field name="preview_moves"
       widget="account_resequence_widget"
       nolabel="1" colspan="2"/>

No options and no label. The wizard's other fields, such as the ordering choice, drive what the preview contains.

The payload shape

{
  "ordering": "date",
  "changeLines": [
    {"new_by_name": "INV/2026/0007",
     "new_by_date": "INV/2026/0005",
     "current_name": "INV/2026/0011",
     "date": "2026-03-14"}
  ]
}

An object, not an array. The ordering key is what the renderer uses to decide which of the proposed numbers to show.

A fresh wizard

# field empty -> the widget renders
{ "changeLines": [], "ordering": "date" }

The fallback is built into the getter, so an unset field produces an empty panel rather than an error.

The file contains two components. A small one renders a single change line and takes the line plus the ordering as props, which is what lets the same line show a different proposed number depending on how the wizard is set to order the renumbering. The outer one is the field widget: it exposes a getter that parses the field's JSON, or returns the empty fallback, and passes the pieces to the template.

Parsing in a getter rather than in setup is the difference between this widget and several of its neighbours in the same module. Because the value is read on every render, changing an option on the wizard and having the server recompute the preview updates the panel in place. The batch sending summary next door, which reads its value once in setup, would not.

Odoo 16 did it differently again: the value was parsed in setup and re-parsed in a props-update hook, which achieved the same result with more machinery. Odoo 17 simplified it to the getter, and nothing has changed since.

There is no supported types declaration and no extractor, so the widget can be named on any field. What it needs in practice is a text field containing the object described above, which in core is produced by the wizard's own computation.

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

Byte-identical. The file on the development branch matches Odoo 19 exactly, including the getter-based parsing and the empty fallback. Any change to the preview will come from the wizard's server-side computation or its template.