**Steps to reproduce:**
* Install the `quality_control` module.
* Create a storable product.
* Configure a Quality Control Point:
  * Set Control per : Quantity.
  * Set Operation Type to Receipts.
  * Set Product to the created product.
* Create a Receipt for the product with a demand of  5 units.
* Confirm the receipt and mark it as To Do.
* Click on the Quality Check button.
* Click on Fail and set the failed quantity to 3.
* Click on Confirm.

**Observed behavior:**
* A new stock move is created for the failed quantity.
* The original move is split incorrectly:
  * First move: 2 `product_uom_qty` and 2 `quantity`.
  * Second move: 2 `product_uom_qty` and 3 `quantity`.
* The failed move has a demand of **2** instead of **3**.

**Cause:**
* Clicking on *Quality Check* triggers `check_quality`, 
which opens the wizard `action_open_quality_check_wizard`: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/stock_picking.py#L79-L82
* Clicking on *Fail* triggers `do_fail`, opening the confirmation wizard: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/wizard/quality_check_wizard.py#L85-L88
* Clicking on *Confirm* triggers `confirm_fail`, which calls `_move_line_to_failure_location`: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/wizard/quality_check_wizard.py#L97
* In `_move_line_to_failure_location`, a new stock move 
is created for the failed quantity: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/quality.py#L480
* The demand quantity is computed using the minimum of the 
failed quantity and the move line quantity.
* This leads to an incorrect demand of *2* instead of *3*.
* However, the move line quantity was already reduced by the failed quantity: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/quality.py#L472

**Fix:**
* Ensure that partial failures properly split stock moves with 
correct `product_uom_qty` and `quantity` values.

---

opw-5492095

Forward-Port-Of: odoo/enterprise#112298
Forward-Port-Of: odoo/enterprise#107493

**Steps to reproduce:**
* Install the **account** and **fleet** modules.
* Create a vendor bill with two expense lines using the same tax.
* Assign a vehicle_id to one line but leave the other without a vehicle.
* Confirm the vendor bill.
* Go to **Accounting > Reporting > Tax Report** and Go to `Account > Tax` report.

**Observed behavior:**
* The tax report shows: 'This report contains inconsistencies. The affected lines are marked with a warning.'

**Cause:**
* The `_get_extra_query_base_tax_line_mapping()` override forced vehicle_id matching using `COALESCE(base_line.vehicle_id, 0) = COALESCE(account_move_line.vehicle_id, 0)`.
* When lines share a tax but have different vehicle_id values (one set, one NULL), Odoo creates a single tax line with `vehicle_id = NULL`.
* The strict COALESCE constraint prevented this tax line from matching either base line (NULL ≠ vehicle_id and NULL ≠ NULL when coalesced to 0), causing the inconsistency.

**Fix:**
* Changed the constraint to only enforce vehicle_id matching when both the base line and tax line have a vehicle_id set.
* If either side is NULL, the match is allowed, letting shared tax lines work correctly across mixed vehicle/non-vehicle expense lines.

opw-5956645

Forward-Port-Of: odoo/enterprise#112313
Forward-Port-Of: odoo/enterprise#110616

Currently an error is generated when the user tries to save a report
with an empty XML format.

Steps to reproduce:
- Install web_studio and sale_management
- Sales > Studio > Reports > New > External > Type Text in report
- Save > Edit Sources > Remove full XML > Save

Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)`

This error occurs because line [1] in `web_editor` attempts to access
nodes by using `etree.fromstring()` with an empty `view.arch`, which is
empty, resulting in an error.

In earlier versions, this error was already handled by the `_check_xml`
constraint, which raised a validation error when an `etree.ParseError`
occurred while parsing `etree.fromstring(view.arch)` with an empty
`view.arch` (see code reference [2]). However, recent changes introduced
in commit [3] allow  `view.arch` to be empty. As a result, this error
is no longer handled by the constraint.

This commit fixes the issue by adding a condition to prevent calling
`etree.fromstring()` when `view.arch` is empty, avoiding attempts to access
nodes from invalid data. It also updates the logic in the `web_studio`
module's `get_xml_editor_resources` method to ensure resources are processed
only when a valid view architecture is available.


[1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367
[2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377
[3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f

sentry-6288795955

Forward-Port-Of: odoo/enterprise#112111
Forward-Port-Of: odoo/enterprise#88613

Currently, when an error occurs during `/ai/generate_response` calls from the
frontend, a `UserError` is logged with its exception stack instead of being
emitted as a logger warning. Additionally, an `UncaughtPromiseError` is
surfaced on the UI.

Error:
```
Error on request:
Traceback (most recent call last):
  File "/home/odoo/src/enterprise/saas-19.1/ai/utils/llm_api_service.py", line 302, in _request
    response.raise_for_status()
  File "/usr/lib/python3/dist-packages/requests/models.py", line 1021, in raise_for_status
```

The issue originates from the `/ai/generate_response` route, which is
defined as a controller `type="http"` to handling POST requests. When
line [1] raises an exception inside this controller, it automatically converts
the unhandled exception into an HTTP response. As a result, the request
returns a `500 Internal Server Error`, which then propagates to the frontend
and appears as an `UncaughtPromiseError`.

This commit fixes the issue by returning internal errors as chat
messages instead of raising exceptions. As a result, the error is
displayed as a message received from the AI agent, rather than
propagating as a server error to internal users.

[1]: https://github.com/odoo/enterprise/blob/423dee8f565a6ca7cd88ec0625a5059920725f50/ai/controllers/thread.py#L83

Sentry-5691330773

When a report uses 'previous_return_period' date_scope on one of its expressions, if there's no account.return.type linked to that report, the opening of the report crashes. This is a bit stupid, since a return type without periodicity will anyway fallback to the the company's tax periodicity field. When there's no return type, we should simply fallback in the same way.

To reproduce:
- Make a Belgian company, install the CoA and localization
- Manually uninstall l10n_be_reports
- Try opening the tax report

Another message also checked that we couldn't compute this date_scope in case there was more than one return type linked to the report, arguing they have different periodicities, so we can't infer which one to use. However, it they actually shared the same periodicity, that check failed anyway. We refine it to authorize this case, and only raise if they truly have different periodicities.

opw-6022150

Forward-Port-Of: odoo/enterprise#111872
Forward-Port-Of: odoo/enterprise#111796

Before this commit:
-------------------------
- In the Repair module, when a quality check for a product was marked as failed,
  Even after selecting a failure location, the failure location is not being set
  at the final product move.
- Instead of showing the selected failure location, the system displayed another
  location as the move destination after completing the repair process.

Steps to reproduce:
-------------------------
1. Install the quality_repair module.
2. In Quality, create a Control Point with:
   - Type = Pass-Fail
   - Control Per = Product or Operation
   - Set at least 1 Failure Location
3. Create a Repair Order for any product and start the repair process.
4. Perform a quality check, set it to Fail, and select a failure location.
5. Open the product moves, the destination location does not match the selected
   failure location.

Cause of the issue:
-------------------------
The failure location was not correctly assigned when a quality check failed
during the repair process because _move_to_failure_location determines the
destination location based on a stock picking (for receipts) or a production_id
(for manufacturing). In the Repair module, however, quality checks are linked to
a repair order, so the selected failure location was not set correctly.

After this commit:
-----------------------
- When a quality check fails in a repair order, the product’s destination
  location is correctly set to the failure location selected by the user.
- This ensures that, upon completion of the repair, the product is moved to the
  selected failure location, maintaining accurate inventory tracking and
  management.

Task ID:5254334

Forward-Port-Of: odoo/enterprise#99235

Steps to reproduce:
-----------------------------------------
1. Install `sale_purchase_project` and Accounting modules
2. From settings, enable Budget Management
3. Create a new product with type Service and enable Create a project on order.
4. Create and confirm the sale order with that product (note the name of created project)
5. Create and confirm purchase order as follows:
> In other information page, select the created project in the Project field
> Add the same product in POL, Set price unit price to 100 and remove any tax
6. Create and post a Vendor Bill for the same vendor as the PO as follows:
> Add Bill line with label downpayment
> Set the Analytic Distribution to the created project
> Set amount to 30
7. Go to the created purchase order > Click on bill matching
8. Select the downpayment bill > Add to PO > Select created PO > Add Down Payment
9. Go to the created project and open dashboard

Observation:
-----------------------------------------
In the Costs section:
Expected Cost: 130
To Bill: 100
Billed: 30

Expected values:
-----------------------------------------
Expected Cost: 100
To Bill: 70
Billed: 30

Issue:
----------------------------------------
In the following code:
https://github.com/odoo/odoo/blob/7e81c528ae350aab4432207f5655dcfadf6ec627/addons/project_purchase/models/project_project.py#L186-L190

When an invoice line was posted (billed), the code correctly subtracted the cost from `amount_invoiced` (making it negative, representing actual cost). But the billed amount was NOT removed from `amount_to_invoice`. This caused double counting the same cost appeared in both 'To Bill' and 'Billed'

Solution:
-----------------------------------------
Replaced the quantity-based calculation with a proper amount-based approach:
- Introduced `total_invoiced_amount` to track the sum of all non-refund invoice line amounts (both posted and draft).
- Modified the unbilled calculation to: `PO_amount - total_invoiced_amount`, ensuring that the unbilled portion accurately reflects what remains to be invoiced from the purchase order.
- Excluded refunds from `total_invoiced_amount` calculation because credit notes represent reversals of previous invoices, not consumption of the purchase order.  Refunds still correctly affect the "billed" and "to_bill" buckets through the normal invoice line processing.

This ensures the accounting principle is maintained: Total Expected Cost = Billed + To Bill = Purchase Order Amount

opw-5167734

Forward-Port-Of: odoo/odoo#245649

### Steps to Reproduce:

- Create a toggle list and add content.
- Expand the toggle list and insert a code block (e.g.: /code).
- Add multiple lines inside the code block using Enter.
- Refresh the page with the toggle open, content is preserved.
- Close the toggle and refresh then content collapses into one line.

### Description of the issue/feature this PR addresses:

- When the toggle list is closed, the code block is inside `display: none` container. In this state, `innerText` depends on rendered layout and does not preserve newline characters `\n`. As a result, multiline code content is extracted as single line.

### Desired behavior after PR is merged:

- Read html and normalize it into plain text by:
  - Converting `<br>` tags into newline characters.
  - Stripping remaining HTML tags.
  - Decoding HTML entities back to their literal characters.
  - Removing the extra newline introduced by a trailing `<br>`
  - Cleaning up invisible zero-width characters.

task-5909034

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

Forward-Port-Of: odoo/odoo#248391