purchase_file_uploader

A vendor bill usually arrives as a file, and it usually relates to one or more purchase orders you already have. Creating the bill by hand and then matching it back is the slow path.

This widget is the fast one. Drop the file where the purchase orders are, and the server creates the bill against them with the file attached.

It works in two positions. On a single order it targets that order. In a list it targets the current selection, provided every selected order belongs to the same vendor.

Three-way matching, order to receipt to bill, is what stops overbilling, and it only happens if the bill is created from the order rather than beside it. Making that the path of least resistance is the whole point of this control.

The single vendor rule reflects a real constraint: a bill belongs to one vendor. Teams that batch scan supplier post should sort by vendor before uploading, which is worth saying explicitly in a process document.

Placing it

<widget name="purchase_file_uploader"/>

Works on both the list and the form.

What it targets

a record prop  -> that order
otherwise      -> the list's selected ids

Resolved at upload time.

The vendor rule

# more than one vendor in the selection
# -> a validation dialog, and nothing uploads

A bill belongs to one vendor.

The upload happens in two phases, and the split matters.

Each file is first created as an attachment on its own, with its name, type and content, using the current search context. The resulting identifier is pushed onto a list held on the component.

Only when every file has finished does the second phase run: one server call to create the invoice, passing both the target order identifiers and all the collected attachment identifiers together. One bill from several files, rather than several bills.

That collected list is cleared in a finally block wrapped around the creation call, which is the detail worth copying. Without it, a failed creation would leave stale attachment identifiers on the component and the next upload would silently include them.

Target resolution is the other half. With a record prop the widget uses that record's identifier; otherwise it asks the list for its selected identifiers. The same two-branch pattern appears in the getter that exposes the records themselves.

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 this page after the release.

The attachment payload key changes. The development branch writes the file content under the raw key rather than the data key when creating the attachment. Everything else, including the vendor check and the finally block, is unchanged.