l10n_ro_edi_stock_document_state

Romanian transporters declare goods movements to ANAF's e-Transport platform, and each declaration lives in Odoo as a document record on the transfer: a state, a UIT code, a timestamp and a message holding whatever the government API answered. This widget renders that state column on the document lists.

It is deliberately tiny. The class extends DocumentState from the account module and overrides a single getter, the one that feeds the popover. Where the parent shows message verbatim, this subclass splits the text on newlines, throws away blank lines, and then chooses a format: exactly one surviving line is shown as-is, while two or more are each prefixed with a bullet and rejoined, so a batch of ANAF validation errors reads as a list instead of a wall of text.

Everything else, the info icon that appears only when a message exists, the top-anchored popover, the clipboard button, the selection rendering underneath, is inherited untouched, which also means the companion field contract is unchanged: the view must load a field literally named message.

e-Transport declarations fail in clusters: a missing net weight, an invalid location code and a bad vehicle plate arrive as one multi-line rejection. For the logistics clerk fixing the transfer, the difference between a bulleted list of three problems and a run-on paragraph is whether the second and third errors get fixed before the retry. UIT codes are legally required on transport documents, so unresolved rejections hold trucks, not just records.

The pattern generalizes: whenever an external system returns several errors in one response, a subclass overriding just the message getter is the cheapest way to make them readable. This widget is the canonical core example of doing exactly that, thirteen lines of real code on top of the shared document state machinery.

The core usage, from the batch transfer form

<list>
    <field name="message" column_invisible="1"/>
    <field name="datetime"/>
    <field name="state" string="Status"
           widget="l10n_ro_edi_stock_document_state"/>
    <field name="l10n_ro_edi_stock_uit" string="UIT"/>
</list>

State and UIT side by side, message loaded invisibly for the popover.

Reusing the bullet trick on your own integration

import { DocumentState } from "@account/components/document_state/document_state_field";

class MyApiState extends DocumentState {
    get message() { // reformat this.props.record.data.message }
}

Exactly the pattern this widget demonstrates: inherit the machinery, override only the text.

The getter is defensive in a way worth copying. Every step uses optional chaining, split, filter, map, join, so a record with no message, an empty string or whitespace-only lines degrades to an empty result instead of a crash, and the inherited template then simply skips the icon. The filter also trims each line before length-checking it, which quietly swallows the trailing newline ANAF responses tend to carry.

Two inherited behaviors read differently in this context. The popover copies the reformatted text, bullets included, because the clipboard handler reads the same getter, so what you paste into a ticket matches what you saw. And since the subclass keeps the parent's static template reference, there is no template file in l10n_ro_edi_stock at all: the module ships one JS file for the whole widget, a useful reminder that a widget is a descriptor, not necessarily markup.

Related and easy to confuse: the plain l10n_ro_edi module handles E-Factura invoices with the parent widget directly, while this one covers e-Transport on stock pickings and batches. Same state machinery, different government API, different module.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. We compared the widget on the public development branch at the time of writing, with the standard caveat about unreleased branches.

Byte-identical to 19, and its parent widget in account is unchanged too, so the whole chain carries over. We re-verify once Odoo 20 ships.