account_batch_sending_summary

Sending invoices in bulk is not one action. Some customers are set up for electronic invoicing, some get an email, some have to be printed, and some cannot be sent at all because something is missing. Firing that off blind is how a batch ends with a dozen silent failures.

Odoo's batch send wizard therefore computes a summary first: for the selection you made, how many documents will go out by which route. This widget is what puts that summary on screen. It takes the structure the server produced and renders it as a panel above the send button.

It does nothing else. There is no interaction, no option, no writing back. It is a display component registered as a field widget so that it can be positioned in a wizard form like any other field.

The value here is the confirmation step. A user who can see that forty two invoices will be emailed and three cannot be sent has a decision to make before anything leaves the building, rather than a list of failures to investigate afterwards. On a monthly invoicing run that difference is a morning.

It also makes the sending configuration visible at the moment it matters. Customers who are missing an email address, or who are set to a delivery method that is not configured, surface here rather than in a log. That turns a technical setup problem into something the person running the batch can act on.

What the panel cannot do is fix anything. It is a report on a computation, so the corrections happen on the customers or the invoices, and the wizard has to be reopened to see the effect.

The core usage

<field name="summary_data"
       widget="account_batch_sending_summary"
       invisible="not summary_data"
       nolabel="1"/>

The invisible expression is what keeps an empty panel off the screen. The widget itself renders whatever it is given.

On your own wizard

<field name="my_summary"
       widget="account_batch_sending_summary"
       invisible="not my_summary" nolabel="1"/>

Possible, but the template expects the structure the accounting wizard produces, so the server side has to match it.

What it will not do

<!-- no options are read, so this changes nothing -->
<field name="summary_data"
       widget="account_batch_sending_summary"
       options="{'anything': True}"/>

The registration has no extractor, so the options dictionary is never looked at.

This is one of the smallest field widgets in Odoo core: a component with the standard field props, a template, and a setup that copies the field's value onto the instance. That single assignment is the only logic in the file.

Reading the value in setup rather than in a getter is the detail worth recording. A getter would re-read the record on every render and the panel would follow any change to the field. As written, the panel is a snapshot taken when the component was created. On this wizard that is invisible, because the summary is computed by the server before the form is rendered and never changes while it is open, but anyone reusing the widget on a form where the value can change should know it will not refresh.

The absence of a supported types declaration is also worth noting. It means the widget can be named on a field of any type without the framework objecting; whether it renders anything sensible depends entirely on whether the value matches what the template expects.

Everything visible, the grouping, the counts, the wording of each line, lives in the template and in the server-side computation. There is no client-side logic deciding what to show, which is why the panel can change between versions without the JavaScript file changing at all.

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 on the development branch matches Odoo 19 exactly, including the single read in setup. Any change to what the panel shows on Odoo 20 will come from the server-side computation or the template rather than from this file.