**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

BUG 1:
---------
**steps to reproduce**:
1. Install documents
2. Open any document
3. Go to Action > Rename
4. Rename the document
5. Preview it and read the name showed there

**issue**:
When previewing the document, it still shows the old attachment name.

**observation**:
When renaming a document, only the document name was updated. The attachment name remained unchanged, which caused inconsistencies:

1. In the All Records section, the document name is displayed correctly. https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/views/documents_document_views.xml#L130

2. But in the Preview, the old attachment name was still shown, as it is taken from the attachment:
https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/static/src/views/hooks.js#L373-L383

**solution**:
Use the document name when previewing it

BUG 2:
---------
**steps to reproduce**:
1. Install Documents.
2. Open any document.
3. Rename it via the chatter.
4. Try renaming it again via the details panel.

**issue**:
After renaming a document twice through the details panel, the preview still displayed the old document name.

**cause**:
On the first rename, the [insert](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/core/document_service.js#L96-L129)) method creates a new [store.Document](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/views/hooks.js#L367-L393) record with the updated attachment name. However, The write method (used by chatter) skips reloading the record and linked attachment data on the second rename.

Unlike the Rename button, which uses web_save (and triggers a record reload via web_read), the chatter directly calls write without refreshing the attachment.

**Solution**:
Ensure the preview uses the document name from the document record, keeping it consistent after multiple renames via the details panel.


**Example:** Try to rename a "Invoice.pdf" document to "Invoice_rename.pdf"
<details>
    <summary>Click here to see the results:</summary>
    Before:
    <img src="https://github.com/user-attachments/assets/563b7fb9-709c-4651-8492-032a7f353730"/>
    After:
   <img src="https://github.com/user-attachments/assets/6fc6bdfe-dd1e-4f3c-aaf7-821c44fd135d"/>

</details>

opw-5065433

Forward-Port-Of: odoo/enterprise#100539
Forward-Port-Of: odoo/enterprise#95111

_
## 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

Currently, an error is produced when configuring the **Accounting Period** on the "**Tax Returns**" journal.

Steps to Reproduce:
1. Install `accountant` module without demo data using `-i` command.
2. Accounting > Dashboard > "**Tax Returns**" Journal, click on “Tax Returns” button.
3. Set an _Opening Date_ in the wizard and try to apply the **Accounting Periods**.

**Error:**
`ValueError - Expected singleton: onboarding.progress()`

**Cause:**
**Until saas-18.2,** 
The onboarding record’s `current_progress_id` was created by method `_search_or_create_progress()` - ([1]) during module initialization. This method was triggered through `_initiate_account_onboardings()`, which was called in the `_accounting_post_init()` hook for all companies - ([2]).

**From saas-18.3,** 
`_accounting_post_init()` was modified to call `_initiate_account_onboardings()` only for companies having a `chart_template` - ([3]).

As a result, companies without a chart template never receive a default progress record, leaving `current_progress_id` unset. When rendering onboarding values, this leads to a singleton error.

**Fix:**
This commit ensures that a progress record exists by creating it when missing before rendering onboarding values.

[1]:  https://github.com/odoo/odoo/blob/b2558e92e627a0efd975a402b77a6b53810c4c41/addons/onboarding/models/onboarding_onboarding.py#L107-L111
[2]: https://github.com/odoo/enterprise/blob/2f2b53f1c6f31ae22351d22cf4bf59ef01a63691/accountant/__init__.py#L22-L25
[3]: https://github.com/odoo/enterprise/blob/37dd63580967c1186618d7340a21539a6c98dbba/accountant/__init__.py#L22-L24

sentry-7064593163

When creating a new connection to the Peppol network, we add multiple services by default. This commit remove from the default (they can still be manually enabled):
- the ANZ BIS3 Invoice & CreditNote that is deprecated in favor of the PINT version,
- the SG BIS3 Invoice & CreditNote that will also be deprecated soon by its PINT version.

Note that anyway for the moment we don't allow to register user from AU/NZ/SG on Peppol, so we were in any case registering those services for all participants, and none of them were relevant for those two local formats ...

In the future we would like to handle the received services(formats) on IAP directly to handle change better.

https://github.com/odoo/odoo/blob/0af9d32e305c1f1afb51e126c1e6747879e78225/addons/account/models/company.py#L35-L50

I checked on our AP, and only 8-10 invoices were sent with these formats, between Belgians... so it is most likely errors. Let's reduce the confusion.

<img width="1283" height="65" alt="image" src="https://github.com/user-attachments/assets/208bbd7e-f836-4bc9-a594-795313b06be9" />

Source: https://docs.peppol.eu/edelivery/codelists/v9.4/Peppol%20Code%20Lists%20-%20Document%20types%20v9.4.json

Forward-Port-Of: odoo/odoo#238674

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

*=website

Steps to Reproduce :
 1. Go to `edit` mode.
 2. Drop at least four block snippets.
 3. Drop a badge in the header next to the _Contact Us_ button.
 4. Undo twice → the _Badge_ reappears.
 5. Undo twice more → the _Badge_ reappears again.
 6. Redo three times → the _Contact Us_ button is duplicated.

Issue:
The `Contact Us` button in the header was duplicated after multiple undo/redo actions. Moreover, the `Badge` snippet did not behave as expected during undo/redo.

Reason:
When the uncommitted draft was cleared before undo/redo, the `OdooEditor` observer triggered the `OdooField` observer to roll back and flush mutations. However, this rollback was considered a new mutation by the `OdooEditor` observer. On the next undo, the `OdooField` observer tried to sync with these artificial mutations, causing duplication of buttons and badges.

Fix:
Deactivate the `OdooEditor` observer during undo/redo operations to prevent recording unnecessary mutations. After discarding the draft, reactivate the `OdooEditor` observer. This avoids redundant syncs and resolves the duplication issue.

task-4558376

Forward-Port-Of: odoo/odoo#233002
Forward-Port-Of: odoo/odoo#223579

**Steps to reproduce:**
- Install `Data Cleaning` app
- Activate notification in Odoo in the admin user profile
- Create a few duplicate contacts
- Go the the "Data Merge: Find Duplicate Records" scheduled action
- Run the action manually
- You should see new notifications telling you that they found potential duplicates
- In the top right MessaginMenu click on the notification, it opens a chatter
- Try to send a message in the chat window
- Traceback : `AttributeError: 'data_merge.model' object has no attribute '_get_thread_with_access'`

**Issue:**
The model doesn't inherit `mail.thread` so it uses `self.env['mail.thread']` directly to send notification:
```
self.env['mail.thread'].sudo().message_notify(
    ...
    model=self._name,
    notify_author=True,
    partner_ids=partner_ids,
    res_id=self.id,
)
```
But when sending the information with the `model` and `res_id` parameters the newly created `Store` uses `self.add("mail.thread", {"id": data.id, "model": data._name, **values})` and the message is assigned to a non-existing thread in the frontend.

**Fix:**
Explicitly check if the message is a `user_notification` and redirect the user to the discuss inbox if it's the case by reapplyng part of https://github.com/odoo/odoo/commit/b3be992c57dc5e412a127d05fc50b059814523aa

opw-5101510

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

Forward-Port-Of: odoo/odoo#238563
Forward-Port-Of: odoo/odoo#234737

Problem:
When the user selects a link to color and the selection falls on a `feff` character, a traceback occurs.

Cause:
After commit 927f4b973932d14961c148e13473017651a60dc0, we preserve the selection at:
https://github.com/odoo/odoo/blob/bee7fc1f955c52a88b527ad9a2ddf0021529bbc7/addons/html_editor/static/src/main/font/color_plugin.js#L247-L247
and then call `getFonts()`, which internally uses
`this.dependencies.split.splitAroundUntil()`.

If the selection is on a `feff` node, `splitAroundUntil()` can clear those nodes because `splitElement()` inside it dispatches to `clean_handlers` with the selected element containing the `feff`. Since the preserved cursor offset refers to the node before the `feff` was removed, restoring it throws:
`The offset x is larger than the node's length (y).`

Solution:
After `splitAroundUntil()`, adjust the preserved cursor offsets if the nodes were mutated to ensure they remain valid.

Steps to reproduce:
It is difficult to reproduce manually, but the issue occurs when coloring a link with the selection on a `feff`.
A test case replicating the situation can be based on the original failing template in the customer’s database.

opw-4953943

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

Forward-Port-Of: odoo/odoo#234328

### [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