**Steps to reproduce:**
* Install the **Netherlands - SBR** (`l10n_nl_reports_sbr`) and **Netherlands - SBR OB Nummer** (`l10n_nl_reports_sbr_ob_nummer`) modules.
* Create two companies with Dutch localization.
* Go to **Accounting → Configuration → Tax Units** and create a Tax Unit with its own **Tax ID** (e.g. `NL826317558B01`), adding both companies.
* On the main company form, fill in the **Omzetbelastingnummer** field (e.g. `123456782B90`).
* Go to **Accounting → Reporting → Tax Return**, select the Tax Unit in the filter, and click **XBRL → Download XBRL File**.

**Observed behavior:**
* The `<xbrli:identifier>` in the exported XBRL file contains the company's **Omzetbelastingnummer** (`123456782B90`) instead of the Tax Unit's VAT (`826317558B01`).
* The tax authority rejects the return because the identifier does not match the fiscal unity registration.

**Cause:**
* `_get_sbr_identifier()` in `l10n_nl_reports_sbr_ob_nummer` unconditionally returns `self.env.company.l10n_nl_reports_sbr_ob_nummer` before consulting the Tax Unit.
* The `super()` call, which correctly routes to `tax_unit.vat` via `report.get_vat_for_export()`, is only reached when the company field is empty — so the Tax Unit's VAT is never used when a company OB-number is set.

**Fix:**
* When a Tax Unit is active in the report options, delegate immediately to `super()._get_sbr_identifier()`, which resolves `tax_unit.vat` through the existing `get_vat_for_export()` logic.
* The company-level `l10n_nl_reports_sbr_ob_nummer` override is preserved as a fallback for the `company_only` (no Tax Unit) case.

opw-6350840

Forward-Port-Of: odoo/enterprise#125167

Steps to reproduce:
- Install pos_loyalty and pos_online_payment.
- Configure a nominative loyalty program (trigger=auto, applies_on=both) awarding points, and an online payment method.
- In the PoS, add a first-time customer and a product, then pay the order with the online payment method.

Issue:
The customer earns no point, and no loyalty.card is even created for a first-time customer. Orders paid in cash are not affected. The loss is intermittent for customers whose card is already cached.

Cause:
Once paid, the order is rebuilt from the server data and re-selected. `pos.order._export_for_ui` has no `couponPointChanges` field, so the rebuilt order starts with an empty one. `set_order` does schedule a recompute, but it does not await it, and `_postPushOrderResolve` reads `couponPointChanges` right after, before the recompute settles, hence sending nothing to `confirm_coupon_programs`. A first-time customer additionally needs a `fetchLoyaltyCard` RPC, so the recompute can never win the race.

Fix:
Wait for the pending recompute before compiling the coupon data. `Mutex.getUnlockedDef` is used rather than awaiting a new `_updateRewards` call, so that no extra recompute is queued on an order that is already finalized and saved on the server.

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:

A user without accounting rights cannot open an invoice form when l10n_es_edi_verifactu is installed.

The module adds a VeriFactu page and three warning banners to the standard invoice form without any groups restriction, so every user able to open an invoice reads three fields (l10n_es_edi_verifactu_document_ids, l10n_es_edi_verifactu_warning, l10n_es_edi_verifactu_warning_level) pointing at l10n_es_edi_verifactu.document.

That model only grants read access to account.group_account_invoice and account.group_account_readonly.

Steps to reproduce:
- install `l10n_es_edi_verifactu`
- create a salesman user with sales rights but no accounting right (*Own Documents Only* is enough)
- create an ES company and an ES customer
- give the salesman access to the ES company
- activate Peppol in the general settings
- log in as the salesman
- create a sale order in the ES company for the ES customer
- confirm it
- click **Create Invoice**
- click **Create Draft**

Current behavior before PR:

An error access is raised:

Failed to read field account.move.l10n_es_edi_verifactu_document_ids

You are not allowed to access 'Veri*Factu Document' (l10n_es_edi_verifactu.document) records.

This operation is allowed for the following groups:
	- Invoicing/Billing
	- Technical/Show Accounting Features - Readonly

Contact your administrator to request access if necessary.


In Odoo sh (for databases 19.0), the standard test sale_management / TestSaleFlowTourPostInstall.test_basic_sale_flow_with_minimal_access_rights fails  for the same reason as soon as l10n_es_edi_verifactu is installed alongside sale_management.

Desired behavior after PR is merged:

On a database with l10n_es_edi_verifactu installed, a non-accountant user having the possibility to create invoices should not have the error message displayed.


---
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:

Portal/public users get AccessError (HTTP 403) when kit product stock
fields are read on the website shop or cart. Kits (phantom BoMs) have no
on-hand stock of their own: `qty_available` / `free_qty` are derived by
finding the BoM, exploding components, and computing how many complete
kits can be built. Shop and cart code read those fields for availability
(in stock / out of stock, prevent selling more than available, etc.).

Portal users are not meant to manage BOMs (no ACL on `mrp.bom`), and kit
components are often not website-published, so the base
`_compute_quantities_dict` path blows up on a normal shop browse.
`website_sale_mrp` already avoids this for cart checks by reading
`product.sudo().free_qty`; the product quantity compute did not.

This affects 17.0+ (verified on 17.0 and 19.0). Targeting 17.0 as the
oldest supported branch so it can be forward-ported.

CLA: covered by https://github.com/odoo/odoo/pull/275749

Current behavior before PR:

Reading kit stock fields (e.g. on the shop) as a portal/public user raises
AccessError when the BoM or unpublished components must be read.

Desired behavior after PR is merged:

For portal/public users, kit quantity computation runs under `sudo()`
(same idea as `website_sale_mrp`). BOMs stay unreadable to portal users
directly. Regression test covers portal and public access.

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

### Issue before this commit:
When generating ZUGFeRD or Factur-X electronic invoices, including an HTML hyperlink (such as an email or website) in the document layout caused the final PDF to fail PDF/A validation. Portals would reject the file with the error: "An annotation dictionary does not contain the key F".

### Steps to reproduce the issue:
1. Download Accounting and l10n_de
2. Go to Contacts > set Tax ID for company Bloem GmbH and also for DE company
3. Activate ZUGFeRD from settings
4. Go to settings and click on Configure Document Layout and insert something like <a href="mailto:info@company.de_skr03example.com"> info@company.de_skr03example.com</a> into the footer
5. Create an invoice to Bloem GmbH and send it through ZUGFeRD
6. Download PDF and upload it on https://www.portinvoice.com/
7. See error: An annotation dictionary does not contain the key F. With the exception of annotation dictionaries whose subtype value is Popup, all annotation dictionaries must contain the key F.

### Cause of the issue:
The underlying PDF generation engine creates hyperlinks as PDF annotations but omits the /F (Flags) key. During Odoo's PDF/A conversion process, these annotations were left unmodified. This violates the strict PDF/A specification, which mandates that all non-Popup annotations must explicitly define the /F key.

### Reason to introduce the fix:
This fix ensures full PDF/A compliance by iterating through all page annotations and injecting the missing /F key for any annotation that is not a Popup. This allows users to safely include clickable links in their invoice templates without breaking electronic document validation.

opw-6388212

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