quotation_document_many2many

Odoo's quote builder assembles a customer-facing PDF by wrapping the generated quotation in pages you supply: a cover, a company introduction, terms, a closing page. Those pages are uploaded PDFs attached to a quotation template.

This widget is the area where they are uploaded and shown. It does not invent an interface: it borrows the kanban renderer and upload button that product documents already use, so the cards, the drag and drop area and the upload flow are the ones people already know from products.

What it supplies is the context. Uploads are posted to the quote builder's own route, tagged with the quotation template they belong to, and restricted to PDF files, which is the only format that can be stitched into the output.

Branded quotations are a sales asset, and the reason they often do not exist is that producing them is a manual assembly job. Attaching the pages to a template once and having every quotation come out wrapped in them turns that into a setup task rather than a per-quote task.

The PDF restriction is worth stating to whoever uploads. A cover designed in a presentation tool has to be exported first; the upload area will not accept it otherwise, and the restriction is deliberate because the output is assembled by merging PDFs.

The other operational note is that the template has to be saved before documents can be attached. The widget captures the template's identity when it renders, so a brand new unsaved template has nothing to attach uploads to.

The core usage

<field name="quotation_document_ids"
       widget="quotation_document_many2many"/>

No options. The embedded kanban comes from the product document renderer the widget reuses.

What it posts

route: /sale_pdf_quote_builder/quotation_document/upload
form data: { sale_order_template_id: <the template> }
accepted: application/pdf

All three are set when the component starts and cannot be changed from the view.

The product equivalent

<field name="product_document_ids"
       widget="product_document_kanban"/>

The same interface for documents attached to a product, which is where this widget's renderer and upload button come from.

The widget is twenty lines, and almost all of its behavior is inherited. It supplies its own template, adds the upload button and the product document kanban renderer to its component list, and sets three instance values in its initialization.

The one behavior change in its history is where the template identity is captured. The Odoo 18 version recomputed it before every render, which meant it followed the record but did work repeatedly for a value that does not change during an edit session. Odoo 19 captures it once when the component starts.

That is fine on the core form, where the field appears on a saved template, and it is the thing to know if you reuse the widget: the identity is read at startup, so a field rendered before the record is saved will carry no template.

The accepted type is passed to the upload control rather than validated afterwards, so the file dialog itself filters to PDFs. A file dropped from outside that dialog would still be rejected server side, but the interface makes the constraint visible before the upload starts.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The development branch is unstable and this may still change; we re-verify the page after release.

Byte-identical. The file on the development branch matches Odoo 19 exactly, including the upload route, the accepted type and the startup capture.