analytic_distribution

Analytic accounting answers the question financial accounts cannot: not just how much was spent, but on which project, department or cost center. The analytic_distribution widget is the entry point for that data. On a journal item, an expense line or a purchase order line, it shows the current split as compact tags, each an analytic account with its percentage, and clicking in opens a dropdown editor where the user distributes the line across accounts, one column per applicable analytic plan.

It is one of the largest field widgets in Odoo, around 750 lines in the 19.0 source, because it is really a small application: it loads the applicable plans, validates percentages against the fetched precision, positions its editor like a popover, and knows how to read neighboring fields on the record to suggest the right split.

The underlying field is JSON. That is also the widget's declared supported type in 19, a change from 18, where the same widget declared char and text.

Cost visibility per project or department is one of the top three reasons companies implement Odoo Accounting, and this widget is where that visibility is won or lost. If entering the split is slow, people skip it, and every report downstream shows an Unallocated bucket nobody can explain at quarter close.

Two configuration decisions drive adoption. First, distribution models: recurring splits, rent 60/40 across two departments for example, should be saved as templates so the widget applies them automatically, and users only touch the exceptions. The widget supports creating those templates from the editor itself. Second, mandatory plans: applicability rules decide whether a missing split blocks posting or passes silently, and the widget's force_applicability option can tighten that per view.

Our rule from accounting implementations: make the split automatic for 90 percent of lines via models and defaults, and the remaining 10 percent will actually get filled by hand.

Standard usage on a line model

<field name="analytic_distribution" widget="analytic_distribution"/>

Renders the tags plus editor against all applicable analytic plans.

Wiring the record context for better suggestions

<field name="analytic_distribution"
       widget="analytic_distribution"
       options="{'product_field': 'product_id', 'account_field': 'account_id', 'amount_field': 'price_subtotal'}"/>

Points the widget at the line's product, financial account and amount, the mapping core uses on journal items so distribution model matching sees the right context.

List view with multi-edit, without instant saving

<field name="analytic_distribution"
       widget="analytic_distribution"
       options="{'multi_edit': True, 'disable_save': True}"/>

multi_edit lets a selection of lines take the same split in one edit; disable_save switches the widget's own save behavior off so the surrounding flow stays in charge.

Details from the source that shape real implementations.

The precision comes with the field. The widget declares analytic_precision as a fieldDependency, so it is fetched automatically for every record, and percentage rounding runs through the shared rounding helper against it. If splits keep rounding to whole percents, that precision setting, not the widget, is what to change.

Templates are create-only from the widget. The editor's save-as-model path opens account.analytic.distribution.model with create and write enabled but edit disabled, meaning users can capture the current split as a new template but never land in an existing template's form from here. Managing existing models happens in Accounting configuration.

An attribute hides among the options. extractProps reads business_domain_compute from the element's attributes, alongside the business_domain option. If you set it as an option it does nothing, one more reason copying core view XML beats reconstructing it from memory.

The editor manages its own closing. Clicks inside popovers and active modals do not close it, a window resize closes it on desktop but deliberately not on mobile, and the whole thing repositions through the standard positioning hook. Worth knowing before you file a cannot-reproduce UI bug.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. We diffed this widget against the public development branch at the time of writing; the branch is unstable until feature freeze, and we re-verify after release.

The option surface is untouched: all eight options, the json type, the analytic_precision dependency and the extractProps mapping are byte-for-byte identical to 19. The internals are not: the tag rendering moves to a new badge component, an offline-handling plugin appears, and the component migrates to the new Owl syntax. In short, XML views carry into 20 unchanged on current evidence, while JavaScript patches against the component internals will need rework.