step to reproduce:
- create a invoice and confirm it
- remove due date from it and save it 
- ensure the confirmed invoice do not payment term or due date
- open aged receivable report
- open this entry 
<img width="1599" height="238" alt="image" src="https://github.com/user-attachments/assets/010f97f4-0d50-4e5a-9366-ae67d17e2bb7" />


Observation:
- on clicking the entry, when redirected to list view, there are `0` records.

Issue:
- The query which is used to display data on report uses `COALESCE(account_move_line.date_maturity, account_move_line.date)`

https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L222-L226

- while the method `_build_domain_from_period` uses only `date_maturity` in domain redirecting to list view
- This creates inconsistencies between two. 
https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L383-L394

opw-5237298

Forward-Port-Of: odoo/enterprise#99883

Currently, an error occurs when creating a time off request for an employee.

Steps to Reproduce:

 - Install the `hr_holiday` module.
 - Go to `Management > Time Off`.
 - Create a `new time off` and `remove the start date`.
 - Now `change the employee`.

`AttributeError: 'bool' object has no attribute 'date'`

This error occurs when creating a time off request for an employee. If the start date is removed and then the employee is changed, the compute method [1] runs to determine whether the time off can be approved and to update the states [2]. During this process, the system checks whether the time off date is in the past, and since the start date is missing, it results in the error [3].

This commit ensures that the system only checks whether the time off is in the past when a start date is provided.

[1]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L594-L597

[2]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L1279

[3]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L1237

No Task ID

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

Forward-Port-Of: odoo/odoo#238281

## Issue:
When a fiscal position should apply based on the address provided during Express Checkout, it was not applied automatically
The correct fiscal position only appeared after reloading the checkout page
This issue affects public users using the eCommerce with Stripe Express Checkout

## Cause:
The fiscal position was correctly determined during the `availableCarriers` computation, but it was not propagated to the payment request itself
As a result, prices and taxes were only updated after a full page reload

## Steps to reproduce:
- Configure Stripe with Express Checkout (e.g., Google Pay)
- Create a fiscal position with automatic detection (Country = US, Tax mapping: 15% → 0%)
- Create a product using the 15% tax
- Go to the website shop and add the product to the cart
- Use Express Checkout with a US address
- Observe that the fiscal position is not applied unless the page is reloaded

opw-5018238

Forward-Port-Of: odoo/odoo#238690
Forward-Port-Of: odoo/odoo#236832

Step To Reproduce:
- install Project
- login with admin and open any Project settings, say Project 1.
- create a upload document activity for 'marc demo'
- ensure marc demo has 'User' access  for project
-  login with marc demo
- open same project (kanban card -> view)
- upload a document for the created activity

Observation:
-  Traceback

```
TypeError: Cannot destructure property 'id' of '(intermediate value)' as it
is undefined at Activity.onFileUploaded
```
Cause:
- upload request to `/mail/attachment/upload` , calls `mail_attachment_upload` which then tries to access thread for 'write' mode, 'project.project ' model .
- as marc demo does not have write access to this model, no thread is returned
- so `NotFound()` is raised

https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mail/controllers/attachment.py#L48-L55

Fix:
- we check if selected user has appropriate rights or not for upload activity

opw-5160132


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

Forward-Port-Of: odoo/odoo#238360
Forward-Port-Of: odoo/odoo#234936

_
## Short functional explanation of the error
When creating a time off allocation with a time off type expressed in hours, and having start/end dates for every attendance in the corresponding calendar, an error is raised.

## Reproduction Steps
1. Go to Employees and click on the Configuration tab > Working Schedules.
2. Click on a schedule and click on the button next to Work Entry Type to show the Starting date.
3. Set a starting date for each entry.
4. Go to Time Off. Click on the Configuration tab > Time Off Types.
5. Click on a time off and next to the Take Time Off in, select Hours.
6. Click on the Management tab > Allocations. Click on New.
7. Select an employee that has the schedule you updated earlier.

## Expected behavior
The allocation is created.

## Unexpected Behavior
A traceback occurs:
``` ZeroDivisionError: float division by zero ```

## Origin of the issue
When setting a start or/and an end date to an attendance, this
attendance won't be taken into account for global attendances anymore.
This leads to an erroneous computation of hours_per_day, leading to
a few issues; one of them is related to time off allocation:
When setting a time off with a time off type expressed in hours,
if every single attendance in the calendar has a start/end date, there
will be no global attendance hours left, leading to a division by 0:
https://github.com/odoo/odoo/blob/8097b674a23858ed7692a0b30ca74419b8f890f7/addons/hr_holidays/models/hr_leave_allocation.py#L262


After discussion, we decided that this fix would only fix a symptom, and not the problem itself.
_
opw-5340056

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

Forward-Port-Of: odoo/odoo#237782

**Description**

When a company's working schedule has flexible hours enabled, the timesheet grid was incorrectly displaying random weekdays as non-working days (greyed out cells). The affected days varied by month because the unavailability calculation was time-dependent.

**Steps to reproduce**

1. Enable flexible hours on company's working schedule
2. Go to Timesheets > All timesheets
3. Switch to Grid view and filter by month
4. Observe that random weekdays (e.g., Wed/Thu or Mon/Tue) are greyed out

**Fix**

The grid_unavailability method now checks if the company calendar has flexible_hours enabled. When true, it returns an empty list of unavailable days, treating all days as potential working days.

This fix adds the flexible_hours check in two locations within the grid_unavailability method to cover all code paths:
1. get_company_unavailable_dates() helper function - prevents unnecessary calculation when called as fallback
2. company_unavailable_days assignment from calendar_work_intervals - handles the direct path when company calendar is found

This follows the same pattern as the gantt view fix #100385

opw-5215646

Forward-Port-Of: odoo/enterprise#100881

**Steps to reproduce:**
- create a product tracked by lot 
- create a lot with a quantity of 2
- create a new sale order
- add two sale order lines, both for a quantity of 1 of the product
- confirm
- open the picking in barcode
- scan the stock location
- scan the lot 
- scan the lot another time
- validate

**Current behavior:**
a backorder is created

**Expected behavior:**
No back order should be created 

**Cause of the issue:**
After scanning the lot for the first time we have the following situation: 
two lines : 
- one with a quantity of 1, qty_done of 1 and reserved_uom_qty of 1
- one with a quantity of 1, qty_done of 0 and reserved_uom_qty of 1
both lined grouped in a parent line with quantity of 1 qty_done of 1 and reserved_uom_qty of 2
All of this is correct.

when scanning the lot for the second time: 
_findLine iterates through the lines to select the right 
line to use.
 _findLine calls _lineIsNotComplete on the first line to check 
if it's complete (this first line is complete).
https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_model.js#L1684
But _lineIsNotComplete will actually do the check on the 
parent line (which is not complete), so the return value will 
be true. 
https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_picking_model.js#L1338
As a consequence, the quantity will be added in the first line and 
we will have a qty_done of 2 in the first line 
and a qty_done of 0 in the second line. 
Which will lead to the creation of a back order

opw

Forward-Port-Of: odoo/enterprise#100912
Forward-Port-Of: odoo/enterprise#99774

**Steps to reproduce:**
* Install and activate the **Uruguayan Localization** for the company.
* Create a contact located in Uruguay.
* Create an invoice for this customer and set **Document Type = 111 (e-Invoice)**.
* From the invoice's gear icon, create a **Debit Note**.

**Observed behavior:**
* The debit note is automatically assigned **Document Type 111 (e-Invoice)**, even though it should use **113 (e-Invoice Debit Note)**.
* Attempting to change the document type manually only shows 113 as an option, confirming the debit note should not have been set to 111.

**Cause:**
* `_compute_l10n_latam_document_type()` applies a rule that assigns Document Type **111** to all Uruguay electronic invoices with RUT identification.
* This logic does **not** check whether the move is a **debit note** (`m.debit_origin_id`), and therefore incorrectly overrides the expected debit note document type.
* The override prevents the correct selection (internal_type == *debit_note*) from being applied.

**Fix:**
* Add a condition in the automatic e-Invoice assignment logic.
* Debit notes now bypass the e-Invoice assignment and fall through to the parent method, which correctly assigns **Document Type 113**.

opw-5154599

Forward-Port-Of: odoo/enterprise#100938

Currently, an error occurs when trying to create a consolidated invoice for 
multiple POS orders associated with the same customer.

**Steps to reproduce:**

- Install the `l10n_sa_pos` module and switch to the `SA company`.
- Create two POS orders for the `same customer` without invoicing at checkout.
- Close the POS session and go to `Point of Sale` > `Orders`.
- Select both orders > click `Create Invoice` > `confirm` the action. (Make sure `Consolidated Billing` is enabled)

**Error:**
`ValueError: Expected singleton: pos.order(8, 7)`

**Root cause:**
At [1], the code accesses `self.date_order`, but when `consolidated billing` is 
enabled, self contains multiple POS orders, causing an `error`.

**Fix:**
This commit prevents the error by ensuring that the `current datetime` 
is assigned when creating a `consolidated invoice`, same as [2].

[1]:
https://github.com/odoo/odoo/blob/583bacdc8ad2b87b99b11d1e12dacf6e42edf22b/addons/l10n_sa_pos/models/pos_order.py#L13

[2]:
https://github.com/odoo/odoo/blob/583bacdc8ad2b87b99b11d1e12dacf6e42edf22b/addons/point_of_sale/models/pos_order.py#L828-L832

opw-5266908

Forward-Port-Of: odoo/odoo#237677

step to reproduce:
- create a invoice and confirm it
- remove due date from it and save it 
- ensure the confirmed invoice do not payment term or due date
- open aged receivable report
- open this entry 
<img width="1599" height="238" alt="image" src="https://github.com/user-attachments/assets/010f97f4-0d50-4e5a-9366-ae67d17e2bb7" />


Observation:
- on clicking the entry, when redirected to list view, there are `0` records.

Issue:
- The query which is used to display data on report uses `COALESCE(account_move_line.date_maturity, account_move_line.date)`

https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L222-L226

- while the method `_build_domain_from_period` uses only `date_maturity` in domain redirecting to list view
- This creates inconsistencies between two. 
https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L383-L394

opw-5237298

Forward-Port-Of: odoo/enterprise#99883

…n batch billed on ordered qty

**Problem:**
When the picking of a purchase order (of a product billed on ordered quantity) is split into different
moves and put in a batch, at batch validation, svls are created with the wrong values.

 **Steps to reproduce:**
    - enable "Batch, Wave & Cluster Transfers" settings
    - create a storable product with a standard price of 1
    - set the category as avco
    - in the Purchase tab select the control policy as
    "on ordered quantities"
    - create and confirm a purchase order for 50 of this product
    - on the Receipt, change the quantity to 20 and split the
    picking
    - go back the the PO and create and confirm a bill for
    the full amount
    - click on the receipt smart button
    - select the two pickings and then the 'Action' button
    - select add to batch
    - check 'new batch transfer' and confirm
    - open the batch and validate it
    - open stock valuation
    
**Current behavior:**
    the newly created svls have total values of
    50 and 50.10

**Expected behavior:**
    it should be 20 and 30
    
**Cause of the issue:**
When the batch is validated, _action_done is called 
on the two stock moves.
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/stock/models/stock_picking.py#L1258
In the stock_account override: 
- first the super method is called
As a consequence the state of the two moves becomes 'done'
and the qty_received of the linked purchase order line becomes 50.
- then product_price_update_before_done is called before creating
the svls.

Inside product_price_update_before_done we call _get_price_unit.
In the purchase_stock override of _get_price_unit : 
- because the super method of action_done was already called, 
qty_received of the purchase order line is 50, so _get_qty_received_without_self
will return 30. 
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L50
So received_qty is 30 and later remaining_qty will be 20
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L86
- but because no svl was created yet receipt_value will stay 0 and later 
remaining_value will be 50
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L55-L63
Therefore price_unit will be 2.5 (50/20) instead of 1 

**fix**
We do not take into account the move(s) of the 
same batch in the remaining value (because svls are not created yet)
so we should not  take them into account in the remaining quantity.

opw-5179581

Forward-Port-Of: odoo/odoo#238222
Forward-Port-Of: odoo/odoo#235601

## Issue:
When a fiscal position should apply based on the address provided during Express Checkout, it was not applied automatically
The correct fiscal position only appeared after reloading the checkout page
This issue affects public users using the eCommerce with Stripe Express Checkout

## Cause:
The fiscal position was correctly determined during the `availableCarriers` computation, but it was not propagated to the payment request itself
As a result, prices and taxes were only updated after a full page reload

## Steps to reproduce:
- Configure Stripe with Express Checkout (e.g., Google Pay)
- Create a fiscal position with automatic detection (Country = US, Tax mapping: 15% → 0%)
- Create a product using the 15% tax
- Go to the website shop and add the product to the cart
- Use Express Checkout with a US address
- Observe that the fiscal position is not applied unless the page is reloaded

opw-5018238

Forward-Port-Of: odoo/odoo#238690
Forward-Port-Of: odoo/odoo#236832

_
## Short functional explanation of the error
When creating a time off allocation with a time off type expressed in hours, and having start/end dates for every attendance in the corresponding calendar, an error is raised.

## Reproduction Steps
1. Go to Employees and click on the Configuration tab > Working Schedules.
2. Click on a schedule and click on the button next to Work Entry Type to show the Starting date.
3. Set a starting date for each entry.
4. Go to Time Off. Click on the Configuration tab > Time Off Types.
5. Click on a time off and next to the Take Time Off in, select Hours.
6. Click on the Management tab > Allocations. Click on New.
7. Select an employee that has the schedule you updated earlier.

## Expected behavior
The allocation is created.

## Unexpected Behavior
A traceback occurs:
``` ZeroDivisionError: float division by zero ```

## Origin of the issue
When setting a start or/and an end date to an attendance, this
attendance won't be taken into account for global attendances anymore.
This leads to an erroneous computation of hours_per_day, leading to
a few issues; one of them is related to time off allocation:
When setting a time off with a time off type expressed in hours,
if every single attendance in the calendar has a start/end date, there
will be no global attendance hours left, leading to a division by 0:
https://github.com/odoo/odoo/blob/8097b674a23858ed7692a0b30ca74419b8f890f7/addons/hr_holidays/models/hr_leave_allocation.py#L262


After discussion, we decided that this fix would only fix a symptom, and not the problem itself.
_
opw-5340056

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

Forward-Port-Of: odoo/odoo#237782

**Description**

When a company's working schedule has flexible hours enabled, the timesheet grid was incorrectly displaying random weekdays as non-working days (greyed out cells). The affected days varied by month because the unavailability calculation was time-dependent.

**Steps to reproduce**

1. Enable flexible hours on company's working schedule
2. Go to Timesheets > All timesheets
3. Switch to Grid view and filter by month
4. Observe that random weekdays (e.g., Wed/Thu or Mon/Tue) are greyed out

**Fix**

The grid_unavailability method now checks if the company calendar has flexible_hours enabled. When true, it returns an empty list of unavailable days, treating all days as potential working days.

This fix adds the flexible_hours check in two locations within the grid_unavailability method to cover all code paths:
1. get_company_unavailable_dates() helper function - prevents unnecessary calculation when called as fallback
2. company_unavailable_days assignment from calendar_work_intervals - handles the direct path when company calendar is found

This follows the same pattern as the gantt view fix #100385

opw-5215646

Forward-Port-Of: odoo/enterprise#100881

Issues:

1. Resetting options when dialog is closed without modification:
When the media dialog is closed without changing any options
and "Add" is clicked, the videoSelector component is reset, causing
previously selected parameters to be lost.

- Steps to reproduce:
    - Drop a Video snippet.
    - Double-click the snippet and toggle a few options (e.g., "Loop").
    - Save the video configuration.
    - Double-click the snippet again to open the video configurator.
    - Save without making any changes.
    - The options will be reset.

2. Embedding videos via Powerbox does not capture URL query parameters:
When embedding a video via Powerbox, option values from the URL
query parameters (like loop or autoplay) are not correctly applied.

- Steps to reproduce:
  - Add any Text snippet.
  - Paste a YouTube video URL with query parameters (e.g., ?loop=1&autoplay=1).
  - Choose to embed the YouTube video from the Powerbox popup.
  - The Video snippet is added without options enabled for the pasted URL.

3. Manual URL editing does not synchronize options:
Editing the video URL manually does not update the toggle states
of corresponding options.

- Steps to reproduce:
  - Drop a Video snippet.
  - Double-click the snippet and append query parameters to the URL.
  - The option buttons should toggle according to the parameters, but they do not.

4. Dailymotion preview fails for protocol-independent URLs:
Previewing Dailymotion videos fails for URLs like //[www.dailymotion.com/](http://www.dailymotion.com/)....

 - Fixes implemented:
    - Preserve selected options when saving the Video snippet without any changes.
    - Retrieve all query parameters from the URL and include them in the RPC request.
    - Synchronize option toggles with the URL input when the user manually edits it.
    - Fixed the Dailymotion regular expression to support protocol-independent
    URLs (e.g., //[www.dailymotion.com/](http://www.dailymotion.com/)...).

task-4529118

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

Forward-Port-Of: odoo/odoo#238441
Forward-Port-Of: odoo/odoo#210596

### [FIX] purchase_mrp, mrp: correct BoM Kit valuation with nested kits

#### Issue:
When purchasing a BoM Kit (50/50) containing others BoM Kits (50/50), cost share was applied at each level (50% instead of 25%), leading to overvaluation (e.g., 200% total instead of 100%)

#### Cause:
`cost_share` was always applied fully during BoM explosion and as a portion of the full price on `_get_unit_price()`

#### Other bug fixed:
Fix `_get_cost_share()` to correctly return 0 when BoM total cost_share already equals 100%

#### Requirement:
AVCO (Average Cost) must be enabled on all components/BoMs

#### Steps to reproduce:
1. Recreate that hierarchy with AVCO Products
- A kit "Testing Kit Complete" containing:
-- "Component01", cost share 50%
-- A kit "Testing Kit 1", cost share 50%:
--- "Component02", cost share 50%
--- "Component03", cost share 50%
2. Create and validate a Purchase Order for "Testing Kit Complete" (unit price: 1000)
3. Receive the products
4. Go in Inventory > Reporting > Valuation and search for Component
5. All 3 components are set to 500, instead of Component01: 500 / Component02: 250/ Component03: 250

opw-4806023


### [FIX] purchase_mrp: correct BoM valuation with product variants or optional lines

#### Issue:
BoM valuation ignores variant-specific lines and does not skip lines with quantity 0

#### Cause:
The code only checks that the BoM adds up to 100%
But this can cause issues with variants that do not include all products or with optional lines
As a result, the total valuation may be incorrect

#### Steps to reproduce:
1. Recreate a kit hierarchy with AVCO products:
   - Kit "Variant Kit" (Variant Color: White and Wood) containing:
     -- "Component01", cost share 0%, only for variant White
     -- "Component02", cost share 0%
2. Create and confirm a Purchase Order for "Variant Kit" (variant: Wood, unit price: 1000)
3. Receive the products
4. Go to Inventory > Reporting > Valuation and search for the components
5. Only Component02 appears with 500$, so only half of the total value is shown

opw-4806023
opw-5085457

**Steps to reproduce:**
* Install and activate the **Uruguayan Localization** for the company.
* Create a contact located in Uruguay.
* Create an invoice for this customer and set **Document Type = 111 (e-Invoice)**.
* From the invoice's gear icon, create a **Debit Note**.

**Observed behavior:**
* The debit note is automatically assigned **Document Type 111 (e-Invoice)**, even though it should use **113 (e-Invoice Debit Note)**.
* Attempting to change the document type manually only shows 113 as an option, confirming the debit note should not have been set to 111.

**Cause:**
* `_compute_l10n_latam_document_type()` applies a rule that assigns Document Type **111** to all Uruguay electronic invoices with RUT identification.
* This logic does **not** check whether the move is a **debit note** (`m.debit_origin_id`), and therefore incorrectly overrides the expected debit note document type.
* The override prevents the correct selection (internal_type == *debit_note*) from being applied.

**Fix:**
* Add a condition in the automatic e-Invoice assignment logic.
* Debit notes now bypass the e-Invoice assignment and fall through to the parent method, which correctly assigns **Document Type 113**.

opw-5154599

Forward-Port-Of: odoo/enterprise#100938

step to reproduce:
- create a invoice and confirm it
- remove due date from it and save it 
- ensure the confirmed invoice do not payment term or due date
- open aged receivable report
- open this entry 
<img width="1599" height="238" alt="image" src="https://github.com/user-attachments/assets/010f97f4-0d50-4e5a-9366-ae67d17e2bb7" />


Observation:
- on clicking the entry, when redirected to list view, there are `0` records.

Issue:
- The query which is used to display data on report uses `COALESCE(account_move_line.date_maturity, account_move_line.date)`

https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L222-L226

- while the method `_build_domain_from_period` uses only `date_maturity` in domain redirecting to list view
- This creates inconsistencies between two. 
https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L383-L394

opw-5237298

Forward-Port-Of: odoo/enterprise#99883

**Description**

When a company's working schedule has flexible hours enabled, the timesheet grid was incorrectly displaying random weekdays as non-working days (greyed out cells). The affected days varied by month because the unavailability calculation was time-dependent.

**Steps to reproduce**

1. Enable flexible hours on company's working schedule
2. Go to Timesheets > All timesheets
3. Switch to Grid view and filter by month
4. Observe that random weekdays (e.g., Wed/Thu or Mon/Tue) are greyed out

**Fix**

The grid_unavailability method now checks if the company calendar has flexible_hours enabled. When true, it returns an empty list of unavailable days, treating all days as potential working days.

This fix adds the flexible_hours check in two locations within the grid_unavailability method to cover all code paths:
1. get_company_unavailable_dates() helper function - prevents unnecessary calculation when called as fallback
2. company_unavailable_days assignment from calendar_work_intervals - handles the direct path when company calendar is found

This follows the same pattern as the gantt view fix #100385

opw-5215646

Forward-Port-Of: odoo/enterprise#100881

**Description**

When a company's working schedule has flexible hours enabled, the timesheet grid was incorrectly displaying random weekdays as non-working days (greyed out cells). The affected days varied by month because the unavailability calculation was time-dependent.

**Steps to reproduce**

1. Enable flexible hours on company's working schedule
2. Go to Timesheets > All timesheets
3. Switch to Grid view and filter by month
4. Observe that random weekdays (e.g., Wed/Thu or Mon/Tue) are greyed out

**Fix**

The grid_unavailability method now checks if the company calendar has flexible_hours enabled. When true, it returns an empty list of unavailable days, treating all days as potential working days.

This fix adds the flexible_hours check in two locations within the grid_unavailability method to cover all code paths:
1. get_company_unavailable_dates() helper function - prevents unnecessary calculation when called as fallback
2. company_unavailable_days assignment from calendar_work_intervals - handles the direct path when company calendar is found

This follows the same pattern as the gantt view fix #100385

opw-5215646

Forward-Port-Of: odoo/enterprise#100881

**Steps to reproduce:**
- Install accountant and l10n_be_reports
- Switch to a Belgian company (e.g. BE Company CoA)

- Create an Intra-Community invoice:
  * Customer: [EU customer]
  * Invoice Date: [last month]
  * Fiscal Position: [Intra-Community]
  * Invoice Lines: [a product with "0% EU M" tax]
- Confirm the invoice

- Go to "Accounting / Accounting / Closing / Tax Returns"
- Open the period containing the created invoice
- Mark all lines as "Reviewed"
- Validate the VAT Return

**Issue:**
In the generated XML, there is a line for grid number "46L", which should not appear.
Therefore, the XML is rejected by the government.
Same issue with grid number "46T".
These 2 grids are sub-section of grid number "46" and should not appear in the XML.

Cause:
Previously, they were filtered out, but since this commit https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b, the formula has changed from "46L" to "-46L" but the excluding filter has not been updated.

opw-5344566

Forward-Port-Of: odoo/enterprise#101353

When selling a bom kit that have some components that applies on specific variants only, the picking was not correctly created. It would only take one kit variant into account, even if you sold 2 kits with different variants.

Steps to reproduce:
-------------------
* Create a product P
* For product P, create an attribute with type "No variant" and values V1 and V2
* Create a BoM Kit for product P, with 3 components C1 C2 and C3
  - C2 applies only for variant V1
  - C3 applies only for variant V2
* Create a POS order with 2 lines of product P:
  - 1 with variant V1
  - 1 with variant V2
* Validate the order and check the created picking
> Observation: Only C1 and C2 are in the picking, C3 is missing

Why the fix:
------------
When creating the picking, the code was grouping the order lines by product only, and not by product variant. Therefore, the 2 lines would be grouped together, and only one of the variant-specific components would be taken into account.

opw-5051289

Forward-Port-Of: odoo/odoo#237844
Forward-Port-Of: odoo/odoo#235528

_
## Short functional explanation of the error
When creating a time off allocation with a time off type expressed in hours, and having start/end dates for every attendance in the corresponding calendar, an error is raised.

## Reproduction Steps
1. Go to Employees and click on the Configuration tab > Working Schedules.
2. Click on a schedule and click on the button next to Work Entry Type to show the Starting date.
3. Set a starting date for each entry.
4. Go to Time Off. Click on the Configuration tab > Time Off Types.
5. Click on a time off and next to the Take Time Off in, select Hours.
6. Click on the Management tab > Allocations. Click on New.
7. Select an employee that has the schedule you updated earlier.

## Expected behavior
The allocation is created.

## Unexpected Behavior
A traceback occurs:
``` ZeroDivisionError: float division by zero ```

## Origin of the issue
When setting a start or/and an end date to an attendance, this
attendance won't be taken into account for global attendances anymore.
This leads to an erroneous computation of hours_per_day, leading to
a few issues; one of them is related to time off allocation:
When setting a time off with a time off type expressed in hours,
if every single attendance in the calendar has a start/end date, there
will be no global attendance hours left, leading to a division by 0:
https://github.com/odoo/odoo/blob/8097b674a23858ed7692a0b30ca74419b8f890f7/addons/hr_holidays/models/hr_leave_allocation.py#L262


After discussion, we decided that this fix would only fix a symptom, and not the problem itself.
_
opw-5340056

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

Forward-Port-Of: odoo/odoo#237782

**Steps to reproduce:**
* Install and activate the **Uruguayan Localization** for the company.
* Create a contact located in Uruguay.
* Create an invoice for this customer and set **Document Type = 111 (e-Invoice)**.
* From the invoice's gear icon, create a **Debit Note**.

**Observed behavior:**
* The debit note is automatically assigned **Document Type 111 (e-Invoice)**, even though it should use **113 (e-Invoice Debit Note)**.
* Attempting to change the document type manually only shows 113 as an option, confirming the debit note should not have been set to 111.

**Cause:**
* `_compute_l10n_latam_document_type()` applies a rule that assigns Document Type **111** to all Uruguay electronic invoices with RUT identification.
* This logic does **not** check whether the move is a **debit note** (`m.debit_origin_id`), and therefore incorrectly overrides the expected debit note document type.
* The override prevents the correct selection (internal_type == *debit_note*) from being applied.

**Fix:**
* Add a condition in the automatic e-Invoice assignment logic.
* Debit notes now bypass the e-Invoice assignment and fall through to the parent method, which correctly assigns **Document Type 113**.

opw-5154599

Forward-Port-Of: odoo/enterprise#100938

Currently, an error occurs when creating a time off request for an employee.

Steps to Reproduce:

 - Install the `hr_holiday` module.
 - Go to `Management > Time Off`.
 - Create a `new time off` and `remove the start date`.
 - Now `change the employee`.

`AttributeError: 'bool' object has no attribute 'date'`

This error occurs when creating a time off request for an employee. If the start date is removed and then the employee is changed, the compute method [1] runs to determine whether the time off can be approved and to update the states [2]. During this process, the system checks whether the time off date is in the past, and since the start date is missing, it results in the error [3].

This commit ensures that the system only checks whether the time off is in the past when a start date is provided.

[1]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L594-L597

[2]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L1279

[3]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L1237

No Task ID

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

Forward-Port-Of: odoo/odoo#238281

Steps to reproduce:
-------------------
1. Install mrp_mps
2. Go to Inventory > Operations > Procurement > MPS
3. Click "Toggle search panel"(▼)
4. Click “Import Records”

Issue:
------
Nothing happens when clicking “Import Records”.

Cause:
------
After this 646bee6, initialization moved to `onWillStart()`, but it only runs
when the current action type is `ir.actions.act_window`. MPS triggers
the import from a [client action](https://github.com/odoo/enterprise/blob/142d86ad89435cd0751e9865ff62e8263a67e060/mrp_mps/views/mrp_mps_menu_views.xml#L4-L9), so the condition returns early and [get_import_templates](https://github.com/odoo/odoo/blob/f272eb19813be4254fd461ec21f1cc47e8834559/addons/base_import/static/src/import_model.js#L238) never loads.

Solution:
---------
Allow initialization for client actions as well, same as window actions.

Reference: MPS(Master Production Schedule)

opw-5248073



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

**Steps to reproduce:**
1. Install l10n_tw_edi_ecpay.
2. Switch to the TW company.
3. Go to Configuration → search for "ECPay".
4. Enable staging mode.
5. Enter all credentials.
6. Create a new invoice → select “Taiwan Semiconductor” as customer → set an email and leave the phone field empty.
7. Add a product → confirm → click “Send” → select only “Send to ECPay” → send.
 
> You can find ECPay testing credentials here : https://developers.ecpay.com.tw/?p=24174

**Issue:**
A traceback occurs while sending the e-invoice:
`AttributeError: 'res.partner' object has no attribute 'mobile'`
    
**Cause:**
In commit https://github.com/odoo/odoo/commit/6b820eb6fc6f782ba6a83d605d87b4a1dd2a87be the `mobile` field was removed from `res.partner`. The ECPay integration still attempted to read `partner.mobile`, which causes the traceback on versions where the field no longer exists.

Additionally, the code was still using the deprecated `self._cr` cursor reference, which was replaced by `self.env.cr` as part of the cleanup in: https://github.com/odoo/odoo/pull/193636/commits/ad7606195a4ba44bf9854506bf2e305d3dd13dbb

**Fix:**
Remove the reference to the obsolete `mobile` field and rely solely on the `phone` field, which is the only supported contact number field in 19.0. 
Also replace deprecated `self._cr` with `self.env.cr`

**opw-5357429**

**Description**

When a company's working schedule has flexible hours enabled, the timesheet grid was incorrectly displaying random weekdays as non-working days (greyed out cells). The affected days varied by month because the unavailability calculation was time-dependent.

**Steps to reproduce**

1. Enable flexible hours on company's working schedule
2. Go to Timesheets > All timesheets
3. Switch to Grid view and filter by month
4. Observe that random weekdays (e.g., Wed/Thu or Mon/Tue) are greyed out

**Fix**

The grid_unavailability method now checks if the company calendar has flexible_hours enabled. When true, it returns an empty list of unavailable days, treating all days as potential working days.

This fix adds the flexible_hours check in two locations within the grid_unavailability method to cover all code paths:
1. get_company_unavailable_dates() helper function - prevents unnecessary calculation when called as fallback
2. company_unavailable_days assignment from calendar_work_intervals - handles the direct path when company calendar is found

This follows the same pattern as the gantt view fix #100385

opw-5215646

Forward-Port-Of: odoo/enterprise#100881

The system will crash when user tries to create new bank statement line.

**Steps to produce:**
- Install `Invoicing` module without demo data.
- Go to `Configuration > Journals` and duplicate the default Bank journal to create `Bank (Copy)`.
- Dashboard and `Click on 3 dots` of Bank(Copy) and click on Transactions.
- Create a new transaction and set the Statement also(Create new and assign it).
- Go to that statements and Add a line and set the `foreign currency` as USD.

**Error:**
`ValueError: Wrong value for account.bank.statement.journal_id: account.journal(7, 6)`

**Cause:**
- When we try to create a transaction in a statement of a non-default journal, its journal is not set by default, resulting in two records being fetched. At line [1], our code attempts to read `statement_id.journal_id` , but encounters multiple records, causing the issue.

**Solution:**
- Here I added context to pass `journal_id` as default and made `payment_ref` required(because at [2], also we do the same).
- Also added hidden `journal_id` field in the list view.

[1]: https://github.com/odoo/odoo/blob/ec2d8d026d9f13c8fb869ad1f7b8026a144e85ec/addons/account/models/account_move.py#L887
[2]: https://github.com/odoo/enterprise/blob/bff451101bb23b4f9acc7982ed1138d7cefa13b9/account_accountant/views/bank_rec_widget_views.xml#L220

**sentry-6928858335**
**opw-5256565**

## Issue:
When a fiscal position should apply based on the address provided during Express Checkout, it was not applied automatically
The correct fiscal position only appeared after reloading the checkout page
This issue affects public users using the eCommerce with Stripe Express Checkout

## Cause:
The fiscal position was correctly determined during the `availableCarriers` computation, but it was not propagated to the payment request itself
As a result, prices and taxes were only updated after a full page reload

## Steps to reproduce:
- Configure Stripe with Express Checkout (e.g., Google Pay)
- Create a fiscal position with automatic detection (Country = US, Tax mapping: 15% → 0%)
- Create a product using the 15% tax
- Go to the website shop and add the product to the cart
- Use Express Checkout with a US address
- Observe that the fiscal position is not applied unless the page is reloaded

opw-5018238

Forward-Port-Of: odoo/odoo#238690
Forward-Port-Of: odoo/odoo#236832

[FIX] website, website_crm: fix crash on save if property field in form
---

__Before commit:__
1. Go to CRM app
2. Open a lead
3. Add a new property field by clicking on the cogwheel at the top left
and then *Edit Properties*
4. Open the website builder
5. Drag a new form
    - Set *Action* to *Create an Opportunity*
    - Set *Sales Team* to *Sales*
6. Add a new field and set *Type* to the newly created property field
7. Save
=> Traceback:
`ValueError: Unable to whitelist field(s) ['xxxx'] for model 'crm.lead'`

__Cause:__
We are trying to whitelist a property field which is not an actual field
to the `crm.lead` model but rather a property of one of the `crm.team`.

__Fix:__
Filter the property fields to whitelist.

---

[FIX] html_builder: make builder_list work with non-integer ids
---
__Before commit:__
1. Go to CRM app
2. Open a lead
3. Click on the cogwheel at the top left and then on *Edit Properties*
    - Set *Field Type* to *Selection*
    - Add two values
4. Open the website builder
5. Drag a new form
    - Set *Action* to *Create an Opportunity*
    - Set *Sales Team* to *Sales*
6. Add a new field and set *Type* as the newly created property field
7. Click on *Add New Radio*
=> There are still items to add although there are already all included.
8. Click on an item
=> Two tracebacks appear:
- `TypeError: Cannot use 'in' operator to search for '_id' in null`
- `TypeError: Cannot read properties of null (reading 'id')`

__Cause:__
When adding item to the selection, the id is casted to `Number` although
it can be a string if the field type is a property.

__Fix:__
When comparing two ids, cast both side of the comparison to strings to
make sure a match can always be found.

task-5248526

Forward-Port-Of: odoo/odoo#237638

**Description of the issue/feature this PR addresses:**
----------------------------------------------
Currently, when replying to a message with only attachments (no text content),
the parent message context is not displayed. This makes it unclear which message
the user is replying to when they only attach files without typing any text.

**Current behavior before PR:**
----------------------------------------------
- Reply messages with only attachments do not show the parent message context
- Users cannot see what message they are replying to when only attaching files
- The MessageInReply component is not rendered for attachment-only replies

**Desired behavior after PR is merged:**
----------------------------------------------
- Reply messages with only attachments now display the parent message context
- Users can clearly see what message they are replying to, even with only attachments
- The MessageInReply component renders consistently for all reply types
- Visual structure maintains proper Odoo message styling
- Better user experience with clear reply context

Task-5109159

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

Forward-Port-Of: odoo/odoo#238230
Forward-Port-Of: odoo/odoo#230574

step to reproduce:
- create a invoice and confirm it
- remove due date from it and save it 
- ensure the confirmed invoice do not payment term or due date
- open aged receivable report
- open this entry 
<img width="1599" height="238" alt="image" src="https://github.com/user-attachments/assets/010f97f4-0d50-4e5a-9366-ae67d17e2bb7" />


Observation:
- on clicking the entry, when redirected to list view, there are `0` records.

Issue:
- The query which is used to display data on report uses `COALESCE(account_move_line.date_maturity, account_move_line.date)`

https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L222-L226

- while the method `_build_domain_from_period` uses only `date_maturity` in domain redirecting to list view
- This creates inconsistencies between two. 
https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L383-L394

opw-5237298

Forward-Port-Of: odoo/enterprise#99883

### Issue:
In 18.0-18.2, for product with a Manufacturing BoM containing a Component, a WO and a Quality Point If a Reordering Rule is triggered, odoo try to add the newly ordered quantity to an existing MO But if the MO is "locked" because a quality check has been performed, a Error is raised:
```
Odoo Warning
You cannot update the quantity to do of an ongoing manufacturing order for which quality checks have been performed.
```

### Steps to reproduce:
- Create a product tracked by quantity
- Add a BoM (1 component tracked by Quantity, 1 Operation with 1 Quality Point)
- Create a Reordering Rule (Route: Manufacture, Trigger: Manual, Min/Max: 1)
- Click on Order
- Open the created MO and the Shop Floor (Remove the filters to see the WO)
- Complete the Quality Point
- Modify the Reordering Rule (Min/Max: 2)
- Click on Order - the error should be raised

### Cause:
The MO to update is retrieved here:
https://github.com/odoo/odoo/blob/45184da06cf7b92a48e3e4e90bf8b285bdd9ad6a/addons/mrp/models/stock_rule.py#L53-L57 Using a domain defined in this function:
https://github.com/odoo/odoo/blob/45184da06cf7b92a48e3e4e90bf8b285bdd9ad6a/addons/mrp/models/stock_rule.py#L130-L153

In 18.0-18.2, when validating a `quality check` from the Shop Floor while the WO is in `waiting` state, the MO remains in `confirmed` state This makes the domain match the current WO and MO, triggering `change_prod_qty` even though the MO is locked

In 18.3–18.4, a similar issue can occur with multiple WOs when the first blocks the second and a `quality check` is performed on the latter The `blocked` state behaves like `waiting`, but the issue is avoided when using the Shop Floor because this commit ensures that clicking a card starts the timer and changes the state to `progress`: 67c2127
However, it could still theoretically be triggered under specific conditions

In 19.0, the new stock.reference system (odoo/odoo#212679) ensures the MO is detected as different, so a new one is always created

opw-5012588
enterprise: https://github.com/odoo/enterprise/pull/101313

### Steps to reproduce:

- In the settings enable By-Products an Multi-step routes
- Put your warehouse in manufacturing in 3 steps
- Create two storable products:
    - Final Product (FP) with an empty bom
    - By Product (BP)
- Go to the barcode app > Operations > Manufacturing > New
- Scan FP > Register By-Products
- Scan BP
#### > The line is created with pre-prod as location and prod as destination

### Cause of the issue:

Since no existing line refers to the by product, a new line is created and its `location_id` and `location_dest_id` are provided by the `_getNewLineDefaultValues`:
https://github.com/odoo/enterprise/blob/17fd46b04d87585b7ed46c00d9559414daa17384/stock_barcode/static/src/models/barcode_model.js#L562-L566 However, at this point nothing had set the `params.newByProduct` in the `processBarcode`:
https://github.com/odoo/enterprise/blob/17fd46b04d87585b7ed46c00d9559414daa17384/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L375-L383 In fact, the only thing indicating that we are creating a by prodcut line at this point is the `displayByProduct`.

### Note:

The issue is no longer reproducible in 18.0+ as this change has already been applied in 2d5dbb93e6b33c2be786f9b2361c993f715d1a7f

opw-5350222

Forward-Port-Of: odoo/enterprise#101087

When doing a name_search with positive operators (=, ilike, in) the resulting query combines domains with the OR operator. This works fine when the leaves are all on the same table (product_product or product_template) as postgresql uses a Bitmap OR when everything is properly indexed.

When leaves are on multiple tables however postgresql has to plan a Seq Scan. For instance, let's take a simple domain on product.product of the form `['|', ('name', 'ilike', 'test'), ('default_code', 'ilike', 'test')]`. Because `name` is an inherited field via `product_tmpl_id`, the resulting query has the where clause `join_table.name ilike %s OR product_product.default_code ilike %s` with `join_table` the table you get after joining product_product and product_template. Since it's an `OR` condition, postgresql does not know in advance whether a given row will pass this condition. There's no way to filter the tables before the join. The condition moves therefore to a `Join Filter` node and postgresql has to scan the whole join table to fetch the correct tuples.

Same thing when there's a subquery. In case of a where clause `cond OR cond OR subquery`, postgresql does not know in advance whether or not a given row is gonna pass the subquery condition. So it has to scan the whole table.

In both cases this becomes a bottlneck when the number of products increaases. This commit introduces the use of `UNION ALL` instead of `OR`. There's one SubPlan for each individual table in the domain. The results are then appended to get the final products matching the conditions. Thanks to each table having its own SubPlan postgresql can now properly hit indexes for each table, greatly improving the performances.

#### speedup

In a database with 2.5M product_product, the name_search on product with a partner_id in the context and the ilike operator goes from 8s -> 5ms.

In another database with 500k product_template, the name_search on template with a partner_id in the context and the ilike operator goes from 1.8s -> 5ms.

opw-4921944
opw-5103287
opw-5049054
opw-5256691
opw-5221753

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

When posting an invoice, the system creates:
- Journal Entry: Dr 131 (Receivable) / Cr 511

Then the system creates a deferral entry:
- Deferral entry: Dr 511 / Cr 3387 (Payable)

Falsifying the Balance sheet report, in the accounts receivable and accounts payable indicators

The issue was that account 3387 was configured as `Payable`, which caused the system to generate both Receivable (131) and Payable (3387) for the same partner. This is incorrect because account 3387 represents "Unearned Revenue", which is a  current liability, not a payable account.

By changing the account type from `Payable` to `Current Liabilities`,
the deferral entry now correctly reflects that 3387 is a current liability account, preventing the incorrect reconciliation behavior where both receivable and payable entries were created for the same partner.

After this fix:
- Entry: Dr 131 (Receivable) / Cr 511
- Deferral: Dr 511 / Cr 3387 (Current Liabilities)

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

#### [FIX] snailmail: extract report PDF generation function
We extract a function `_generate_report_pdf` from `_fetch_attachment`
to create the report PDF (and its filename).
The resulting PDF's margins are fixed and a cover page is added to it
after the function is called in `_fetch_attachment`.

The new function is extended in the related enterprise commit to generate the
followup report inside `_fetch_attachment` (when sent via snailmail).
This way it will respect the cover page option and page layout / size requirements.
(See the related enterprise PR for more details.)

#### [FIX] snailmail: extract letter resending function

We extract a function `_resend_letters` from the `update_resend_action`.
It handles the regeneration of letters after the cover option has been updated.
This way the resending logic can easily extended to adjust the logic depending
on attributes of the letter.

The new function is extended in the related enterprise commit to disable
the resending for followup report letters.
This is necessary because the followup report requires special options
to be generated that are not available at the point of the regeneration.

#### references

opw-5160121
opw-5209504
opw-5226366

#### [FIX] snailmail_account_followup: fix address, cover page and layout

Currently there is the following potential problem when sending
the followup report via snailmail.
1. The address generation is not adjusted for snailmail. That can
   lead to problems with the service we use to send the actual letter.
   They validate the address rather strictly.
2. The cover page option does not work; it does not add a cover page.
   So we can not work around problems with the address generation
   by adding a cover page.
3. The layout / dimensions / margins of the generated document / PDF may not work
   with our current snailmail provider (Pingen). But there is no error
   message about it. (Although we do have something in the usual
   snailmail flow)
4. In case the address is invalid we do not try to "print" / send the letter,
   so the user does not receive any feedback.
   This could be an issue in case multiple follow-up reports are sent
   at the same time.

This commit fixes these issues. (See below for details.)

(1)
The logic for this already exists but it is only activated when
a context key is set. This is not the case currently.
After this commit we do set the key.

(2) & (3)
The issue is that we generate the PDF attachment before creating the
'snailmail.letter' record.
In the usual snailmail flow the PDF attachment generation is handled during the sending and
printing (in function `_fetch_attachment` on model 'snailmail.letter').
There is some special logic to
- add a cover page to the report PDF (if the option is selected)
- make sure the page dimensions of the PDF are okay
- overwrite the margins of the PDF with white to make sure the PDF is
  not rejected by Pingen because of this

But all this only happens if we do not have an attachment already.
(So it does not happen currently with the followup report)
For this a function called `_generate_report_pdf` was extracted from `_fetch_attachment`
in the related community commit to generate the report PDF (and its
filename). The function is extended here to be able to generate the
followup report.

(4)
We try to print / send the letter even if the address is invalid

Reproduce (i.e. for the cover page issue; but it explains how to get
the PDF that will be sent in general)

1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Set the "Add a Cover Page" option
   (Settings -> Accounting -> section "Customer Invoices")
   - enabled to test for the cover page
   - disabled to test that the address generation is adjusted
4. Send a follow-up report:
   - On 17.0: Accounting -> menu: "Customers" /  "Follow-up Reports"
     -> click on a line / partner -> button "Follow up"
   - On 18.0+: partner form view -> tab "Accounting"
     -> section "invoice follow-ups" -> button "Send"
5. Go to the snailmail letter:
   In debug mode: Settings -> menu: "Technical" -> section: "Email" -> "Snailmail Letters"
   (or just search for "snailmail" in the main screen)
   And select the letter
6. Download the PDF document

#### [FIX] snailmail_account_followup: forbid regenerating failed letters

The wizard to resend failed letters which allows to change the
cover page option is broken: The follow-up report can not be regenerated
correctly because it requires special follow-up specific `options` that are
lost after the initial pdf generation for the letter.

Currently it can happen that the follow-up PDF is regenerated but
without (actual) content (table listing the overdue amounts).

After this commit we cancel the snailmail letters and show an
error notification indicating that the followup needs to be done again to
create a new letter.

Reproduce
(needs credit on IAP or locally edit this function https://github.com/odoo/odoo/blob/3ffd51f1cb18e3f4fb0367c4a498d7438e0c0357/addons/snailmail/static/src/core_ui/message_patch.js#L11
to open the resend wizard `this.openFormatLetterAction()` for `sn_credit` error or always)

1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Ensure the address of the partner causes issues with Pingen
4. Ensure the cover page option is disabled:
   Settings -> Accounting -> section "Customer Invoices"
5. Send a follow-up report:
   - On 17.0: Accounting -> menu: "Customers" /  "Follow-up Reports"
     -> click on a line / partner -> button "Follow up"
   - On 18.0+: partner form view -> tab "Accounting"
     -> section "invoice follow-ups" -> button "Send"
6. Make some modifications like editing the follow-up message or a custom attachment
7. Download the snailmail letter PDF (see previous commit for details)
8. In the chatter go to the message saying "Letter sent by post with Snailmai"
9. Click on the red symbol (paper plane) next to the name
10. A "Format Error" wizard should show up
11. Select "Add a Cover Page"
12. Click the button "Update Config and Re-Send"
13. Download the snailmail letter PDF (see previous commit for details)
14. Compare PDFs from 7 and 13; they are different (not just the cover page)

#### references

opw-5160121
opw-5209504
opw-5226366

Steps to reproduce
-----
- Enable batch pickings
- Create a product
- Create 2 receptions for the product (qty > 1)
- Create a batch with the 2 transfers
- Open the batch in barcode
- Scan part of both pickings
- Go back to the barcode main screen
- Open the batch again

> Both pickings have their demand = partially delivered quantity

Cause
-----
When leaving the page, we trigger

https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L65-L68

in which we end up merging the moves together

https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L51

This has been added by 9753c24 (ade0bef in 17.0)

The problem is that `_merge_moves` merges all of the moves into the first of `merge_into`

https://github.com/odoo/odoo/blob/26761e04bb648b46cd35697c6cbc8ed1e27fef90/addons/stock/models/stock_move.py#L1086-L1088

This, however, doesn't make much sense for batches because the moves can be from different pickings.

-----
Ticket:
opw-5163740