autosave_many2many_tax_tags

Taxes in Odoo accounting are not a number written on a line. Choosing a tax makes the server generate additional lines on the same journal entry: the tax amount itself, and the tax grid allocations behind the tax report. Those lines are computed when the entry is saved.

On a form where the user is editing lines directly, that creates a lag. You pick a tax, nothing visibly happens, you carry on editing, and the tax lines appear only when you eventually save. Worse, the amounts you were reading while editing were incomplete.

This widget closes that gap. It is the standard tax tags field with a small piece of bookkeeping attached: whenever something changes that would alter the tax computation, it saves the whole journal entry so the server recomputes and the result appears immediately.

The value is confidence during data entry. An accountant encoding a manual entry can see the tax lines and the running balance settle after each change, rather than discovering at save time that a tax was applied to the wrong account. On entries with several taxed lines, that is the difference between checking as you go and reconciling afterwards.

The cost is that the document is committed continuously. Every tax change writes the entry to the database, so there is no such thing as trying a tax and discarding it. For a draft entry that is usually fine, and it is the trade Odoo chose deliberately, but it is worth telling a team that expects a form to be a scratchpad until they press save.

There is also a performance note. Each of these saves is a full write plus recomputation of the entry. On an entry with many lines, rapid tax changes mean repeated round trips, which on a slow connection feels like the form stuttering. It is not a bug, it is the widget doing exactly what it was built to do.

The core usage, trimmed

<field name="tax_ids" widget="autosave_many2many_tax_tags"
       optional="hide"
       domain="[('type_tax_use', '=?', parent.invoice_filter_type_domain)]"
       context="{'active_test': True}"/>

Hidden by default as an optional column, with the tax type filtered to match the document. The autosave is not configurable and applies whenever the column is shown.

The companion fields it needs

<field name="balance"/>
<field name="account_id"/>
<field name="partner_id"/>
<field name="tax_ids" widget="autosave_many2many_tax_tags"/>

All four are read by name. None is declared as a dependency by the widget.

Without the autosave

<field name="tax_ids" widget="many2many_tax_tags"/>

The parent widget: same dropdown behavior, but tax lines only appear when the user saves the entry.

The widget captures three values when it starts: the line's balance, its account and its partner. It then installs a record observer that runs on every change to the line, and compares the current values against the captured ones. If they differ and the line already carries at least one tax, it refreshes the captured values and saves the root record.

That extra condition is the part worth noticing. A line with no taxes can have its balance and account changed freely with no saving at all, because nothing tax-related would be recomputed. The autosave only becomes active once a tax is on the line, which keeps ordinary entry editing responsive.

Adding and removing taxes take a different route. The component's update method is wrapped so that after the tags are written, the root record is saved; and the delete handler is overridden to do the same after removing a tag. Both call the same save, so all four triggers converge on one behavior.

The save target is the model's root record rather than the line. On a journal entry form the line is a child of the entry, and tax lines are a property of the entry as a whole, so saving the line alone would not produce them. This is also why the effect is a full document write each time.

One inherited behavior is worth contrasting with its neighbor in the same list. The tax tags autocomplete this widget builds on always appends a Search more entry to the dropdown, even when the standard logic would omit it, while the account picker one column to the left suppresses that same entry unless you type a digit. Two adjacent columns on the same row, two opposite decisions, both deliberate.

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 widget file matches Odoo 19 exactly on the development branch, including the hardcoded field names and the condition that the line must already carry a tax. Core still uses it on the journal entry line tax column.