receipt_selector

A journal entry in Odoo has a document type: customer invoice, vendor bill, credit note, refund, sales receipt, purchase receipt, or a plain entry. Most of those are decided by how you got to the form, and users never think about them. Two pairs are genuinely a choice: a vendor document can be a bill or a purchase receipt, and a customer document can be an invoice or a sales receipt.

This widget is what surfaces that choice, as a small pair of radio buttons above the document title. It starts from the standard radio widget and then does three things: it removes every value that is not one of the two relevant ones, it rewrites the two labels so the receipt option reads as Receipt rather than its longer technical name, and it decides whether the choice should appear at all.

When it should not appear, the widget renders the document type as plain text. That covers credit notes and refunds, read-only forms, and the common case of a database that never turned sales receipts on.

The difference between an invoice and a receipt is not cosmetic. A receipt is used where payment happens at the point of sale and no credit is extended, which changes the accounting entries and, in several countries, the legal document requirements. Getting it right at document creation is far cheaper than reclassifying later.

What makes this widget worth understanding is the hiding rule, because it is the most common support question it generates. A finance user reads that Odoo supports sales receipts, opens a customer invoice, and sees no choice at all. The reason is a setting: outgoing documents only offer the receipt option when sales receipts are enabled for the database. Turn it on and the toggle appears.

The label rewriting is a small piece of interface craft worth copying. Both receipt values are shown simply as Receipt, because in the context of a document you already know is incoming or outgoing, the longer name adds nothing. The original label is kept for the read-only display, so the record still reads precisely when it is not being edited.

The core usage

<field name="move_type"
       widget="receipt_selector"
       options="{'horizontal': true}"
       invisible="move_type == 'entry'"
       nolabel="1"
       readonly="state != 'draft'"/>

The read-only expression matters: once the entry leaves draft the widget renders the document type as text, which is the correct behavior for a posted document.

Why the choice is missing

<!-- outgoing documents only offer Receipt when the
     database has sales receipts enabled -->

The setting is read once per session through a lazy session value, so enabling it takes effect on the next page load rather than instantly.

The values it groups

in_invoice   # Bill
in_receipt   # Receipt
out_invoice  # Invoice
out_receipt  # Receipt

Everything else in the selection, including credit notes, refunds and plain entries, is left out of the radio group entirely.

The filtering happens in the items getter, and it is worth reading closely because it decides from the current value rather than from anything in the view. If the record's document type is one of the two incoming values, the allowed set is the incoming pair. If it is one of the two outgoing values and the session says sales receipts are enabled, the allowed set is the outgoing pair. In every other case the allowed set stays empty and the getter returns the selection untouched.

That last branch is easy to misread. An empty allowed set does not blank the radio group; it returns the full selection, and the template is what prevents the full list from being shown. The template renders radio buttons only when the field is editable, the value is not a credit note or refund, and, for outgoing documents, sales receipts are enabled. Otherwise it prints a span with the label.

The labels themselves are handled carefully. The widget deep-copies the selection before rewriting it, so the record's own field definition is left alone, and the read-only branch uses a separate getter that looks the label up in the original selection. That is why a posted vendor receipt reads with its full name while the editable radio next to a bill reads simply Receipt.

The session value is fetched through Odoo's lazy session service in the component's startup hook, with a callback that updates local state when it arrives. So on a slow first load the widget can briefly render the text branch before the radio group appears, which is harmless but explains an occasional flicker.

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.

No behavior change. The development branch differs only in the migration to the new Owl props and reactive-state helpers. The document type groups, the label rewriting, the session lookup and the text fallback are identical, and core still uses the widget on the journal entry form.