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

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