**Issue**:
Making a product a kit could prevent confirming deliveries.

**Steps to reproduce**:
- Make sure the account application is installed
- Create a product P without kit
- Create a SO and confirm it
- Make the product P a kit
- Validate the delivery associated to the SO
-> A traceback occurs: the record does not exist anymore

**Cause**:
While confirming the delivery:
https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L168 It first filters which moves are out (`moves_out`). On the move associated with product P, since the kit is not exploded yet: https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L172 Then explodes the kit:
https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L174 https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mrp/models/stock_move.py#L357-L361 By doing so, the original move associated to the product P are deleted: https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mrp/models/stock_move.py#L399 Thus, `moves_out` contains moves that no longer exist, and eventually, and eventually while accessing `product_id`: https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L179 A traceback is thrown

**Aditionnal information**
Validating a delivery of a kit product whose moves were not exploded will trigger their explosion and require a second validation.
Therefore, no stock valuation errors will be created.

opw-6063602

Forward-Port-Of: odoo/odoo#260844
Forward-Port-Of: odoo/odoo#258403

Version:
----------
- saas-19.2+

Steps to reproduce:
----------------------

1. Install `stock_dropshipping` and `sale_management` modules.
2. Create a Customer (res.partner) with a proper address block.
3. Create a dropship product (route: Dropship).
4. Create a Sales Order for the created customer.
5. Add the dropship product.
6. Confirm the Sales Order to generate a Purchase Order.
7. Open the generated PO/RFQ and print the report.

Issue:
------
The shipping address is missing in the printed PO/RFQ report.

Cause:
--------

The `t-call` syntax is updated to use the new semantic, which passes
values *as attributes/parameters* on the `<t>` (with `t-call`) tag itself,
instead of relying on nested `t-set` directive.

- Old (Deprecated): Used nested `<t t-set='var_name' t-value='x'/>` tags
inside the calling element to define variables.
- New: Variables are passed as attributes directly on the element where
the `t-call` is located (e.g., `<t t-call='module.template' var_name='x'/>`).

A warning is added to alert developers when using the old deprecated
syntax.

see Reference: https://github.com/odoo/odoo/pull/197296

<details>
  <summary>Click here to see the results:</summary>

  <p><strong>Before:</strong></p>
  <div class="image-row">
    <img src="https://github.com/user-attachments/assets/c6892b30-10d6-4fb4-881c-1433d4fe07a0" />
  </div>
  <p><strong>After:</strong></p>
  <div class="image-row">
    <img src="https://github.com/user-attachments/assets/6109fcc3-5773-44a8-b07b-6566ed855d3f" />
  </div>
</details>


> NOTE: We can also move test into `purchase_stock`

----

opw-6075017

---

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

Forward-Port-Of: odoo/odoo#257522

Steps to reproduce:
---------------------------------
1. Install Calendar module with demo
2. For both Users: User > Preferences > Notifications > In Odoo
3. Log in through Admin > Calendar > New meeting
4. Set a start time in the near future
5. Add Marc Demo as an attendee
6. Under Options > Reminders, add a reminder that triggers shortly before the meeting (e.g., 15 minutes)
7. Save the meeting
8. Log in as Marc Demo in another browser window
9. Wait until the reminder time is reached

Observation:
---------------------------------
The reminder notification is displayed for Marc Demo. The Administrator (Mitchell Admin) does not receive any notification.

Issue:
---------------------------------
In `_notify_next_alarm`, the domain
`('group_ids', 'in', self.env.ref('base.group_user').ids)`
 was used to filter internal users. However, the admin user does not have
`base.group_user` directly in their `group_ids`, it is only present in `group_ids.all_implied_ids` (inherited through group hierarchy). This caused the admin user to be excluded from the user search, so no bus alarm notification was sent to them.

Solution:
---------------------------------
The `share` field on `res.users` correctly identifies internal users (`share=False`) vs portal/public users (`share=True`) by checking the full group hierarchy, including implied groups. This ensures the admin (and all internal users) receive alarm notifications while still excluding portal and public users.
https://github.com/odoo/odoo/blob/b261223c8e15c412a06a0d938d217bdf0ab9f9ff/odoo/addons/base/models/res_users.py#L459-L464

opw-6010337

Forward-Port-Of: odoo/odoo#255263

Steps to reproduce the bug:
- Create a service product "P1":
  - In the Purchase tab:
    - Vendor: Azure Interior
    - Subcontract Service: True
  - UoM: dozen
  - Purchase UoM: unit

- Create a sales order with 1 dozen of P1
  - Confirm -> a purchase order with 12 units of P1 is generated
- Confirm the purchase order
- Go back to the sales order:
  - Update the quantity from 1 to 2 dozen

Problem:
A new purchase order is generated, but with 144 units instead of 12
units. The quantity difference between the old SO quantity and the new
one is computed twice in the purchase order line UoM, in both
`_purchase_increase_ordered_qty` and `_purchase_service_prepare_line_values`:
https://github.com/odoo/odoo/blob/17.0/addons/sale_purchase/models/sale_order_line.py#L186

Solution:
The `quantity` parameter must be expressed in the SO line UoM, as
described in the documentation of the function `_purchase_service_prepare_line_values`.

https://github.com/odoo/odoo/blob/17.0/addons/sale_purchase/models/sale_order_line.py#L178

opw-6049106

Forward-Port-Of: odoo/odoo#260517
Forward-Port-Of: odoo/odoo#255478

When creating a procurement through mtso, if the product has a muti level bom with the same component at multiple levels, it will consider the available quantity multiple times.

Steps to reproduce:
-------------------
* Enable MTO and change supply method to: "Take From Stock, if unavailable, Trigger Another Rule"
* Create three products : final, semi, component
   - final: mtso, manufacture
   - semi: mtso, manufacture
   - component: mtso, buy, on hand quantity to 4
* Create a bom for final:
   - 10 components
   - 1 semi
* Create a bom for semi:
  - 10 components
* Create and confirm a MO for 1 "final"
-> Issue the purchase order is only for 12 components and not 16.

Observation:
-------------
When confirming our MO, it will create a manufacture procurement for the products.
The procurement will recursively create procurements and stock moves for each of its components.
https://github.com/odoo/odoo/blob/b0b8a102153eaa9231321524ec5140cc6d754502/addons/stock/models/stock_move.py#L1563-L1571
Since its a MTSO, it will first check the products if there is available products in stock (free_qty) and create the procurement for the missing quantity:
https://github.com/odoo/odoo/blob/b0b8a102153eaa9231321524ec5140cc6d754502/addons/stock/models/stock_move.py#L1646-L1647
https://github.com/odoo/odoo/blob/b0b8a102153eaa9231321524ec5140cc6d754502/addons/stock/models/stock_move.py#L1657-L1663
And each procurement, if it is of the manufacture type, will create corresponding procurements for their components.

Once all the procurements and stock moves have been created, the stock move will confirmed and assigned.
https://github.com/odoo/odoo/blob/942cbbbf243ff28f84fdaa40ed73b6572e0032a6/addons/stock/models/stock_move.py#L1627-L1629


-> The issue arise because the free_qty will only be updated when the stock moves are assigned which happen after all the procurement quantity are calculated for all the levels.

opw-5514788

Forward-Port-Of: odoo/odoo#253958

### Issue before this commit:
When handling many2many fields with a large number of records (e.g., 20k+), the client-side performance degraded significantly. In extreme cases, the browser became unresponsive or crashed when triggering onchange or compute logic.

### Steps to Reproduce:
Create a computed many2many field.
Add it to a form view (can be invisible).
Populate the related model with a large dataset (20k+ records). Trigger an onchange that recomputes the field.

### Cause of the Issue:
In _applyCommands (LINK case), the system checks for existing record IDs using Array.includes(), which has O(n) time complexity.
When handling thousands of records, repeated ID lookups using includes() result in O(n²) complexity.

### With This Commit:
Replaced Array.includes() with a Set (Set.has()), reducing lookup time to O(1). The set is updated incrementally as new IDs are added, improving overall complexity to O(n) and preventing UI freezes for large datasets.

opw-6122024

Forward-Port-Of: odoo/odoo#260993

# Setup
You'll need a User with :
- An active contract (for easiness of testing, a contract that started long ago with 8hrs/day)

# How to reproduce
- Create a new Time Off type with "Ignore Public Holidays" enabled
- Create a Public Holiday for Period X
- Create A Time Off request for the User for a Period Y that contains Period X
- Go to the Time Off Ledger
- Remove the Missing Hours filter and search for the dates in Period Y

Exemple of periods :
- Period X => Feb 10 2026 - Feb 10 2026
- Period Y => Feb 9 2026 - Feb 11 2026

# The problem
The "Approved Time Off" and "Difference" values are wrong.

With the given exemples, we'll see Feb 9 and Feb 11 with "Approved Time Off" values of 12hrs, which is wrong since the employee is supposed to work 8hrs a day, so he should have a time off of also 8hrs.

# Cause
The calculation for "Approved Time Off" is the following :
Divide the `number_of_hours` of a hr_leave
By the number of working days during the period of the leave

Using our exemple, we get :
`number_of_hours` = 24hrs
number of working days = 2
Approved Time Off = 24hrs / 2 => 12hrs, but we expect 8hrs

The `number_of_hours` is correct since we checked "Ignore Public Holidays" (which actually means : include the public holidays in the number of hours of a leave)

The problem is that the aggregation for the number of working days excludes automatically
public holidays, without paying attention to the value of "Ignore Public Holidays" :
https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/hr_holidays_attendance/report/hr_leave_attendance_report.py#L193-L202
Explanation for this part of the query : we only keep days where there is no record in
resource_calendar_leaves (`WHERE rcl2.id IS NULL`)  that contains that day
and that are considered public (`AND rcl2.resource_id IS NULL`)

# Proposed Solution
We add a `JOIN hr_leave_type` to be able to get the value for
`include_public_holidays_in_duration` ("Ignore Public Holidays").

Then, we make it so we exclude the Public Holidays only if that value is
false (`AND NOT lvt.include_public_holidays_in_duration`)

opw-6082422

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

Forward-Port-Of: odoo/odoo#258963

When creating a procurement through mtso, if the product has a muti level bom with the same component at multiple levels, it will consider the available quantity multiple times.

Steps to reproduce:
-------------------
* Enable MTO and change supply method to: "Take From Stock, if unavailable, Trigger Another Rule"
* Create three products : final, semi, component
   - final: mtso, manufacture
   - semi: mtso, manufacture
   - component: mtso, buy, on hand quantity to 4
* Create a bom for final:
   - 10 components
   - 1 semi
* Create a bom for semi:
  - 10 components
* Create and confirm a MO for 1 "final"
-> Issue the purchase order is only for 12 components and not 16.

Observation:
-------------
When confirming our MO, it will create a manufacture procurement for the products.
The procurement will recursively create procurements and stock moves for each of its components.
https://github.com/odoo/odoo/blob/b0b8a102153eaa9231321524ec5140cc6d754502/addons/stock/models/stock_move.py#L1563-L1571
Since its a MTSO, it will first check the products if there is available products in stock (free_qty) and create the procurement for the missing quantity:
https://github.com/odoo/odoo/blob/b0b8a102153eaa9231321524ec5140cc6d754502/addons/stock/models/stock_move.py#L1646-L1647
https://github.com/odoo/odoo/blob/b0b8a102153eaa9231321524ec5140cc6d754502/addons/stock/models/stock_move.py#L1657-L1663
And each procurement, if it is of the manufacture type, will create corresponding procurements for their components.

Once all the procurements and stock moves have been created, the stock move will confirmed and assigned.
https://github.com/odoo/odoo/blob/942cbbbf243ff28f84fdaa40ed73b6572e0032a6/addons/stock/models/stock_move.py#L1627-L1629


-> The issue arise because the free_qty will only be updated when the stock moves are assigned which happen after all the procurement quantity are calculated for all the levels.

opw-5514788

Forward-Port-Of: odoo/odoo#253958

**Problem:**
Changing the order of websites does not update which website is shown as the default when visiting from an incognito window (no domain match).

**Steps to reproduce:**
1. Create two websites with no domain set
2. Change their sequence order via the handle widget in the backend
3. Open an incognito window
4. The default website shown is still the old one

**Current behavior:**
The default website does not change after reordering.

**Expected behavior:**
The website with the lowest sequence should be served as the default.

**Cause of the issue:**
Commit d6f4af2790a0 replaced `models.Model` with `models.CachedModel` and removed the blanket `self.env.registry.clear_cache()` from the top of `write()`. CachedModel only auto-clears caches for fields listed in `_cached_data_fields`, but `sequence` is not in that list. As a result, `_get_current_website_id` (decorated with `@tools.ormcache`) keeps returning the stale cached website ID after a sequence change.

https://github.com/odoo/odoo/commit/d6f4af2790a0abacba6e616b00d999eddc30edc9#diff-5e92e473fa4d3da6db7ef727fb217dad51ef6c2383913edca73fe040a23e82c2L339-L341


**Fix:**
Restoring `clear_cache()` scoped to the existing sequence/company_id check ensures the ormcache is invalidated only when relevant fields change, rather than on every write as before.

opw-6102426

Some countries lile Estonia, Nederlands or France apply a rounding from
the tax report by adding a line to the end of the query results representing
the sum of the roundings on each line of the tax report.

When having a company with branches, the rounding is applying in each
closing move (one per company/branch) but the value is coming from the
aggregated report lines, this leads to wrong computation of the closing
entries.

Cause:

In `_generate_tax_closing_entries` we loop over each company, therefore
`_compute_tax_closing_entry` is called one time for each company, but it
uses the report options containing all companies

Fix:

Use options with only the current company in
`_compute_tax_closing_entry`

Steps:

- Install FR localisation
- Select FR company and create two branches
- Create, for last month:
  - 1 bill for parent company (100 with tax 20% G)
  - 1 invoice per branch (200 and 300 with tax 20% G)
- Create a tax return with opining date at the beginning of the current
  month
- Submit the last return and go to the created closing entries
-> See that closing entries are wrong

opw-5976359

Forward-Port-Of: odoo/enterprise#110652

project_template_id is a company dependent field. When creating a project, it is called without the proper company context set up. When confirming an SO through the portal, the order's env is setup without a company and `.with_user(SUPERUSER_ID)`, making future company_dependent variables use OdooBot's company.

Following examples earlier in the function, call `.with_company` while accessing project_template_id.

Steps to reproduce:
1. Install Sales and Project
2. Create second company
3. Create Customer with portal access, under created company
4. Create service product with different projects for each company
5. Create sales order with customer and service product, send to customer
6. Login as customer on portal, accept and sign SO a. Should stall, RPC Error in console

Ticket: opw-6082772

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

Forward-Port-Of: odoo/odoo#260387

### Steps to reproduce:
	- Install project_timesheet_forecast module
	- Configure your database to have a far timezone (Montevideo/Uruguay in my case)
	- Create a public holiday starts from 12AM to 11:59PM with a calendar
	- Create a planning slot for a resource that overlap with the public holiday
	- Check the Timesheets / Planning analysis report
	- Group by employees > day 
	**- Check the date of the public holiday and notice there are still planned hours shown**
	- Remove the calendar from the public holidays that we created previously
	- Check the report once again 
	**- Notice the day of the public holiday and the day after has no planned hours**

### Cause:
In the query we are using to exclude the leave days from the report we only exclude the ones that has calendar_id assigned, not taking into consideration that some of the public holiday are general and is not applied to just one working schedule.

Also if we have a leave starting midnight to 11:59PM since we store dates in database as UTC for timezone like Uruguay's one it will shift the end with one day which will introduce inconsistencies

### Fix:
We check if the calendar_id is null on the resource_calendar_leaves and make sure we take timezone of the resource into account when checking the dates of the leaves.

opw-5027070

Forward-Port-Of: odoo/enterprise#114757
Forward-Port-Of: odoo/enterprise#111846

**Steps to reproduce:**
- Install the `l10n_cz_reports` module and switch to a `CZ Company`
- Create an invoice for a customer with a VAT number, add a product, and 
  set the Transaction Code (enable it from the optional columns if needed).
- Navigate to Reporting > VIES Summary Report.
- Observe the value in the `VAT Number` column (includes country code).
- From the dropdown, export the report as XML.

**Observation:**
In the generated XML file, the `c_vat` field contains the VAT number 
including the country code (e.g., `CZ12345679`) instead of only the 
numeric part (`12345679`).

**Root cause:**
At [1], the VAT number is directly taken from the report lines without 
removing the country code.

**Fix:**
This commit ensures that the `c_vat` field contains only the VAT number without 
the country code, complying with the official VIES XML format requirements.

Ref: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV#:~:text=Tax%20identification%20number%20of%20the%20purchaser%20(only%20the%20numeric%20part)

[1]:
https://github.com/odoo/enterprise/blob/c4f2c3442f30f5ac972dd136a3642acc5bcc6da2/l10n_cz_reports_2025/models/l10n_cz_vies_summary_handler.py#L29-L62

opw-6093259

Forward-Port-Of: odoo/enterprise#114990
Forward-Port-Of: odoo/enterprise#113083

## Overview
Accessing the Mobile Menu (QR ordering) or Self-Ordering interface crashes after installing `pos_blackbox_be` on SaaS-19.1. The interface fails to load due to a missing field in the POS data loading flow.

## Steps to Reproduce
1. Install `pos_blackbox_be`
2. Open POS  
3. Access the Mobile Menu (QR code) or Self-Ordering page  

## Current Behavior
- A traceback is raised  
- The interface does not load  

## Root Cause
The method `_load_pos_self_data_fields` returns the field:
iface_fiscal_data_module

However, from SaaS-19.1 this field was renamed to:
iot_fdm_be_id

This mismatch causes the POS self-ordering data loading to fail.

## Fix
Updated the returned field to match the new field name.

# Before
return fields + ['iface_fiscal_data_module']

# After
return fields + ['iot_fdm_be_id']

## Impact
- Restores proper loading of Mobile Menu (QR ordering)  
- Fixes Self-Ordering interface crash

opw-6044883  

## Reproduction Video
https://drive.google.com/file/d/1R5TYVIXvtts12YLF5iB4GKZirMZePoGr/view?usp=sharing

Forward-Port-Of: odoo/enterprise#114357

Steps to reproduce
==================

- Install hr_payroll
- Use a mobile viewport
- Go to Employees
- Open a record
- Switch to the Salary Adjustments notebook tab

=> TypeError: undefined is not an object (evaluating 'props.activeActions.onDelete=this.onDelete.bind(this)'

Cause of the issue
==================

The SalaryAttachment2ManyField widget overrides the rendererProps to handle the delete action, but this isn't defined on mobile (because a kanban view is used)

See

https://github.com/odoo/odoo/blob/9f93f22ed5f6d5dbbafeb0a8c6fababdc2a65d45/addons/web/static/src/views/fields/x2many/x2many_field.js#L196-L212

Solution
========

Since there is no delete action on the kanban view, there is no need for an override.

While we are at it, there was no kanban view defined. Thus a default view was used

https://github.com/odoo/odoo/blob/138fad6d54a0b59885b1e5c712beb8f581c9555c/odoo/addons/base/models/ir_ui_view.py#L2835-L2846

It only contained the field description. Since that one is optional, records without a description were almost invisible..

Thus we also add a basic kanban view

opw-6047295

This function searches for overtimes by the date of hr.attendance.overtime.line. This is simply a date and can lead to problems if not using the UTC timezone.

Steps to reproduce:
1. Set timezone to anything ahead of UTC (Europe/Chisinau) (Not required, but helps)
2. Create a new employee
3. Set the Contract
4. Set Work Entry Source to Attendances
5. Set the timezone of Working Hours to anything ahead of UTC (Europe/Chisinau)
6. Create an attendance for the employee that causes overtime (default anything over 8 hours)
7. Two work entries will be created. One for the default time and one for the overtime.
8. Create an attendance for the next day (no need for overtime)
9. Alter the Check Out time
10. Duplicate overtime work entry created for the day prior

Example:
Searching for Overtimes on April 17th.
date_start = datetime(2026, 4, 17, 0, 0)
date_stop =  datetime(2026, 4, 17, 23, 59, 59, 999999)

Translated from Europe/Chisinau time (3 hours ahead):
date_start =  datetime(2026, 4, 16, 21, 0)
date_stop =  datetime(2026, 4, 17, 20, 59, 59, 999999)

start/stop times are cut to dates as overtime.line.date is just a Date:
start_naive.date() = date(2026, 4, 16)
end_naive.date()  = date(2026, 4, 17).

Then, given the domain:
    ('date', '<=', end_naive.date()),
    ('date', '>=', start_naive.date()),

Result: all overtimes on April 16th and 17th returned.

This commit aims to change the function to truly return overtimes between the given datetimes (start_dt, end_dt)

opw-5952995

### Steps to reproduce:

- In the settings: Enable "Storage Locations"
- Inventory > Configuration > Warehouse Management > Operation Types
- On receipts, in the Barcode App tab enable: "Force a destination on all products"
- Open the barcode app, create a new receipt
- Scan a product > Validate
#### > You are not blocked by the fact that you did not scan any destination even just to validate the default one

### Cause of the issue:

The `barcode_validation_after_dest_location` operation type setting is not used at any point in the barcode app.

### Note:

Line in the barcode app are always created a with a `location_dest_id`: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1310-L1322
In particular, even if the setting says: Force a destination on all products. It should rather be interpreted as force a destination scan before validation. Note that a destination scan will not necessarily update a single line but rather all concerned lines at once: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1558-L1576
It is therefore a valid call to check if a location dest was scanned to determine if the a destination was set on each product before validation of the picking, even if it is just to confirm the default destination.

### Note 2:

We modify the `_get_barcode_config` to only provide a `barcode_validation_after_dest_location` if locations re enabled otherwise users enabling the option without the ability to scan locations would be soft lock and unable to validate their picking. That same logic already being applied to the `restrict_scan_dest_location` config parameter:
https://github.com/odoo/enterprise/blob/6afe02e3e836df2822d7cae8aebbd5bdde6b34cc/stock_barcode/models/stock_picking_type.py#L109

opw-6110690

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