Hong Kong payroll rental records now use an attachment button for payment proofs, making it easier to add and manage supporting documents. The rental similarity check was also refined to avoid misleading duplicate warnings, especially after data migrations or for the same employee.

As the system now starts to be used by real users, we noticed a few points of improvement that can easily be done in stable and will provide a better UX when interacting with the system.

The payment proof as a field was a consequence of multiple iterations of the system; but it ended up only as a way to input the proof and nothing else.
It is confusing, only allows one proof at a time, and is overall not nice to use.
To improve that, we will remove the field and replace it with an 'Attach Payment Proof' button similar to the expense app, allowing for a better experience.

The similar rental check was checking even if all the related fields were empty. On a database migrating from a previous version, this leads to ALL the rentals to be marked as similar, which isn't ideal.
The same check was also comparing multiple rentals from the same employee as long as they are active. As rentals for an employee cannot overlap, it makes no sense to check this case and cause false positives.

task-6448054

Forward-Port-Of: odoo/enterprise#126764

Currently, Peppol product detection relies strictly on barcode or default_code matching, which fails when vendors use their own codes. Accurate product identification is essential before running the predictive model (for taxes/accounts) and is a strict prerequisite for Purchase Orders matching to function correctly. This PR makes the product matching relies on the Vendor Product Code as the first priority ( SellersItemIdentification or StandardItemIdentification or BuyersItemIdentification

Currently, Peppol product detection relies strictly on barcode or default_code matching, which fails when vendors use their own codes.

Accurate product identification is essential before running the predictive model (for taxes/accounts) and is a strict prerequisite for Purchase Orders matching to function correctly.

This PR makes the product matching relies on the Vendor Product Code as the first priority ( SellersItemIdentification or StandardItemIdentification or BuyersItemIdentification )

task-6171251

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#262801

The Hong Kong payroll rental workflow now uses an attachment button for payment proofs, making it easier to add and manage supporting documents. The similar-rental detection was also refined to avoid misleading matches after migrations and prevent false warnings for the same employee.

As the system now starts to be used by real users, we noticed a few points of improvement that can easily be done in stable and will provide a better UX when interacting with the system.

The payment proof as a field was a consequence of multiple iterations of the system; but it ended up only as a way to input the proof and nothing else.
It is confusing, only allows one proof at a time, and is overall not nice to use.
To improve that, we will remove the field and replace it with an 'Attach Payment Proof' button similar to the expense app, allowing for a better experience.

The similar rental check was checking even if all the related fields were empty. On a database migrating from a previous version, this leads to ALL the rentals to be marked as similar, which isn't ideal.
The same check was also comparing multiple rentals from the same employee as long as they are active. As rentals for an employee cannot overlap, it makes no sense to check this case and cause false positives.

task-6448054

Receipt printers in Point of Sale IoT now use the same broader printer selection rules as preparation printers. This helps ensure eligible printers are available for receipt printing, reducing configuration friction for businesses using connected POS hardware.

In odoo/enterprise#124306, we removed the subtype
from the printer domain, but only for preparation printers.

We also update it for receipt printers.

Forward-Port-Of: odoo/enterprise#127142
Forward-Port-Of: odoo/enterprise#125648

Users can now use AI-powered document sorting without needing a Studio subscription. This makes the AI sorting workflow available to more document users and removes an unnecessary licensing barrier.

Purpose
=======
We changed our mind, and we should be able to sort documents with AI without having to pay for studio.

Revert of bc15543b5ce563bdddb54198eaaf00a5c8d01e54

Task-6383816

This commit adds 3 new `Tax Exemption Reason Code`: - VATEX-FR-F - VATEX-FR-I - VATEX-FR-J task-6333649 Forward-Port-Of: odoo/odoo#280537 Forward-Port-Of: odoo/odoo#278086

This commit adds 3 new `Tax Exemption Reason Code`:

- VATEX-FR-F
- VATEX-FR-I
- VATEX-FR-J

task-6333649

Forward-Port-Of: odoo/odoo#280537
Forward-Port-Of: odoo/odoo#278086

Doing an euclidean division on floats with the native operators is unreliable: because of IEEE-754 representation errors, `value1 % value2` can return a spurious remainder (e.g. `50.4 % 16.8 == 16.799999999999997` instead of 0.0) and `int(value1 / value2)` can truncate the quotient one step too low (e.g. `int(0.3 / 0.1) == 2` instead of 3). `float_div` returns the `(quotient, remainder)` pair free of those errors. The key is to never run a lossy `%` or `//` on the raw floats. Instead both ope

Doing an euclidean division on floats with the native operators is unreliable: because of IEEE-754 representation errors, `value1 % value2` can return a spurious remainder (e.g. `50.4 % 16.8 == 16.799999999999997` instead of 0.0) and `int(value1 / value2)` can truncate the quotient one step too low (e.g. `int(0.3 / 0.1) == 2` instead of 3). `float_div` returns the `(quotient, remainder)` pair free of those errors.

The key is to never run a lossy `%` or `//` on the raw floats. Instead both operands are first snapped onto the precision grid with `float_round` and then scaled to integers: since a grid-snapped value is a multiple of `rounding`, dividing it by `rounding` counts how many grid steps it spans. That division is still noisy (`4.35 / 0.05 == 86.99999999999999`), so the result is passed through `builtins.round` to coerce it to the exact integer step count. The euclidean division itself is then a plain integer `divmod`, which is exact, and the remainder is scaled back to real units. This is why the correction is applied to the inputs and not to the output: rounding the result of a native `%` would only round an already-corrupt value, and would still misreport the quotient in the corner cases the util exists to handle.

Dividing by `rounding` is meaningful for any precision, not only powers of ten: the grid step can be `0.05`, `0.25`, `0.5`, `0.03`, ... and `value / step` counts the steps in every case. This mirrors the normalize/denormalize scheme `float_round` already uses internally.

The util shares `float_round`'s inherent limitation: the scaled step count must stay representable as an exact `float` integer, so exactness is lost past ~2**53 grid steps (extreme magnitudes at a fine precision). This is the IEEE-754 double-precision ceiling and is well outside any realistic quantity or price range.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#280883
Forward-Port-Of: odoo/odoo#277160

Receipt printer setup now uses the same broader printer matching rules already applied to preparation printers. This helps point-of-sale teams select compatible IoT printers more consistently and reduces unnecessary configuration restrictions.

In odoo/enterprise#124306, we removed the subtype
from the printer domain, but only for preparation printers.

We also update it for receipt printers.

Forward-Port-Of: odoo/enterprise#125648

The checks the Tax Agency performs are always based on the latest version of their XSD (no API versioning), but the XSD URI changes with each new version of the checks. Since it's not functionally used, it's not so important to keep it always updated and yet now: - we now update the export templates to have the latest `schemalocation` URI for once. - we start ignoring namespaces in l10n_it_* XML tests - we start ignoring the root FatturaElettronica tag's namespace attributes so there

The checks the Tax Agency performs are always based on the latest version of their XSD (no API versioning), but the XSD URI changes with each new version of the checks.

Since it's not functionally used, it's not so important to keep it always updated and yet now:

- we now update the export templates to have the latest `schemalocation` URI for once.
- we start ignoring namespaces in l10n_it_* XML tests
- we start ignoring the root FatturaElettronica tag's namespace attributes

so there won't be a problem in case we change the `schemalocation` again.

Forward-Port-Of: odoo/odoo#280795
Forward-Port-Of: odoo/odoo#275345

Receipt printer selection now follows the same broader matching rules already applied to preparation printers. This helps businesses connect compatible point-of-sale IoT printers more reliably without unnecessary filtering.

In odoo/enterprise#124306, we removed the subtype
from the printer domain, but only for preparation printers.

We also update it for receipt printers.

Forward-Port-Of: odoo/enterprise#125648

Receipt printer selection in Point of Sale now uses the same broader printer matching rules already applied to preparation printers. This helps ensure compatible IoT printers can be selected consistently, reducing setup friction for stores.

In odoo/enterprise#124306, we removed the subtype
from the printer domain, but only for preparation printers.

We also update it for receipt printers.

Forward-Port-Of: odoo/enterprise#125648

Belgian payroll now shows a warning when an employee has both private car kilometers and bike kilometers set for the same daily reimbursement context. This helps payroll teams spot combinations that cannot legally be reimbursed together without blocking their workflow.

Problem:
Legally, the daily reimbursement of bike travel and private car travel cannot be cumulated. We don't want to prevent the user from doing so, but we still want to warn them.

Solution:
We added an explicit warning on the employee form using the `hr.payroll.warning` model.

Task-6389211

Accounting-related automated tests were updated to match a platform change in how journal entry line descriptions are stored. This helps keep quality checks aligned with the latest accounting data model without changing business workflows.

This commit updates the HOOT tests to reflect the community change where the `account.move.line` `name` field has been converted from `Char` to `Text`.

See the corresponding community commit for additional details.

See Also:
- https://github.com/odoo/odoo/pull/278081
- https://github.com/odoo/upgrade/pull/10909

Users can now prepare and send signature documents from a phone using a mobile layout with easy access to fields, signers, and documents. The editor also improves drag previews, selection highlighting, and touch controls so mobile setup is more practical and reliable.

Preparing a document for signature on a phone was nearly impossible.
The editor relies on a desktop side panel that does not fit on a
small screen: the field types could not be reached or dragged onto
the document, and there was no usable way to manage the signers or
the documents. In practice, users had to wait until they were back
on a computer to prepare and send a signature request.

On small screens, the side panel is now replaced by a bottom sheet
with three tabs (Fields, Signers, Documents). Fields are dragged
from the sheet onto the document — the sheet steps aside during the
drag — and signers and documents are managed like on desktop. The
sheet resizes to a few useful heights and moves up while typing so
the keyboard does not hide what is being edited.

The layout is selected on env.isSmall, which swaps the sidebar for a
new SignTemplateMobileShell while the SignTemplate root and its state
stay shared. The shell is a bottom sheet that snaps between three
heights (peek, half, full) via a handle drag with flick-velocity
detection, and collapses on Escape or the hardware back button; while
an input is focused it expands and pads its content by the keyboard
overlap derived from the visual viewport. The Signers and Documents
tabs extend the desktop sidebar components, inheriting their behavior
and overriding only the template.

task-5149968

Belgian payroll eco voucher calculations now use working days to determine employee entitlements. This improves payroll accuracy and helps align voucher amounts with actual work patterns and related compliance checks.

CRM lead cards no longer show the phone plus/minus control for quickly adding or removing call activities, reducing visual clutter for upcoming designs. Users now add call activities through a selection-based action in kanban or list views, also available for contacts, with clearer handling when records already have a call or lack a phone number.

*: test_mail_enterprise

Before this commit, on CRM leads kanban cards, there was a phone and plus/minus icon button that allowed users to easily add/remove call activities due or overdue for today for that lead. While this was nice, it encumbered the card and will not fit nicely in new designs anymore.

Instead, this is replaced by an action button that appears when you select records, in kanban or lists. This is also added for simple contact records (all models using the `voip.queue.mixin` at the moment).

Side-effects:
- You don't have to possibility to delete calls from the queue easily anymore (you have to do it one-by-one). Functionally it might be better to have the opportunity to cancel and log the reason anyway.
- If you try to add a call activity while there is already one, it does nothing for the related call.
- If you try to add a call activity but there is no phone number, it will prevent you to add the activity on all selected calls (with a message explaining what record prevented the action).

task-6377768

The Mexico electronic invoicing payment method settings are now placed under the main Accounting menu. This aligns the enterprise menu with recent community changes, making the option easier to find in its expected location.

Move to the accounting root menu where it belongs.

See also:

- https://github.com/odoo/odoo/pull/280715

The signing app had an unused internal messaging setup removed. This cleanup reduces maintenance overhead without changing how users create or manage signature requests.

This commit removes a `useSubEnv` which defined a bus and is not used anymore.

This update adds automated checks for the POS IoT payment connection logic. It helps reduce the risk of payment terminal issues reaching customers by catching problems earlier during development.

We add tests for the `PaymentInterfaceIot` class.

Users can now resend invitations to document members who were previously invited but have not signed up yet. This makes it easier to follow up with pending collaborators directly from the document sharing dialog, without affecting active members.

This commit allow users to re-invite document members who were previously invited
but haven't logged in yet, from the document share dialog.

The 're-send' option is only displayed for members who have not signed up yet.

Task-6040696

The map view now uses the clicked item’s intended opening mode instead of guessing whether to open records in the current view, a new window, or a dialog. This makes interactions more consistent, reuses configured list and form views, and supports opening multiple records in a dialog when needed.

This is a follow-up of 75cac501edd, the controller no longer infers by itself whether a record should open in a dialog: the caller now passes an explicit target ('current', 'new_window' or 'dialog'), matching what the template already knows when a click comes from the unlocated records list.

Also reuse the list/form view ids defined on the action (same approach as the pivot view) instead of hardcoding false, and extend the dialog target to support opening several records at once.

task-6378012

This update improves the reliability of automated tests by using a shared time-mocking helper across several Odoo Enterprise modules. It helps ensure date- and time-dependent test scenarios behave consistently, reducing false failures and supporting smoother quality checks.

Use the new function so that everything gets patched correctly.

https://github.com/odoo/odoo/pull/280810

This update adds a sandbox mode for Belgian DMFA payroll declarations, allowing tests to simulate official reporting flows without affecting real submissions. It helps teams validate payroll accounting behavior more safely and reliably before production use.

Recruiters can now use the AI email composer when refusing an individual applicant, not just when handling multiple applicants. This makes it easier to draft and edit consistent, professional refusal messages in the single-applicant workflow.

…se wizard

Refusing a single applicant now opens a dedicated wizard where the email body is rendered and editable. The mail_composer_chatgpt widget was only set up on the multi-applicant wizard, so it was missing there.

Inherit the new applicant.refuse.single form to add the widget, mirroring what is already done for applicant.get.refuse.reason.

task-6361850

Adds payroll withholding support for Michigan, Missouri, Kentucky, Utah, South Carolina, and Kansas. This improves payroll accuracy and compliance for employers operating in these states, including local city and county taxes where applicable.

Add state income tax withholding for Michigan, Missouri, Kentucky, Utah, South Carolina and Kansas.

Michigan and Kentucky are flat rate states with a personal exemption or standard deduction. Michigan also taxes residents and nonresidents of its 24 cities that have their own income tax. The rate depends on whether the employee lives or works there. Kentucky also has a county occupational tax. 87 of its 120 counties charge one, so we have to support it. We opted to create a new model l10n_us.res.county and add a m2o on res.city. It will be useful for tax reports down the line.

Missouri and South Carolina use progressive brackets. Missouri also withholds a flat 1% earnings tax for employees who live or work in St. Louis or Kansas City.

Utah uses a flat rate reduced by an allowance. That allowance gets smaller as wages go above a threshold, instead of a fixed exemption like other states.

Kansas' brackets and allowances depend on both pay frequency and filing status. Married filing jointly uses different numbers, but single, head of household, and married filing separately all use the same ones.

task-6270166

Belgian payroll now centralizes holiday attestation details for new hires and automatically calculates paid time off allocations and recoverable holiday pay amounts. This reduces manual work and errors when employees move between employers with different working schedules or rates.

[IMP] l10n_be_hr_payroll: Holiday attestations rework
Encoding the holiday pay attested by a new hire's previous employer was
split across separate simple/double N and N-1 fields on hr.employee and
an ad-hoc l10n.be.double.pay.recovery.line model, and the amount to
recover and number of days to allocate had to be computed by hand from
the certificate, which is complex and error-prone whenever the
employee's work rate changes.

This commit merges simple and double holiday pay encoding into a single
l10n.be.holiday.attest model on the payroll tab, and compute
automatically, from the certificate (previous year: days assimilated,
working regime, work fraction) and the current contract (current
regime and fraction):
- the number of paid time off days to allocate (LEAVE120 allocation
  and a dedicated unpaid work entry type/leave type),
- the maximum amount to recover, prorated against the employee's work
  rate so that a change of regime between the two employers no longer
  requires a manual computation.

task-5928591

This update adjusts Belgian payroll work entry settings so the right working schedules remain available when new schedule-selection data is used. It also removes a recently added restriction that could unnecessarily limit schedule choices for payroll users.

related PR adds a new field resource_calendar_selectable in the module hr_work_entry

this PR updates/sets the value of this filed for some work entry types and reverts Task#6333928 that added a restrictive domain on working schedules.

Task#6364149

The subscription portal now hides sections that do not contain any billable lines. This makes customer-facing pages clearer and avoids confusion from empty optional sections that looked like errors.

In portal, a section was always displayed even when it had no billed line. Empty sections (especially optional ones) gave the impression the page was bugged.

Only show a section when it contains at least one line to bill.

task-6280705

The salary contract update process was adjusted to use a cleaner data format when handling contract changes. This should make the flow more reliable and easier to maintain, including for Belgian payroll-specific handling.

The Belgian payroll rules now include the 2026 night work premium hourly rate for CP 200 employees. This helps payroll calculations stay aligned with the latest required rate for the upcoming year.

. Add cp_200_premium_pay_night_hourly_rate value for 2026

task-6443017

Belgian payroll now includes additional official reasons for ending an employee collaboration. This helps HR teams select the correct standardized reason when processing departures and improves alignment with Belgian reporting requirements.

Before ending the collaboration with employee in Belgium. We should put the reason behind the end of collaboration. There is given official list of end reason that can be used to explain it.

Currently, In belgium localization, there are few missing reason. In this PR expected to add the missing reason from the offical form:
- (1) end of contract due to notice given by the employer
- (2) end of contract due to termination by the employer
- (5) Force majeure because of the employee's permanent incapacity for work
- (7) End of contract for fix-term employmen
- (8) End of contract for specific work

task-6396239

This update prevents duplicate default prompt setups for the same AI agent context, reducing inconsistent behavior and runtime errors. Existing duplicates are cleaned up during upgrade so the new rule can be applied safely.

## Summary

This PR adds a unique index on `ai.composer` to prevent duplicate **Default Prompts** for the same **AI Agent**, **interface key**, and **focused model**.

Previously, multiple records could exist for the same `(ai_agent_id, interface_key, focused_model_id)` combination, leading to inconsistent data and runtime issues such as singleton errors when the AI composer expected a single matching record.

The unique index uses PostgreSQL's `NULLS NOT DISTINCT`, ensuring that `NULL` values in `focused_model_id` are treated as equal and duplicate generic Default Prompts are also prevented.

## Changes

- Add a unique index on the `(ai_agent_id, interface_key, focused_model_id)` triplet.
- Use `NULLS NOT DISTINCT` to enforce uniqueness even when `focused_model_id` is `NULL`.
- Add test cases to verify the unique constraint behavior.

## Upgrade

Duplicate `ai.composer` records are removed before applying the unique index.

Upgrade PR: https://github.com/odoo/upgrade/pull/10819

---

opw-6323764

Forward-Port-Of: odoo/enterprise#121609

This update strengthens the automated checks around scheduled marketing campaign activity processing. It helps ensure background marketing actions run with the right settings and reduces the risk of future regressions as the feature is expanded.

Just quickly cover cron usage when executing activities, aka the
other main marketing automation cron.

Improve other tests about cron usage.

Prepares Task-6425785 [marketing_automation] Incremental sync
Prepares Task-3866422 [marketing_automation] Overhaul application

Payment files now include the building number in ISO20022 address data, aligning SEPA credit transfer and direct debit exports with requirements that become mandatory in November 2026. This helps businesses remain compliant with upcoming banking standards and reduces the risk of payment file rejections later.

This commit adds the <BldgNb> node in the iso20022 XML files,
as it will be mandatory starting November 2026.

Linked: https://github.com/odoo/odoo/pull/271855

task-6317758

Forward-Port-Of: odoo/enterprise#126734
Forward-Port-Of: odoo/enterprise#121674

Payroll accounting entries are now grouped more efficiently when many payslips are processed together. This reduces validation time for large payroll runs, helping accounting teams complete batch processing much faster without changing the resulting entries.

Description
===========

When batch payroll journal items are enabled, all payslips for the same journal and accounting period contribute to one accounting move.

For every salary line, `_prepare_slip_lines()` searched the complete list of previously prepared move lines for both the debit and credit entries. It also created a new `line_ids + new_lines` list for every search. As the move grew, accounting validation time grew quadratically.

This commit keeps a shared index while preparing the move. It is keyed by the stable aggregation fields: line name, account, and analytic distribution.

Only lines in the matching bucket must then be checked for compatible debit or credit signs and tax tags.

Benchmark
=========

The blueprint creates 500 validated payslips and 10,000 payslip lines. All lines are accumulated into one accounting move.

On a fresh database with `hr_payroll_account` and `populate` installed, populate the data with:
```sh
    ./odoo-bin populate\
        -d <database> \
        -b hr_payroll_account.benchmark_payroll_account_move_creation \
        --seed 42
        -j 4
```

Run the benchmark with from the [gist](https://gist.github.com/pivi-odoo/3a5a21bb42f82d5ae10646d15986013b):
```sh
    ./odoo-bin shell \
        -d <database> \
        < benchmark_prepare_slip_lines.py
```
The benchmark measures `_get_account_move_vals()` with a cleared ORM cache before every sample.

| Payslips | Input lines | Move lines |  Before |  After | Speedup | 
|---------:|------------:|-----------:|--------:|-------:|--------:|
|       20 |         415 |        398 |  0.634s | 0.093s |    6.8x |
|       50 |        1004 |        986 |  3.040s | 0.178s |   17.1x |
|      100 |        1992 |       1974 | 11.865s | 0.344s |   34.5x |
|      200 |        3942 |       3884 |       - | 0.648s |       - |

Reference
=========
task-6429789

The Indian payroll module now uses clearer tooltip text for ESIC employee and employer contributions. The updated wording explicitly states the wage limits for regular employees and Persons with Disabilities, helping payroll users apply the rules with more confidence.

Clarify the ESIC employee and employer contribution tooltips by using clearer wording and explicitly mentioning the wage limits for regular employees and Persons with Disabilities (PwD).

Task-6451829

Belgian payroll reporting now excludes employees marked as not subject to withholding taxes from key fiscal reports. This helps ensure employees who are not taxed in Belgium are not incorrectly included in 281 and 274 tax reporting.

Purpose: Some employees should not have any withholding tax and some should not have any fiscal report neither as they are not taxed in belgium.

- excluded employees with `no_withholding_taxes` checked from 281 and 274 reports.

task-id: 6377289

The Time Off Gantt view popover now lets users edit leave records directly and split a leave into two parts. This makes scheduling adjustments faster and reduces the need to navigate away from the planning view.

- Make the leave record in the popover editable.
- be able to split a leave in 2

task-6345738

The Belgian payroll exemption wizard and reports now consistently show the Start-up and Micro-enterprise sections only when the company is eligible. This helps prevent employers from generating irrelevant or invalid 274.60/274.61 report sections when their SME exemption status is missing or expired.

Make the form view, PDF, and XLSX reports consistent when reporting the Start-up (274.60) and Micro-enterprise (274.61) exemptions.

Specifically:
- Hide the "Start-up/M-E" tab in the wizard form view if the company's exemption SME status setting is not configured.
- Do not generate the 274.60/61 tab/worksheet in the XLSX file if the employer is ineligible (i.e. status is empty or CBE has expired).
- Do not generate the 274.60/61 page in the PDF printout if the employer is ineligible.

task-6421989

Live chat and Discuss now have a cleaner interface with fewer distracting icons. Users can translate new messages more easily within a conversation, canned responses are ordered by recent usage, and conversations can be downloaded before a chat ends.

This commit aims to improve the UI of livechat and discuss by removing clouding icons.
It improves the UX by having the option to translate all new messages when translating one message, this is a client side option meaning it would need to be done again after refresh and is isolated to the current channel.
We also improve the sort of canned responses by using the last used canned function Odoo-wide (depends on other users as well) and being able to download conversations even when the livechat is not ended.

https://github.com/odoo/odoo/pull/270509

Task-6272656

Certificates of Completion for Sign requests now show timestamps in the sender's timezone instead of always using UTC. This makes the certificate easier to understand for signers and reduces confusion for teams working across regions.

The Certificate of Completion always displayed timestamps in UTC, which confused signers in non-UTC regions. They are now shown in the request sender's timezone.

task-6046266

Belgian payroll now warns users when company car details are updated after the DMFA declaration has been prepared. It also records the update date, helping payroll teams identify changes that may affect reporting accuracy and compliance.

Task: 6201452

Improves the Brazilian fiscal localization screens and labels so business users can configure tax and fiscal data with clearer wording and fewer duplicate options. It also improves product and contact fiscal code handling, archiving of NBS codes, and gives clearer validation messages for correction letters before they reach external tax services.

This contains a bunch of UX and data cleanups across the Brazilian fiscal localization:

- Selection labels for activity sector, tax regime and SPED type now have human-readable text instead of the raw API codes, SPED type is prefixed with its official code,
- NCM codes get a new is_service flag distinguishing goods (NCM) from services (LC116), with search filters, a "NCM / LC Codes" menu and a product code field filtered on the product type,
- NBS codes can now be archived,
- Clean up the settings: rename "Simplified Regime ICMS Rate" to "ICMS Simplified Credit Rate" with a Brazil-specific tooltip, drop the duplicate CBS/IBS Normal toggle (kept on the company contact) and align the CNAE field,
- Show the operation type Technical Name on its form,
- Reorder the contact Fiscal Information fields and rename the product "Transport Cost Type" to "Additional Cost Type",
- Open the partner form when a single contact is missing Avatax fields, and the Brazil-specific list for several,
- Validate the correction letter reason length in Odoo so a short reason no longer shows a raw XML schema error from Avalara,

task-6327269

Appointment pages now provide clearer placement information for floating content snippets. This helps ensure page elements are positioned more appropriately when editing appointment pages, improving consistency for website editors.

Community commit introduces a new plugin responsible for relocating
floating snippets.
In this commit we provide a scope that adds info of where the snippet
can be on an appointment page.

Community pr: https://github.com/odoo/odoo/pull/268301

task-6034130, task-5447310

All signers can now choose whether to add a frame when adopting their signature, not only internal Odoo users. The signing dialog controls also have clearer borders, making the public signing experience easier to use and understand.

Version: 19.0

Before this PR:
The 'Frame' checkbox in the 'Adopt Your Signature' dialog was only shown to internal Odoo users (users with the `base.group_user` group).Also, on the public signing page, the Full Name input, the Frame checkbox and the Auto/Draw/Load buttons had no visible border

After this PR:
The 'Frame' checkbox is now rendered for every signer in the 'Adopt Your Signature' dialog. The Full Name input, Frame checkbox and Auto/Draw/Load buttons now have a visible border.

Taskid-4610728

Receipt printer selection in Point of Sale IoT now matches the broader printer filtering already used for preparation printers. This helps businesses use eligible printers more consistently without being limited by an overly specific printer type setting.

In odoo/enterprise#124306, we removed the subtype
from the printer domain, but only for preparation printers.

We also update it for receipt printers.

Forward-Port-Of: odoo/enterprise#125648

Vendor bill product suggestions based on line labels now respect the setting that enables or disables this feature. This prevents unwanted suggestions for businesses that turned the option off, while keeping the default behavior for community users.

Context:
There was an enterprise field `predict_bill_product` allowing users to toggle product prediction based on line label.

Before this commit, product prediction by name was running without taking into account the value of this field, which could confuse users who had disabled the feature in settings.

This commit makes product prediction by name depend on this field.

For community users, the prediction will run by default.

no-task

---
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Before this commit, when importing and invoice/bill, we predicted the invoice line account based on previous invoices/bills. If the predicted account had default tax, it was ignored during tax matching. With this commit, first checks whether the predicted account has a default tax. If it finds one that matches the tax percentage from the imported XML, that tax is applied. Otherwise, or if the account has no default tax, the existing tax matching logic is used. task-6345661

Before this commit, when importing and invoice/bill, we predicted the invoice
line account based on previous invoices/bills. If the predicted account had
default tax, it was ignored during tax matching.

With this commit, first checks whether the predicted account has a default tax.
If it finds one that matches the tax percentage from the imported XML, that tax
is applied. Otherwise, or if the account has no default tax, the existing tax
matching logic is used.

task-6345661

Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr