Currently, an exception is raised while loading icon content assets
such as `.woff` or `.woff2`, due to a mismatch between the requested
asset version and the latest available version.

Steps to produce:
- Install website
- Open page `/web/assets/1/6a783c3/web.odoo_ui_icons.min.woff2`

Error: `UnboundLocalError: cannot access local variable 'assets' where it is not associated with a value`

This issue occurs because the code at [1] compares `binary.extension` with
`asset_type`, causing the condition to fail because `binary.extension` contains
values such as `woff` or `woff2`, while `asset_type` is set to `'binary'`.

The root cause is that `asset_type` with value `'binary'` is being passed as
a parameter to the `bundle.get_link` method (see [2]). The `asset_type`
value comes from the `_parse_bundle_name` method (see [3]), where it is
set to `'binary'` whenever the file extension belongs to `BINARY_EXTENSIONS`,
such as `woff` or `woff2` (see [4]).

This commit fixes the inconsistency between `bundle.get_version()`
and `bundle.get_link()` when `binary` is `True`.

Currently, `bundle.get_version()` used `extension if binary else asset_type`,
while `bundle.get_link()` always received `asset_type`. This could lead to an
incorrect redirect when handling binary assets.

The fix normalizes the value by updating `asset_type` beforehand and reusing
it consistently in both `bundle.get_version()` and `bundle.get_link()`. This
also improves readability by removing the inline conditional expression.

[1]: https://github.com/odoo/odoo/blob/8a2e001cffd381a89ab192f2e391ccc0843108c4/odoo/addons/base/models/assetsbundle.py#L166
[2]: https://github.com/odoo/odoo/blob/8a2e001cffd381a89ab192f2e391ccc0843108c4/addons/web/controllers/binary.py#L146
[3]: https://github.com/odoo/odoo/blob/8a2e001cffd381a89ab192f2e391ccc0843108c4/odoo/addons/base/models/ir_asset.py#L93-L94
[4]: https://github.com/odoo/odoo/blob/8a2e001cffd381a89ab192f2e391ccc0843108c4/odoo/tools/constants.py#L6-L7

Sentry-7441025709

Forward-Port-Of: odoo/odoo#263506

Currently, an error is produced when sending invoices to MyInvois if the invoice number uses a year-range sequence.

**Steps to Reproduce:(v-19.0)**
1. Install the `accountant` and `l10n_my_edi` modules (with demo data).
2. Switch to "MY Company"(Malaysian company).
3. Enable "_Quick Encoding_" for Customer Invoices in Settings.
4. Create a customer invoice with customer "_MY Company_", set a Malaysian classification code and taxes on the invoice line, and confirm the invoice.
5. Set the invoice back to Draft and modify the invoice number with a year-range sequence (e.g., INV/2025-2026/00001), then confirm it again.
6. Open the invoice list view and click **"Send to MyInvois"**.

**Error:**
`ValueError: not enough values to unpack (expected 4, got 2)`

The `_get_sequence_date_range()` method on `myinvois.document` overrides the method from `sequence.mixin` and returns only two values from `date_utils.get_fiscal_year()`. However, it expects the method to return four values at [1].

[1] - https://github.com/odoo/odoo/blob/57b6b8d63b038ede32dfcc833c30e93d0cf4166c/addons/account/models/sequence_mixin.py#L146
Ref: https://github.com/odoo/odoo/blob/1ce06257f877711bd5de5487364909d72b476318/addons/account/models/account_move.py#L4263

sentry-7320998540

Forward-Port-Of: odoo/odoo#266221
Forward-Port-Of: odoo/odoo#253237

Currently, an error occurs when the user checks the report line errors.

**Steps to Reproduce:**

 - Install the `l10n_hk_hr_payroll_empf` module with demo data.
 - Switch to the `Hong Kong` company.
 - Go to `Payroll` > `Reporting` > `Hong Kong` > `eMPF Contributions`.
 - Create a record by setting the `Scheme` and adding a `contribution line`.
 - Ensure that the employee and payslip fields are empty in the contribution line.
 - Click on `Validate`, then click on the `error icon` on the report line.

`ValueError: Expected singleton: hr.version()`

This error occurs when the user manually adds a line and checks the errors on it.. The system 
attempts to open the employee record from the version [1], but the version is not set [2] on the 
line because there is no employee. And it raise the error [3].

This commit ensures that when checking errors, if the version is not set on the line, a UserError 
is raised, prompting the user to set the employee on the line. It also corrects a typo in the status 
message.

[1]- https://github.com/odoo/enterprise/blob/7889b2b0b3d13b32e6e36e616e20379d8c8f8812/l10n_hk_hr_payroll_empf/model/l10n_hk_empf_contribution_report_line.py#L219

[2]- https://github.com/odoo/enterprise/blob/7889b2b0b3d13b32e6e36e616e20379d8c8f8812/l10n_hk_hr_payroll_empf/model/l10n_hk_empf_contribution_report_line.py#L142-L156

[3]: https://github.com/odoo/odoo/blob/98855c6b70df24500babe6027109aa9e17431ec1/addons/hr/models/hr_version.py#L609-L611

Forward-Port-Of: odoo/enterprise#116607

The total of a sale order containing a combo product that has an extra price is not correclty converted to the sale order's pricelist currency

Steps to reproduce:
1. Install Sales
2. Go to Invoicing > Configuration > Accounting > Currencies and activate currency MXN
3. Go to Sales > Products > Pricelists and create a new pricelist for currency MXN
4. Go to Sales > Products and create a new combo product "test"
5. Create a combo choice "combo" with options "Large Cabinet" and extra price 10000$
6. Go to Sales and create a new quotation for customer Acme Corporation with product "test" (total is $10,001)
7. Change the pricelist to MXN and update prices
8. The total is ~MX$10,018 (it should be ~MX$186,682)

Issue:
The extra price of a combo product is not converted to the sale order's pricelist currency, so we end up adding the price of the product in the order's currency with the extra price not converted

Solution:
Convert the extra price of the combo product to the sale order's pricelist currency

opw-6192935

Forward-Port-Of: odoo/odoo#266172
Forward-Port-Of: odoo/odoo#265008

Before this commit, for DBs with a very large number of products it was possible for the thread to run out of memory when importing an invoice or a bill.
The reason is that the name on product.product is non stored and computed. This leads to tons of recomputes, which in turn leads to reads and stores in cache of the underlying `product.product`, which down the line uses up all of the available memory for the thread.

The proposed method uses batches instead of a `search_fetch` as the latter would not solve the recompute problem and hence the underlying memory problem.
Another alternative approach could be going straight for the `product.template.name`, but that approach might introduce a loss of precision or functionality when searching for products at invoice import.

Here is the memory graph from memray before the fix:
<img width="1106" height="450" alt="opw-6168737-memray-pre-fix" src="https://github.com/user-attachments/assets/f971dc4d-aa09-41e3-a8c5-e5ca53f9786d" />

And here is the same graph after the fix:
<img width="1106" height="450" alt="opw-6168737-memray-post-fix" src="https://github.com/user-attachments/assets/0a784cdc-9b40-498b-bbcb-89114eec1ec9" />

We can see a much lower peak memory usage after the fix. We an also observe that the memory complexity shifts from `O(n)` to `O(1)`, with `n` being the number of `product.product` records stored in the DB.

For both presented graphs, the same, unaltered database was tested. The database contains 389 467 `product.product` records.

opw-6168737

Forward-Port-Of: odoo/odoo#265639
Forward-Port-Of: odoo/odoo#262591

This commit resolves multiple issues in the Vietnamese accounting reports module:

1. Appendix 142 PDF Export Crash:
   - Extracted the PDF sectioning logic into a new `_get_pdf_sections` method.
   - Added safeguards to gracefully handle cases where the report has no lines, preventing an `IndexError` when attempting to access `lines[-1]`.
   - Added unit tests to ensure empty lines are correctly parsed without crashing.

2. XML Data and Dependency Fixes:
   - Fixed an invalid `report_id` reference in `account_return_data.xml` by correctly pointing it to `l10n_vn_reports.l10n_vn_tax_report` instead of `l10n_vn.form_01_gtgt_report`.
   - Reordered the `__manifest__.py` data loading sequence. `account_tax_report_data.xml` now loads before `account_return_data.xml` to prevent "External ID not found" errors during module installation/upgrades.

3. Naming and Sequencing Improvements:
   - Renamed "Vietnamese Tax Report" to "VAT Declaration - 01/GTGT" to reflect the actual Vietnamese tax form accurately.
   - Added explicit `sequence` fields to the tax reports (VAT Declaration: 10, Appendix 142: 20) to ensure proper UI ordering.

Task-6216318