Purpose: The Brazilian Federal Government, through the Brazilian Federal Revenue Service (Receita Federal do Brasil), is implementing the alphanumeric CNPJ to address the imminent depletion of its capacity to generate new CNPJ numbers. The current, exclusively numeric model is approaching its limit. The transition to a format that includes letters and numbers expands the number of possible combinations, ensuring the future availability of registrations for new companies. With the government expanding the CNPJ numbers, we need to implement a solution to support the alphanumeric CNPJ that will be issued starting July 2026.

Current Behavior: The method, `is_valid,` from stdnum is currently used to determine whether the CNPJ is valid or not. This is now considered an outdated method to determine the validation.

Changed Behavior: The new validation logic by stdnum, found here https://github.com/arthurdejong/python-stdnum/commit/d3ec3bd7fefe0d0a708b6594a66de28777eb9b8d, is patched into `check_vat_br.` The reasoning for patching this rather than calling stdnum is because using stdnum will cause library dependency issues for older versions of Odoo.

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

Currently, an error occurs when importing the SAF-T file into accounting.

Steps to Reproduce:

 - Install the `account_saft_import` and `accountant` modules.
 - Create a `new company` with the country set to `Denmark`, and `switch` to this company.
 - Go to `Settings` > `Accounting`, and click `Import` under Accounting Import.
 - Click `Import SAF-T`, enable Import account opening balances, and upload [this file](https://drive.google.com/file/d/177zf_w3B8m3g2VlJkbDB-Zp61TbZuV5r/view)

`AttributeError: 'NoneType' object has no attribute 'update'`

This error occurs when importing the SAF-T file in accounting. The SAF-T XML does not include any <saft:Account> entries, so map_accounts is empty [1]. As a result, based on map_accounts here [2], it got None in data['account.move'], which causes the error in [3].

[1]
https://github.com/odoo/enterprise/blob/2f59dc2443833b0308fcd774a8008b8ebdce48fd/account_saft_import/wizard/import_wizard.py#L436

[2]
https://github.com/odoo/enterprise/blob/2f59dc2443833b0308fcd774a8008b8ebdce48fd/account_saft_import/wizard/import_wizard.py#L447

[3]
https://github.com/odoo/enterprise/blob/2f59dc2443833b0308fcd774a8008b8ebdce48fd/account_saft_import/wizard/import_wizard.py#L467

This commit ensures that it uses an empty object if it gets None.

sentry-6714182871

Currently, an error occurs when the `Snailmail: process letters queue` scheduled action is triggered.

Steps to reproduce:

 - Install the `website` and `account` modules.
 - Create a `Invoice` > `Confirm` > `Send` > check the `By Post` checkbox.
 - `Reset to Draft` newly created invoice and delete it.
 - Run the `Snailmail: process letters queue` scheduled action.

`MissingError: Record does not exist or has been deleted.
(Record: account.move(27,), User: 1)`

This error occurs when the user sends the invoice by post, which creates a Snailmail letter record related to the invoice. 
If the invoice is subsequently deleted, the Snailmail: Process Letters Queue scheduled action run and attempt to fetch 
the attachment of related snailmail letter and invoice[1] but the invoice is not exists [2] and raise a MissingError.

[1] https://github.com/odoo/odoo/blob/cc368d553cd94bee8b09d4981cb8f1dbc27a34b3/addons/snailmail/models/snailmail_letter.py#L149

[2] https://github.com/odoo/odoo/blob/420765c787b33f79ee8814f799de721508858319/addons/account/models/account_move.py#L3605

This commit ensures that the system evaluates the attachment only if the invoice also exists.

sentry-6635629791

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

Steps to produce:
---
- Install `mrp`.
- Go to Manufacturing > Products > Bills of Materials.
- Click Create, select a product.
- In the Product Variant field, type any value and click "Create".

Issue:
---
Using quick create on the Product Variant field does
not create a variant of the selected product template. Instead, it
creates a completely new, unrelated `product.template`. This is because
the `create()` method on `product.product` is overridden to call super()
with context `create_product_product=False`, which suppresses direct
variant creation and forces creation through `product.template` instead,
see [1].

**Why passing `default_product_tmpl_id` does not help:**
One might expect that passing `default_product_tmpl_id` in the field
context would cause the newly quick-created `product.product` to be
linked to the already-selected `product.template`. However, because of
the `create()` override above (introduced in [commit]), the variant
creation is always redirected to `product.template`, ignoring any
`default_product_tmpl_id` passed in context. It is therefore not possible
in any case to quick-create a `product.product` that is correctly and
directly linked to the currently selected `product.template`.

Fix:
---
Disable the "Create" and "Create and Edit" options. Since there is no
way to quick-create a `product.product` that is correctly linked to the
currently selected `product.template`, the user must create the variant
directly on the product template first.

[1]https://github.com/odoo/odoo/blob/f04d79d44873d0f1c35303a1a892f3a3a394ea17/addons/product/models/product_product.py#L364-L368

[commit]: https://github.com/odoo/odoo/commit/7389345696720255a9d3c72ca1d9c2f4e4ecd7b8

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

Issue
-----
Forced full packaging reservation setting is ignored when there is a big quant in stock.

Steps to reproduce
-----
- Enable packagings
- Create a product category "Super Category"
    - Reserve Packagings: Reserve Only Full Packagings
- Create a stored product "AAA"
    - Product Category: Super Category
    - 50 units on hand
    - Packaging: 6-Pack (6 units)
- Create a delivery for 15 units of AAA

> Reservation is made for 15 units

Cause
-----
The rounding to a multiple of the packaging quantity takes the stock quant into account. For our example case, we have 8 full 6-Packs on hand, so the `available_quantity` gets set to 48 when doing

https://github.com/odoo/odoo/blob/5e458236ca2ff2ab92c4893495e7a721be902c40/addons/stock/models/stock_quant.py#L923-L925

This leads to the reservation quantity being min(15, 48) = 15

https://github.com/odoo/odoo/blob/5e458236ca2ff2ab92c4893495e7a721be902c40/addons/stock/models/stock_quant.py#L927

-----
Ticket:
opw-5974333

### Issue before this commit:
Before this commit, the General Ledger report did not correctly order journal items when a company and his branch were involved.
Even when entries had different dates, the lines were grouped and displayed primarily by company, resulting in a non-chronological view.

### Steps to reproduce the issue:
1. Download Accounting
2. Create a company branch for your actual company
3. Create 4 invoices (2 for the company with different dates and 2 for the branch with same dates as the company's invoices)
4. Open General Ledger and see that under the account's group the order is per company and not per date

### Cause of the issue:
The issue was caused by the SQL query used to retrieve account move lines in the General Ledger (PR that introduce the bug: https://github.com/odoo/enterprise/pull/107638)
Specifically, the ORDER BY clause prioritized company-related fields before the transaction date. As a result, the sorting logic first grouped entries by company and only then applied date ordering within each company group, instead of performing a global chronological sort.

### Reason to introduce the fix:
The fix ensures that journal items are primarily ordered by date across all companies, providing a correct chronological view of transactions.

### Fix details:
It's not possible to reorder the attributes in the ORDER BY clause without braking the test test_general_ledger_export_csv_multi_comp so it has been decided to create this trick to solve only the bug in the visualization of the General Ledger report leaving the bug in the export of csv.

opw-6000740