When printing an invoice, a traceback will occur if the company's partner has an invalid CUIT.

Steps to reproduce the error:
- Install ``l10n_ar_edi`` module with demo data
- Switch to ``(AR) Exento`` Company
- Go to Invoicing > Configuration > Journals > Open ``Ventas Preimpreso`` journal >
  ARCA POS System: ``Electronic Invoice - Web Service`` > Save
- Create a new invoice with ``ADHOC SA`` partner > Confirm the invoice
- Open the ``(AR) Exento`` partner and set the VAT to ``BE0477472701``
- Open the Invoice > print

Traceback:
```py
ValueError: invalid literal for int() with base 10: 'BE0477472701'
```

After this [commit], companies outside the EU can use European VAT numbers.
Consequently, an Argentine partner can have a CUIT number such as ``BE0477472701``,
which is valid as a Belgian VAT number but not as a CUIT.
When printing the invoice, the ``l10n_ar_vat`` field is computed
from the partner's VAT and its value is passed to ``int()``,
causing a traceback at the following line:
https://github.com/odoo/enterprise/blob/d55486866d09f8aa87c2003dab722cfa323068b4/l10n_ar_edi/models/account_move.py#L138

[commit]: https://github.com/odoo/odoo/commit/a2afe3292e1cd0a4f339dc47707e469653d13ea0

Enterprise PR: https://github.com/odoo/enterprise/pull/127820

sentry-7666042143

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

## **Steps to reproduce:**
1. Install the Inventory and Purchase module and enable Multi-Step Routes.
2. Open the Buy route and set Company A as its company.
3. Create a user who has access only to Company B.
4. Log in as this user and navigate to Products.
5. Click New to create a product.
6. An AccessError is raised because the Buy route belongs to Company A, which is not accessible to the user.

## **Issue:**

The buy route returned by `env.ref` is not necessarily applicable to the current company. Returning `buy_route.ids` directly can therefore cause issues when creating a product in a multi-company environment.

When the user has access to multiple companies, the buy route belonging to another company can be selected during product creation. When the user does not have access to the company of the buy route, this can instead result in an AccessError.

The previous implementation performed an ORM search on `stock.route`, which implicitly filtered the route according to the current environment. However, that query was removed as part of this pr https://github.com/odoo/odoo/pull/276554.

## **Solution:**

Filter the route returned by env.ref against the companies available in the current environment before returning its ID.

Use sudo() while filtering so that the route's company_id can be read even when the route belongs to a company inaccessible to the current user. The route is still explicitly checked against env.companies, so sudo() does not allow an inaccessible company's route to be returned.

opw-6448497

Runbot Video : [Video](https://drive.google.com/file/d/1qQyJrPNwXuHtu6GXyC_78dtd_A24khFR/view?usp=sharing)

Forward-Port-Of: odoo/odoo#284179
Forward-Port-Of: odoo/odoo#283199

When printing an invoice, a traceback will occur if the company's partner has an invalid CUIT.

Steps to reproduce the error:
- Install ``l10n_ar_edi`` module with demo data
- Switch to ``(AR) Exento`` Company
- Go to Invoicing > Configuration > Journals > Open ``Ventas Preimpreso`` journal >
  ARCA POS System: ``Electronic Invoice - Web Service`` > Save
- Create a new invoice with ``ADHOC SA`` partner > Confirm the invoice
- Open the ``(AR) Exento`` partner and set the VAT to ``BE0477472701``
- Open the Invoice > print

Traceback:
```py
ValueError: invalid literal for int() with base 10: 'BE0477472701'
```

The issue occurs because when the partner's identification type is CUIT,
At [1] ``_run_check_identification()`` method does not include partners whose identification type has ``is_vat=True``.
As a result, CUIT is not validated by ``_run_check_identification()`` method in ``l10n_ar`` module at [2].
So, partner's ``l10n_ar_vat`` field can be computed as ``BE0477472701``.
Passing this value to ``int()`` raises the traceback during invoice printing at below line.
https://github.com/odoo/enterprise/blob/d55486866d09f8aa87c2003dab722cfa323068b4/l10n_ar_edi/models/account_move.py#L138

[1]:https://github.com/odoo/odoo/blob/c2a39085ba0fbcf8a0e6a55228191e764499caea/addons/l10n_latam_base/models/res_partner.py#L24-L30

[2]:https://github.com/odoo/odoo/blob/c2a39085ba0fbcf8a0e6a55228191e764499caea/addons/l10n_ar/models/res_partner.py#L55-L65

Community PR: https://github.com/odoo/odoo/pull/282454

sentry-7666042143

**Steps to reproduce:**
- Install Accounting and l10n_se
- Switch to a Swedish company (e.g. SE Company)

- In Accounting settings, set "Identification" with anything
- In Bank journal:
  * Set an account number
  * Make sure "Swedish ISO20022" is available in "Outgoing Payments"
  * Set "pain.001.001.09" as "XML Format" in "Outgoing Payments"
- Create a vendor payment:
  * Vendor: [a vendor with a trusted bank account]
  * Payment Method: Swedish ISO20022
  * Amount: [any]
- Confirm the payment
- From the payments list, select the payment and create a batch
- Validate the batch payment

**Issue:**
When the batch is validated, a `pain.001.001.09` file should be generated. However, its content is that of a `pain.001.001.03` file, even if the version reported in the file is `pain.001.001.09`.

For example, `<ReqdExctnDt>` should contains a subnode `<Dt>` in `001.001.09`, which is not the case.

It leads to the file being rejected as non-compliant to `pain.001.001.09`.

opw-6472050

Forward-Port-Of: odoo/enterprise#128598

### Issue before this commit:
Before this commit, users were completely blocked from creating an invoice for a foreign partner (e.g., "Cliente del Exterior") if all exportation journals were archived or unavailable, as the system would immediately trigger a RedirectWarning error.

### Steps to reproduce the issue:
1. Download Accounting and l10n_ar
2. Go to contacts and create a new one with:
	1. Country as United States
	2. VAT number ex. 55000002126
	3. AFIP Responsibility Type as Cliente del Exterior
3. Go to Journals, filter for sales journals and archive:
	1. Electronic Exportation Invoice (FEX)
	2. Expo Sales Journal
4. Go to invoices and create a new one for the client you just created
5. As soon as you insert the client you will receive the error: You are trying to create an invoice for foreign partner but you don't have an exportation journal

### Cause of the issue:
https://github.com/odoo/odoo/blob/014d58e3204d17db6dcba3c8ab7d8ad35003300e/addons/l10n_ar/models/account_move.py#L186-L189 The _onchange_partner_journal method rigidly enforced the use of an exportation journal for foreign AFIP responsibility types (codes 8, 9, and 10). If the query failed to find an active export journal, the code intentionally threw a hard error instead of providing a fallback mechanism.

### Reason to introduce the fix:
This fix is introduced to prevent unnecessary workflow blocks. By catching the missing journal and defaulting the document type to "Invoice B" (code 6), the user can now successfully generate the invoice using a standard domestic sales journal without being forced to configure an exportation journal.

opw-6442501


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

Forward-Port-Of: odoo/odoo#282971

When having multiple companies selected at the same time, _get_conversion_rate returns:

File "/data/build/odoo/odoo/orm/fields_misc.py", line 114, in get
raise ValueError("Expected singleton: %s" % record)

1 - Create a new company with currency EUR.
2 - Create a branch company underneath the main company.
3 - In Accounting, install fiscal localization, e.g. Belgian Companies on the company configuration settings.
4 - Select an account like 600000 Raw Materials, and enable Allow Reconciliation on this account. The exact account isn't important, only that we can make credits / debits to it to be reconciled.
5 - With only the top level company selected, make a debit of 100 USD, e.g. Vendor Bill, set in currency USD to the account 600000.
6 - Now with only the branch level company selected, make a credit of 100EUR, e.g. Customers Invoices, set in currency EUR to the same account with an amount equal to the credit in step 5. (if 1USD == 1EUR, 1-1), so that there is no residual amount, i.e. credit == debit.
7 - Now select both the top level company and the sub branch company in the company context.
8 - In Journal Items, reconcile the unreconciled journal items for the Account 600000.

With this commit we select the first company of the aml instead of every companies on the amls.

opw-6290703

Forward-Port-Of: odoo/enterprise#123774

When a helpdesk team has its website form enabled, a dedicated qweb view is generated from the `ticket_submit_form` template. The arch was read in the language of the user creating or editing the team, so a team set up by an English user language produced an English form even when the website served another language.

Steps to reproduce
==================
1. Set a language other than English as the website default language.
2. While your user language is English, create a helpdesk team with the website form enabled.
3. Open the team form on the website.

=> The form is rendered in English instead of the website language.

Root cause
==========
`_ensure_submit_form_view` read the template arch without forcing a language, so it used the current user's language and stored only that value on the generated per-team view.

Fix
===
Read the template arch in the default language of the team's website, so the generated form matches the website language regardless of the user's own language.

opw-6303903

Forward-Port-Of: odoo/enterprise#121164

When unreconciling a payment from an invoice with a cash basis tax,
the tax cash basis (CABA) entry is reversed. The reversal is supposed to
land in the same period as the origin entry so the tax report nets to
zero for that period.

Steps to reproduce:

- Enable cash basis and create a cash basis tax (exigibility on payment)
- Post an invoice dated in the past with that tax
- Reconcile a bank statement line to the invoice
- Resequence the cash basis entry so the month is dropped from the
  name (CABA/08/2026/0001 -> CABA/2026/0001)
- Unreconcile the statement line

Issue:

The reversal CABA entry created on the last unreconcile is dated today
instead of the origin entry's month. In the tax report the original tax
amount stays in the statement's month while the reversal amount appears
in the current month, so the two no longer cancel out.

Analysis:

While under a monthly journal sequence a past date returns
the last day of that month, under a yearly sequence a past date within
the current year returns the latter between the move date and today,
moving the reversal out of the origin period.

opw-6301553

Forward-Port-Of: odoo/odoo#281250

Problem:
When using horizontal groups in Aged Receivables / Aged Payables reports, the amounts shown in the Older periods are incorrect.

Steps to reproduce:
1. Activate debug mode
2. Go to Accounting > Configuration > Horizontal Groups
3. Add a new horizontal group that results in at least 2 groups
4. Go to Accounting > Reporting > Aged Receivables / Aged Payables
5. Apply the horizontal group created
6. Notice how the amount in the Older period is incorrect, different from before applying the horizontal group. (It may be coincidentally correct, you can check by applying different aging intervals until you find one that shows the issue)

Cause:
The periods were not correctly calculated. The number of periods was calculated based on the number of period columns, without taking into account the number of column groups. When using horizontal groups, period columns are duplicated for each group that exists after applying the horziontal group. This is not considered when calculating the number of periods, which results in calculating too many periods and therefore having incorrect durations for each period.

opw-6374639

Forward-Port-Of: odoo/enterprise#127570

Deleting a project also sends the folders of every archived project to the trash.

### Steps to reproduce

- Install `documents_project`, where each project has its own Documents folder linked through `project.project.documents_folder_id`.
- Create `Project 1`, `Project 2`, and `Project 3`, then archive the first two.
- Delete `Project 3`.
- The folders of `Project 1` and `Project 2` are moved to the trash with their contents, although both projects still exist and still reference them.

### Cause

`_archive_folder_on_projects_unlinked` only archives folders that are no longer used by any project. This was checked through a `documents.document` domain on `project_ids`.

The domain mixed two conditions on the same relation:

- `('project_ids', '!=', False)` checks that a folder has users,
- `('project_ids', 'not any', [('id', 'not in', self.ids)])` checks that it has no users outside the projects being deleted.

Those conditions are not evaluated the same way by the ORM. The first one keeps archived projects visible by disabling `active_test` internally, while the second one searches `project.project` normally and hides archived projects.

An archived project can therefore be counted as a folder user by one condition and ignored by the other, causing its folder to be archived.

### Fix

Check remaining users directly on `project.project` with `active_test=False`, so archived projects are included. Since only folders of deleted projects can become unused, the search starts from those folders instead of scanning all Documents.

opw-6442976