account_payment_register_html

When you register a payment against an invoice that has payment terms, Odoo needs to tell you something: the full amount is due eventually, but only part of it is due now. That message is computed on the server, because working out which installment applies needs the payment terms, the dates and what has already been paid.

The result is a small piece of HTML placed on the wizard, and this widget renders it. What makes it more than a text field is one link inside that message. Clicking it sets the payment amount to the installment amount, so the user can accept the suggestion without retyping a figure.

The mechanism is deliberately blunt. The widget listens for clicks anywhere in the message and acts only if the clicked element carries a specific class. Everything else in the message, including any other link the server might generate, does nothing.

Partial payment against payment terms is where invoicing gets fiddly, and where a mistyped amount creates a reconciliation problem later. Offering the correct figure as a one-click choice removes the arithmetic from the person doing the data entry, which is worth more on a busy payment run than it sounds.

The design is also a good example of a pattern worth reusing: compute the message server side, where the business logic already lives, and give the client one narrow interaction rather than a general-purpose editor. The Odoo 19 rewrite made that explicit by dropping the rich editor the widget used to be built on.

The core usage

<field name="payment_difference_note"
       widget="account_payment_register_html"
       nolabel="1"/>

No options. The message and the switch link are produced by the wizard's own computation.

The markup the handler reacts to

<a class="installments_switch_button">
  Pay the installment only
</a>

The class is what the click handler checks. An element without it, however it looks, is inert.

The companion field it writes from

# on the wizard model
installments_switch_amount = fields.Monetary(...)
# clicking the link copies it into `amount`

Both names are read literally from the root record, so a custom wizard must use the same ones.

The Odoo 19 component is twenty lines: a getter that returns the field's value, and a click handler. The handler reads the clicked element from the event, tests its class list for the switch class, and if it matches, updates the wizard's amount from the companion field on the model root.

Two consequences follow from testing the clicked element itself rather than searching upwards. Clicking a nested element inside the link, for example a bold word or an icon, does not match, because the class sits on the parent. And the handler runs for every click anywhere in the message, which is cheap but means the interaction is entirely determined by the markup the server produced.

The update targets the model root rather than the field's own record, which on this wizard is the same object, but it is the reason the widget can change a different field from the one it is rendering.

The version story is the interesting part. In Odoo 18 this widget extended the rich HTML field from the editor module, which meant the whole editing stack was loaded to display a sentence with a link in it. Odoo 19 replaced that with a plain component that outputs the value, keeping the same click handling. The behavior a user sees is identical; the weight behind it is not.

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 hardcoded class and field name. Any change to the message itself will come from the server-side computation.