Currently when a user with a product manager rights that is not admin tries to look up the product with barcode information is not auto filled.

## Steps to replicate:
- Install stock with demo data
- Barcode Database > Setup barcode lookup credentials
- Users > Marc Demo > Give Marc Demo > Master Data > Products > Create
- Login as `Marc Demo`
- Products > Barcode: `850049670180` > Click anywhere else

## Observed Behaviour:
Information on the product template is not autofilled, as it would be when using a System Admin user(Mitchell Admin).

## Root cause:
This issue occurs because barcode lookup is gated behind a check for System Admin rights. Although users in the Product Manager group have permission to create products, they do not satisfy this condition, so the barcode lookup never executes at [1].
[1]-
https://github.com/odoo/enterprise/blob/c66995fda83e19b28a38312af8efdc1601881cf0/product_barcodelookup/models/product_template.py#L17-L22 
## Why this is an issue:
The original restriction (task [2] and commit [3]) was intended to limit barcode lookup to users who can create products, preventing unnecessary API calls. This was a valid assumption in 17.3-18.0, where creating products in POS required System Admin rights but now after commit [4] this is no longer the case.

In v18, task [5] introduced the Product Manager group, making product creation independent of System Admin rights or module rights. Later, v18.3 exposed these Master Data access rights to non-debug users through commit [6].

As a result, there are users who are legitimately responsible for product creation and maintenance (regardless of POS usage) they can no longer use barcode lookup unless they are also granted full System Admin privileges, which provides broader access than required.

## Solution:
Remove the group-based permission check so that access is determined solely by product edit permissions. This ensures that only users with the ability to modify products can use the API call, preserving the original security intent.
As a result, users no longer need unnecessary administrative privileges toperform barcode lookups.

[2]:
https://www.odoo.com/odoo/project/49/tasks/3911024 
[3]:
https://github.com/odoo/enterprise/commit/444df3e48cb8d479d3b5d4a03a4bfefa48650910 
[4]:
https://github.com/odoo/odoo/commit/821bbc4504fd80a508e2412c7490ee60dd03f7b8 
[5]:
https://github.com/odoo/odoo/commit/d4886faf12ccaf63d5e899c20df2543d1ce046ab 
[6]:
https://github.com/odoo/odoo/commit/e74eaf628498155243db73ea229eaf5e74c24f2a

opw-6290999

Forward-Port-Of: odoo/enterprise#121915

When importing an EnvioDTE XML containing several DTEs (journal upload or incoming DTE mail server), one vendor bill is created per DTE, but the first bill receives the invoice lines and references of ALL the DTEs in the file, causing the total amount mismatch.

Cause: `_split_xml_into_new_attachments()` creates new attachments for the documents beyond the first one but leaves the original `file_data['xml_tree']` untouched; the decoder must scope itself to the first document (as l10n_it_edi and l10n_es_edi_facturae do), which `_l10n_cl_import_dte()` never did.

e.g. l10n_es_edi_facturae:633:

```python
# Only decode the first invoice of the Factura-e file.
tree = tree.xpath('//Invoice')[0]
```

Fix: scope the tree to the first DTE node before filling the bill. Kept behind a `len > 1` guard so files with a bare <DTE> root (matched by `xpath('//ns0:DTE')` but not by `findall('.//ns0:DTE')`) keep working.

Introduced in: https://github.com/odoo/enterprise/pull/75327.

opw-6378954

Forward-Port-Of: odoo/enterprise#124691

Problem:
When testing importing a bank statement, an error gets thrown although the import is correct.

Steps:
1. Go to Accounting
2. Go to Bank -> Import
3. Download the Import Template
4. Try importing the template
5. Select to Create New Values in case of absent values
6. Test the import
7. Notice the error "Record *** does not exist ..."

Cause:
When testing an import of bank statement, the importing of the bank statement lines is done first and then they are linked to a new bank statement, if needed.
https://github.com/odoo/enterprise/blob/831cc0201b128d82ce08a3f97b207859d8904870/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L140-L145 This gets rolled back in case of testing (dryrun)
https://github.com/odoo/enterprise/blob/831cc0201b128d82ce08a3f97b207859d8904870/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L152 However, because the importing of the bank statement lines is a full test import of its own:
https://github.com/odoo/enterprise/blob/831cc0201b128d82ce08a3f97b207859d8904870/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L140 it gets rolled back before the lines can be linked to a new bank statement, resulting in the error of missing records.

This didn't happen before because the BaseImport would not flush the cache when rolling back the changes, so the statement lines would still be in the cache and then can get linked to the statement. But after this commit: odoo/odoo@06889bd , where the savepoint in the BaseImport changed to a flushing savepoint:
https://github.com/odoo/odoo/commit/06889bd62465fa20c79084b3027e0e917a55a8c8#diff-f7ea8dfd301f732f65b95439f68b7d124dd274fb2130a2aba037c9c17ceb963fL1441-R1439 when the importing of bank statement lines gets rolled back, the lines get flushed from the cache and cannot be linked to the newly created bank statement.

Solution:
There's no need to test linking the imported lines to a newly created bank statement. We can skip creating the bank statement if it is a test import (dryrun).

opw-6404000

Problem:
Users cannot change analytic distribution set on employees. Users encounter an error when trying to change it.

Steps to reproduce:
1. Enable analytic accounting
2. Try to edit the analytic distribution field on an Employee
3. Notice the error being thrown when trying to save

Cause:
Analytic distribution field is a JSON field and JSON field and tracking is not supported on JSON fields.
https://github.com/odoo/odoo/blob/2aa35eb9c7a709126dca65e81ca6e823706fbb19/addons/mail/models/mail_tracking_value.py#L172
Tracking is supported for other fields but is not supported for JSON fields, so setting tracking=True on a JSON fields leads to an error being thrown. The error gets thrown whenever the field is edited.

Caused by 88a3e70 , as a result of this comment
https://github.com/odoo/odoo/blob/0133e46f89df7dce8c39d2bacd29579d57a83fad/addons/hr/models/hr_version.py#L443

that mentioned that whitelisted fields should have tracking set to true.
However, that's not necessary.

opw-6405122

Forward-Port-Of: odoo/enterprise#125135

### Issue before this commit:
When a company generates an EC Sales List for a foreign country (e.g., a Luxembourgish company running a Belgian report), the exported XML and PDF files incorrectly display the company's primary domestic VAT number instead of the foreign VAT number defined in the fiscal position in the tag DeclarantReference.

### Steps to reproduce the issue:
1. Download Accounting and l10n_lu
2. Switch to LU company
3. Go to Fiscal Positions in settings and create the Belgian position (insert country as Belgium and Foreign Tax ID as BE0477472701)
4. A pop up will appear saying: Click  to create the taxes for this country. so click there to create the taxes
5. Go to Invoices and create a new invoice and be sure that:
	1. be sure the customer has a VAT number in their profile
	2. in tab Other Info the Fiscal Position is set to Belgium
	3. the tax applied is 0% EU S (BE)
	4. date of invoice is in June
6. Open the tax return in 1 July
7. Open EC Sales List June 2026 (BE) and mark as reviewed all the lines
8. Click on Validate
9. Open the XML and PDF file created and see that the tag DeclarantReference is wrong because it reports the data of LU company instead of BE company

### Cause of the issue:
The `export_to_xml_sales_report` method relied on legacy code (company.partner_id.vat) to fetch the VAT number. It failed to use the centralized `get_vat_for_export(options)` method, thereby completely bypassing the foreign VAT logic correctly implemented in other tax reports.

### Reason to introduce the fix:
To ensure tax compliance by appling the correct VAT number from the foreign fiscal position.

opw-6170447

Forward-Port-Of: odoo/enterprise#125210
Forward-Port-Of: odoo/enterprise#124698