l10n_in_hsn_autocomplete

Every product sold in India needs an HSN code, and every service a SAC code. They are classification numbers from a government schedule, they determine the GST rate, and nobody remembers them. Looking one up normally means leaving Odoo for the GST portal, searching there, and copying a number back.

This widget removes that round trip. As you type in the HSN field it queries the GST portal's own search service and shows the matching codes as suggestions, with their official descriptions. Choosing one writes the code, and can also write the description into a second field.

The search adapts to what you type. If the input is digits only, it searches by code. If it contains anything else, it runs two description searches in parallel, one for products and one for services, so the same box works for both classifications.

Wrong HSN codes are a compliance problem with a direct cost: the code drives the GST rate on the invoice, and a mismatch turns into a return correction or a notice. Getting the classification right at product setup, from the official source, is cheaper than reconciling it afterwards.

The point that belongs in a deployment decision is where the request comes from. The call is made by the browser of whoever is editing the product, straight to the government service. Your Odoo server is not involved. That means it works without any server-side network configuration, and equally that it will not work for a user behind a network that blocks the destination, and that the request carries whatever the user's browser carries.

It also means the feature degrades rather than breaks. If the service is unreachable or slow, the dropdown shows a single entry saying it could not contact the API, and the field remains an ordinary text input the user can type into. Nothing blocks saving the product.

The core usage

<field name="l10n_in_hsn_code"
       widget="l10n_in_hsn_autocomplete"
       invisible="'IN' not in fiscal_country_codes"/>

The field is hidden entirely outside Indian fiscal setups, which is why most Odoo databases never see this widget.

Filling a description too

<field name="l10n_in_hsn_code"
       widget="l10n_in_hsn_autocomplete"
       options="{'hsn_description_field': 'l10n_in_hsn_description'}"/>

With the option set, choosing a suggestion writes both the code and its official description in one update.

What no longer works on this field

<!-- the placeholder is silently ignored -->
<field name="l10n_in_hsn_code"
       widget="l10n_in_hsn_autocomplete"
       placeholder="e.g. 8471"/>

The widget's extractor does not read it, so it never reaches the input.

The request logic is worth spelling out because it is unusual for an Odoo widget. Three query shapes are defined: search by code, search product descriptions, and search service descriptions. If the typed value is numeric and contains no space, only the code search runs. Otherwise the two description searches run in parallel.

Each request carries its own abort controller with a five second timer, so a slow service does not leave the dropdown hanging. All the requests are awaited together, and any failure anywhere collapses into a single suggestion reading that the API could not be contacted, plus a console warning. There is no retry.

Results are filtered before they are shown: an entry whose code is three characters or shorter is discarded. HSN codes are used at four, six or eight digits depending on turnover, so the shortest schedule entries are noise for a product form.

Selecting a suggestion is wrapped in a deferred call rather than being applied immediately. That is a common pattern when a selection has to land after the autocomplete has finished closing, and it means the write happens on the next tick rather than inside the click handler.

Between Odoo 18 and Odoo 19 the suggestion objects were restructured: each one now carries the description as data and its own selection handler, rather than being mapped into a flat list. The behavior a user sees is the same, but a custom module patching the suggestion shape will notice.

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 service address, the three query shapes, the five second timeout, the three character minimum and the code length filter are all identical. The differences are the migration to the new Owl props and reference helpers, which affect patches rather than views.