This pull request introduces an automated process to periodically update the DGI (Dirección General Impositiva) state for Uruguayan electronic stock pickings, along with improvements to error handling and logging when a picking is rejected. The main changes are the addition of a scheduled cron job, enhanced logging, and user notifications for rejected pickings.

**Automated DGI State Updates:**

* Added a new scheduled cron job (`ir_cron_update_dgi_state_pickings`) that runs every 10 minutes to update the DGI state of stock pickings with electronic documents in the "received" state. (`l10n_uy_edi_stock/data/ir_cron.xml`, `l10n_uy_edi_stock/__manifest__.py`) [[1]](diffhunk://#diff-36f19bab7c2edeb0f43a1db1639b72e8508deed19652e0b1142ebfce688b9d3eR1-R11) [[2]](diffhunk://#diff-370a6cfd5890d6504958deb4a225d69ec84e84fa59deeeb52c96a849f3fdfc22R14)
* Implemented the `_l10n_uy_edi_stock_cron_update_dgi_state` method in `stock_picking.py` to process batches of pickings and trigger itself again if more records remain. (`l10n_uy_edi_stock/models/stock_picking.py`)

**Error Handling and Notifications:**

* Enhanced the `l10n_uy_edi_action_update_dgi_state` method to log rejected pickings and post a message in the chatter to notify users when a picking has been rejected by DGI, prompting manual review and correction. (`l10n_uy_edi_stock/models/stock_picking.py`)
* Introduced logging setup for the module to support the new logging functionality. (`l10n_uy_edi_stock/models/stock_picking.py`) [[1]](diffhunk://#diff-108d31170c95f307accd45410f9a98bd16ce0413932fab4732eb764d75d3e260R2) [[2]](diffhunk://#diff-108d31170c95f307accd45410f9a98bd16ce0413932fab4732eb764d75d3e260R14)

Forward-Port-Of: odoo/enterprise#109518

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

Steps to reproduce:
---
- Install `Sales` module.
- Create a Sale Order.
- Add a section with products.
- Add a subsection under it with products.
- Enable `Hide Prices` on the section.
- Enable `Hide Composition` on the subsection.
- Preview the Sale Order.

Issue:
---
- Prices are still visible in the subsection (grouped view) even though `Hide Prices` is enabled on the parent section.

Root cause:
---
- The variable `show_section_total` was defined only within the main rendering block and not reused in the grouped (`t-else`) block.
- The grouped section summary (used when `collapse_composition=True`) did not respect the parent section's `collapse_prices` setting, causing prices to be displayed.

Solution:
---
- Moved `show_section_total` definition outside the main conditional block so it can be reused in both rendering paths.
- Applied `t-if="show_section_total"` to price fields in the grouped section summary to ensure consistency with the parent section's price visibility.

Before:
---
<img width="1030" height="232" alt="image" src="https://github.com/user-attachments/assets/1ac05e5e-6841-420f-909f-994690656cc0" />

After:
---
<img width="1023" height="232" alt="image" src="https://github.com/user-attachments/assets/921ae337-4d53-433a-a42b-bdc437181889" />



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

Forward-Port-Of: odoo/odoo#255464

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

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#256009
Forward-Port-Of: odoo/odoo#255316

The AVCO audit report currently recalculates the AVCO value on outgoing moves. Based on the logic in `run_average_batch()`, it should instead use the AVCO value computed on the last ingoing move to recalculate the
`added_value`.                                                         

On the other hand, the `added_value` should not be recomputed from the AVCO value on ingoing moves.

Source of those changes: [245141](https://github.com/odoo/odoo/pull/245141)

Steps to reproduce the issue:
1. Create a new product. Do not assign it to a category yet.
2. Set the cost (standard_price) to 10$ on the product form.
3. Add 10 units to inventory.
4. Sell and deliver 5 units to a customer.
5. Purchase 10 units at 25$/ea and validate the receipt.
6. Sell and deliver 5 units to a customer.
7. Assign the product to category with AVCO cost method.
8. Go to the AVCO justification report:
    - The added value on the purchase is incorrect: 200$ instead of 250$.
    - On the last delivery: the added value is -125$ and the AVCO increases from 20$ to 25$.

Ticket: opw-5921104

Forward-Port-Of: odoo/odoo#252239

**Description of the issue this PR addresses:**
Ensure the `Looking for Help` timer is shown even when the current 
user is already a member of the livechat channel.

**Steps to Reproduce:**
1. Log in as a visitor and as Mitchell Admin (Live Chat operator).
2. From the visitor side, select I have a pricing question.
3. From the admin side, mark the conversation as Looking for Help.
4. The channel appears in the Looking for Help category.
5. Observe that the timer should be visible there (e.g., 1m).

**Current behavior before PR:**
- The timer was hidden when an agent was already a member of the 
conversation, assuming that once an agent joined, the `waiting for help` 
phase was over.

- However, in escalation workflows an analyst may escalate a chat and 
remain a member while the channel returns to the `Looking for Help` 
state for another expert. In this case, the escalating analyst could not 
see the timer needed to track SLA requirements (e.g., creating a 
ticket after 10 minutes).

- Also, the mock server did not recompute
`livechat_looking_for_help_since_dt` when `livechat_status`
changes, leading to incorrect timer values (e.g., showing 2d
instead of < 1m after switching back to Looking for Help).

**Desired behavior after PR is merged:**

- The timer is displayed whenever the channel is in `need_help` 
and `livechat_looking_for_help_since_dt` is set, regardless of 
whether the current user is a member of the channel.
- The mock server now mirrors server-side behavior by updating
`livechat_looking_for_help_since_dt` when livechat_status changes,
prevents missing recomputations and ensuring consistent test
behavior.

task-[6009851](https://www.odoo.com/odoo/project/1519/tasks/6009851)


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

Before this commit, closing an AI chat window could lead to the following crash:

```js
TypeError: Cannot read properties of undefined (reading '_raw')
```

Steps to reproduce:
- have no chat windows open, cache cleared.
- open DM with demo in chat window from messaging menu, in home menu.
- open AI chat, from systray.
- close the AI chat window. => crash

This happens because when closing the AI chat window, it deletes the AI conversation. By deleting the AI conversation, it removes the conversation from `store.menuThreads`, which is the list of conversations to display in messaging menu. Removal of this conversation in `menuThreads` is done internally through

```js
const index = recordList.indexOf(record);
recordList.splice(index, 1);
```

This is done that way as to reuse custom methods of `RecordList`, especially the `splice()` that is used by many methods that mutate the record list. Internal code of the custom `splice` method does `slice()`, which is used to retrieve some records without mutating the record list.

In practice, these `.slice()` were accidentally mutating the list, because they invoke the `Proxy.getter` of the `RecordList`, and when the list is flagged for `computeOnNeed` / `sortOnNeed`, invoking this `Proxy.getter` would mistakenly enable the `computeInNeed` / `sortInNeed` flags and thus mutate the list, e.g. with a sort, which may change the order of items and mess up the `index` computed in `indexOf()` step.

This is what happens with the chat window. The `menuThreads` looked something like this:

```js
menuThread = ["thread_1", "thread_2", "thread_3"];
```

With the removal of `thread_2`, the `.indexOf()` is `1`, but due to `.slice()` triggering the sort, the list was changed to:

```js
menuThread = ["thread_2", "thread_1", "thread_3"];
```

... And it instead removed `thread_1` but kept `thread_2` in list. This introduce 2 problems:
- `thread_1` is mistakenly removed from relation when it shouldn't
- `thread_2` is kept, but since this is a local id with no actual record in store, `recordList[index]` would return `undefined` as there's no existing record matching this local id.

This commit fixes the issue by improving internal code of record list
methods to avoid accidental triggering of lazy re-compute and
re-sort. The accidental re-compute and re-sort come from invoking
non-implemented array methods on the proxy of record, such as:

- `recordProxy.at()`
- `recordProxy.slice()`

These methods were just used meant to retrieve records from the record list, and they did so by using accessing through `recordProxy`. This approach has the benefit to look good as this is exactly the same as the external API, but it has the unintended side-effect of the re-compute / re-sort of lazy fields. Instead of using these methods, records are retrieved with:

- raw access to get local ids in relation
- convert local ids to raw records through raw access in `store.recordByLocalId`

This approach, while uglier, has the benefit to not accidentally trigger the re-compute / re-sort.

opw-5761279

Forward-Port-Of: odoo/odoo#251769

Before this commit, when in discuss call and current user has microphone muted, the icon has light red / pink background color on muted instead of red.

The color should be the same as the one from "disconnect", but the difference comes from `btn-danger` with or without `.active` that has different shade of red for background: the `.active` version is lighter like in the mute button when active.

`.active` classname is preferred to keep so that the visual is consistent for most discuss actions, including the ones without success / danger which a majority of these buttons have. However, the buttons with danger / success style are intended to preserve their color unchanged as the `.active` aspect is meant to tell whether the button is active or not and the slight change of color shade is not desirable in the context of discuss action list.

This commit uses the same background color for danger / success / primary inline button. Other styles line dropdown and inline buttons without background had already the same colors, so this commit fixes the only case that was missing.

Task-5436990

Before / After

<img width="283" height="38" alt="Screenshot 2026-03-13 at 15 21 22" src="https://github.com/user-attachments/assets/3ebba48c-5b22-43e9-a915-e18a5531e660" /> <img width="270" height="41" alt="Screenshot 2026-03-13 at 15 21 45" src="https://github.com/user-attachments/assets/586d05a4-2a6c-48e0-89c6-bffa85a86e59" />

Forward-Port-Of: odoo/odoo#253923