account_tax_repartition_line_factor_percent

An Odoo tax does not simply produce one amount. It distributes that amount across accounts and tax grids through repartition lines, each carrying a percentage. Most of the time those percentages are round numbers: a hundred percent to one account, or fifty and fifty.

Sometimes they are not. Splitting a tax three ways gives thirty three point three recurring, and a percentage rounded to two decimals does not add back up to a hundred. On a tax report that mismatch is a real problem, so the underlying field keeps far more precision than an ordinary amount.

This widget is what makes that precision usable. It sets the field's displayed precision to twelve decimals, then strips the trailing zeros so a clean fifty percent does not appear as fifty followed by a wall of zeros. And when a user types an expression, it rounds the result to the same precision before saving, so what appears on screen is exactly what is stored.

The reason to care is the tax report. Repartition percentages that do not sum exactly produce residual cents in tax grids, and those residuals are what an auditor or a tax office notices. Keeping twelve decimals is not perfectionism; it is what makes a three way split reconcile.

The display trimming matters for a different reason. A configuration screen that shows every value with twelve decimals is unreadable, and unreadable configuration screens get misconfigured. Showing fifty as fifty point zero zero and only extending when the value genuinely needs it keeps the common case clean while the uncommon case stays exact.

The practical advice for anyone setting up multi way tax distributions is to type the fraction rather than the decimal. The field accepts arithmetic, so entering the division directly gives the full precision, whereas typing thirty three point three three three by hand stops wherever your patience does.

The core usage

<field name="factor_percent"
       widget="account_tax_repartition_line_factor_percent"/>

No options. The twelve decimal precision and the trimming come entirely from the widget.

Entering a fraction

# typed into the field
= 100/3
# stored and displayed as 33.333333333333

The base float widget evaluates the arithmetic; this widget rounds the result to the field's precision so the saved value matches the display.

Overriding the precision

<field name="factor_percent"
       widget="account_tax_repartition_line_factor_percent"
       options="{'digits': [16, 4]}"/>

Legal, because the twelve decimals are a default prop rather than a hard rule. Rarely a good idea on a repartition line.

The trimming rule is more careful than it looks. The widget takes the formatted value, finds the run of digits at the end, and counts the trailing zeros in it. It then removes those zeros, but never more than the length of that digit run minus two. The effect is a floor of two decimals: fifty formats as fifty point zero zero rather than collapsing to a bare fifty, which keeps the column visually aligned with the other amounts on the form.

Values with no trailing zeros are returned untouched, and so are values whose formatted form ends in something other than a digit, so the rule degrades safely rather than mangling unusual formats.

The parsing override exists for a specific failure the source comment names outright. The base float widget lets a user type an expression, and the result of dividing one hundred by three is an irrational-looking float with far more digits than the field's precision. Without intervention the screen would show a rounded value while the database stored the unrounded one, and the two would disagree the next time anything summed them. The override rounds the parsed value to the field's own precision before it is written, so display and storage stay in step.

Everything else is the standard float widget: the same formatting, the same input handling, the same options. The subclass is thirty lines and changes two methods and one default.

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.

No behavior change. The trimming rule, the rounding on parse and the twelve decimal default are all identical. The only difference is the migration to the new Owl props syntax, where the default precision becomes an optional prop with the same default value instead of a static default.