In Italy the periodic VAT return (LIPE) is filed quarterly, so `is_quarter_month` gates the XML export wizard on March, June, September and December. That field only looks at the date, never at the kind of return, so every Italian return locked on a quarter month was treated as a LIPE.

Submitting the withholding tax return therefore opened the LIPE export wizard. Depending on the record the wizard receives, it either crashes while reading the VP lines missing from the withholding report, or silently generates a LIPE file and attaches it to another return.

Add an `is_lipe_return` field telling whether the return actually produces the LIPE.

Steps to reproduce:
- Install `l10n_it_xml_export` and `l10n_it_edi_withholding_reports` on an Italian company with monthly returns
- Open Accounting > Reporting > Tax Return
- Review and submit the withholding returns up to February
- Review then submit the March withholding return --> The LIPE export wizard opens, and the export fails on the withholding report.

opw-6255016

Forward-Port-Of: odoo/enterprise#126676
Forward-Port-Of: odoo/enterprise#125263

# How to reproduce
- Set the current employee's schedule to one with :
    - Schedule Type : Flexible
    - Total : a different amount than "Full Time Equivalent"
- Go to My Timesheets
- Add a new line with some Time Spent > 0
- Hover the bottom right cell of the grid (this is the total overtime for the week)

# The issue
The computation of the overtime for the week is based on "Full Time Equivalent" instead of "Total". This is inconsistent with the Planning app and the All Timesheets view.

# Cause
This [PR] introduced the usage of `full_time_required_hours` to compute the total overtime. This field was used because `hours_per_week` ("Total") was thought to be computed using `resource.calendar.attendance`. However, that is not the case when the schedule is flexible : https://github.com/odoo/odoo/blob/46d3fee5812b8406aac2244baa76b0daeef358c2/addons/resource/models/resource_calendar.py#L220 https://github.com/odoo/odoo/blob/46d3fee5812b8406aac2244baa76b0daeef358c2/addons/resource/models/resource_calendar.py#L163-L166

[PR]: https://github.com/odoo/enterprise/pull/81057

opw-6303520

Forward-Port-Of: odoo/enterprise#125510

**Steps to reproduce:**
- Install l10n_din5008 and Accounting.
- Enable Snailmail from Accounting → Settings.
- Create a German customer (Fiscal Country: Germany).
- Create and post a customer invoice using the DIN5008 report layout.
- Select Send by Post.
- Enable Developer Mode and navigate to Settings → Technical → Email → Snailmail Letters.
- Open the generated letter and send it.

**Observed behavior:**
The address blocks are incorrectly aligned when the DIN5008 report is rendered for snailmail. The information block and recipient address do not follow the expected vertical positioning.

**Cause:**
The DIN5008 layout previously applied vertical alignment rules to its table cells. These rules were removed while adapting the layout to the invoice table structure and its customizations, such as the position column and line numbering.

While this alignment is no longer required for the regular DIN5008 invoice layout, the snailmail layout relies on it to correctly position the sender/invoice information and recipient address blocks.

**Fix:**
Add a `snailmail` class to the DIN5008 invoice section when `snailmail_layout` is present in the rendering context.

Restore the required vertical alignment rules scoped to this class so they only affect snailmail reports, without changing the regular DIN5008 layout.

**References**

* **PR:** [#201225 – DIN5008 layout improvements](https://github.com/odoo/odoo/pull/201225)
* **Ticket:** [6387869](https://www.odoo.com/odoo/project/49/tasks/6387869)

opw-6387869

Forward-Port-Of: odoo/odoo#285891

**Steps to reproduce:**
- Create a quotation
- Add order lines until reaching 200 (duplicating helps), save and ensure that the pager appeared (1-200/201)
- Drag one of the lines with the handle to reorder them
- Discard all changes (X shaped button) 

You will have an evaluation error

**Behavior:**
When loading a list of records exceeding the limit, only parts of the records are saved in `_cache`.
When triggering a reordering of said list, all records need to be loaded including the ones on other pages: https://github.com/odoo/odoo/blob/d4eff7b14d37a9b59c95d304542a5a12629bc90b/addons/web/static/src/model/relational_model/static_list.js#L1139-L1149 `_getResIdsToLoad()` gets all Ids missing from the cache, these are then passed through `._createRecordDatapoint` and will then be stored in `_cache`.
The issue is that the Datapoints are getting created with only `activeFields` as data, which in our case are `id` and `sequence`

When discarding the changes `._checkValidity()`is called on each Datapoint: https://github.com/odoo/odoo/blob/d4eff7b14d37a9b59c95d304542a5a12629bc90b/addons/web/static/src/model/relational_model/record.js#L423-L429 And then `._isInvisible()` is called.
This is where the issue happens, since only `sequence` and `id` are stored, when we try evaluate `combo_item_id`, which is the condition to see if sequence is invisible, `combo_item_id` is not found and we get an Evaluation Error.

This commit prevents going into `._checkValidity()` by adding `this.isInEdition` to the check leading to it, requiring that the record is in 'edit' mode which is not the case for records created with `_createRecordDatapoint()`

opw-6399024

Forward-Port-Of: odoo/odoo#281018

Steps to reproduce:
- Install `l10n_fr_pdp` and `l10n_be` module
- Activate `French e-invoicing` (you need to put your DB in test mode)
  (i.e: `account_peppol.edi.mode = 'test'` in system parameter) Refer this Documentation https://www.odoo.com/documentation/19.0/applications/finance/fiscal_localizations/france.html?highlight=e%20invoicing#localizations-france-e-invoicing-fac-elec-config
- Create a Invoice and Sent with `E-invoicing`
- Run `PEPPOL: retrieve new documents` Cron
- In Invoice Other Info >  `E-Invoicing Status` should be in `Done` state
- Now Vendor Bill is created for that invoice > Cancel that bill with reason >  Check `E-Invoicing Status` response for bill(one response will be without UUID)
- Go to schedule actions > `PEPPOL: update message status`
- Run it and get the traceback: `KeyError: 'false'`

Issue:
When sending a lifecycle response to the French PDP, `_pdp_send_response` calls the `/api/pdp/1/send_response` endpoint and expects IAP to return a `message_uuid` for each response.

However, IAP return a response without a message UUID, for example: ` {'messages': [{'message_uuid': False}]}` `_pdp_send_response` currently assumes that every returned message has a valid UUID and creates an `account.peppol.response` with:
```
    'peppol_message_uuid': False
    'peppol_state': 'processing'
```
This leaves an `account.peppol.response` in `processing` state without a UUID that can be used to track it.

During the next execution of `_cron_peppol_get_message_status`, `_peppol_get_message_status` retrieves this response through `_peppol_get_documents_for_status` and builds `uuid_to_record` using `peppol_message_uuid` as the key. The resulting mapping contains the Python value `False` as a key.

The cron then calls the PDP `1/get_document` endpoint with this invalid UUID. IAP returns it as the string `'false'`, which is passed to `_peppol_process_messages_status`. The French PDP implementation tries to retrieve the corresponding record with: `uuid_to_record[uid]`

Since the mapping contains `False` while `uid` is `'false'`, this raises: `KeyError: 'false'`

This failure prevents the status cron from completing the processing of the messages.

Solution:
Avoid creating the `account.peppol.response` when IAP does not return a `message_uuid`. A response without a UUID cannot be tracked through the PDP status flow, so creating it in `processing` state only leaves an
invalid record that will later cause the status processing to fail.

opw-6453133

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

Forward-Port-Of: odoo/odoo#281691

The search order on account move line depends on date, move name and id.
This search result order can be non deterministic because,
when creating account move line from stock valuation, it depends on the order from a set, but sets are unordered.

**Step to reproduce**
Run [test_subcontracting_purchase_bill](https://github.com/odoo/odoo/blob/13b2781978b0edad0df0800404276919b767e32b/addons/mrp_subcontracting_purchase/tests/test_mrp_subcontracting_purchase.py#L268) in:
Single app, community, with demo data.

**Observation**
* The search:
When doing the search since we didn't specify any order,
the search from account.move.line will ordered by:
https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/addons/account/models/account_move_line.py#L23
https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/addons/account/models/account_move_line.py#L1664
Since, for the components the date and move name are the same it will only depend on the aml ids:

* `Account.move.line` creation:
When it validate the receipt (`button_validate`)
https://github.com/odoo/odoo/blob/869c750f978b1b00a4a04bd61226f0e20d2e7729/addons/mrp_subcontracting_purchase/tests/test_mrp_subcontracting_purchase.py#L296

It will mark as done the picking (`_action_done`) and the productions (`button_mark_done`) linked to this picking.
https://github.com/odoo/odoo/blob/869c750f978b1b00a4a04bd61226f0e20d2e7729/addons/stock/models/stock_picking.py#L1429
https://github.com/odoo/odoo/blob/869c750f978b1b00a4a04bd61226f0e20d2e7729/addons/mrp_subcontracting/models/stock_picking.py#L49
Modify the inventory accordingly (`_post_inventory`)
https://github.com/odoo/odoo/blob/869c750f978b1b00a4a04bd61226f0e20d2e7729/addons/mrp/models/mrp_production.py#L2231
while inside of `_post_inventory`, it will process all the production moves, for this it will divided them in set to process them by batch:
https://github.com/odoo/odoo/blob/f0e58b9324af18d0cf0264aec2886d098e997f03/addons/mrp/models/mrp_production.py#L1904-L1911

From this set, it will create the `account.move.line`:
It retrieve the actual stock move with the browse, and call `_action_done`, from where the stock valuation layer will create the `account.move.line`.
https://github.com/odoo/odoo/blob/f0e58b9324af18d0cf0264aec2886d098e997f03/addons/mrp/models/mrp_production.py#L1913
https://github.com/odoo/odoo/blob/f0e58b9324af18d0cf0264aec2886d098e997f03/addons/stock_account/models/stock_move.py#L187
The issue arise because a set read order is non deterministic.

runbot-939794

Forward-Port-Of: odoo/odoo#279396

Version:
--------
- 19.0+

Steps to reproduce:
-------------------
- Install `stock`, `purchase`, and `accountant`
- Create a storable product with:
  - Tracking Inventory enabled
  - Control Policy set to **Ordered Quantities**
- Create and confirm a Purchase Order with some unit price
- Do not receive or invoice the order
- From the Purchase Order gear menu, click **Accrued Expense Entry**

Issue:
------
The Accrued Expense Entry wizard opens, but no accounting lines are
generated.

For products invoiced on **Ordered Quantities**, the ordered quantity
should already be accrued even though nothing has been received.

Cause:
------
This issue was introduced after this changes [commit](https://github.com/odoo-dev/odoo/commit/81f25bc57b8433a65bf33950c64dc7582240a229)

Previously, the accrual wizard relied on the stored
`qty_to_invoice` field, whose computation already respected the
product's Control Policy.

For products invoiced on **Ordered Quantities**,
`_compute_qty_invoiced()` computes the quantity to invoice from the
ordered quantity:

https://github.com/odoo/odoo/blob/810a02a577c2811dc5c12f0abf45eebb9cf96d00/addons/purchase/models/purchase_order_line.py#L147-L152

The refactoring replaced this logic with the new
`amount_to_invoice_at_date` field, which always computes the invoicable
quantity as:

`qty_received_at_date - qty_invoiced_at_date`
https://github.com/odoo/odoo/blob/65dbcabcd243abf24d6d3c3788d2caff66485790/addons/purchase/models/purchase_order_line.py#L282-L285

This formula ignores the product's Control Policy.

For products invoiced on Ordered Quantities, before any receipt:

`qty_received_at_date` = 0
`qty_invoiced_at_date` = 0

therefore:

`amount_to_invoice_at_date` = 0

The Accrued Expense wizard filters out lines whose
`amount_to_invoice_at_date` is zero:

https://github.com/odoo/odoo/blob/65dbcabcd243abf24d6d3c3788d2caff66485790/addons/account/wizard/accrued_orders.py#L168-L178

As a result, the purchase order line is excluded entirely and the
wizard produces no accounting entries.

The same assumption is also used later in
`account.accrued.orders.wizard._compute_move_vals()` when computing
tax-included amounts, causing incorrect accrual values for
Ordered Quantities products whenever receipts and invoices differ.

Fix:
----
Introduce `_get_qty_to_invoice_at_date()`, mirroring the existing
purchase_method logic used by _compute_qty_invoiced().

The helper returns:

product_qty - qty_invoiced_at_date for Ordered Quantities
products;
`qty_received_at_date` - `qty_invoiced_at_date` for
Received Quantities products.

Now products invoiced on `Ordered Quantities` become
accruable as soon as the Purchase Order is confirmed;

---

opw-6290782

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

Forward-Port-Of: odoo/odoo#276435

Problem:
When applying color on a selection that spans across partially selected inline elements (e.g. `<p><b>a[b</b>c]d</p>`), container elements whose contents are not fully selected (such as `<b>`) were included in `targetedNodes`. This caused improper color formatting/nesting on partially selected elements.

Cause:
In `ColorPlugin._applyColor()`, `targetedNodes` were filtered by checking `isNodeEditable(node)` and `nodeName !== "T"`, but did not check whether the contents of `node` were fully selected (`areNodeContentsFullySelected(node)`). As a result, partially selected ancestor elements were included in `targetedNodes`.

Solution:
Filter `targetedNodes` in `_applyColor()` using
`this.dependencies.selection.areNodeContentsFullySelected(node)` to ensure only fully selected nodes are targeted when applying colors.

Steps to reproduce:
1. Open html_editor.
2. Insert content: `<p><b>ab</b>cd</p>`.
3. Select `b` inside `<b>` and `c` inside `<p>` (`<p><b>a[b</b>c]d</p>`).
4. Apply text color (e.g. red).
5. Observe "ab" and "c" was colored instead of just "b" and "c".

task-6456443

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

Forward-Port-Of: odoo/odoo#285658
Forward-Port-Of: odoo/odoo#281462

Currently, an error occurs when a user tries to view the WhatsApp Business account.

**Steps to Reproduce:**

 - Install the `whatsapp_oauth` module.
 - Go to `Settings` > `Languages` and add `French (BE)`, then `switch to it`.
 - Go to `WhatsApp` > `Configuration` > `WhatsApp Business Accounts (Comptes Whatsapp Business)`.

`ValueError: L'élément '<xpath expr="//div[contains(normalize-space(.), 'Receiving Messages')]">' ne peut être localisé dans la vue parente`

When the user changes the language, the text in the view is translated [1]. Since the WhatsApp 
account view tries to locate the div using the plain text Receiving Messages [2]. Since the text 
has been translated in the parent view, the XPath can no longer locate the element and raise 
the error.

This commit ensures that the XPath uses the name attribute to identify the element, which is 
language-independent. We cannot use the class attribute because the same class is used by 
other div elements.

[1]- https://github.com/odoo/enterprise/blob/a3db72899cb97612505aebbd5450aeb65205db73/whatsapp/views/whatsapp_account_views.xml#L81-L84

[2]- https://github.com/odoo/enterprise/blob/a3db72899cb97612505aebbd5450aeb65205db73/whatsapp_oauth/views/whatsapp_account_views.xml#L61-L63

7534862409

Forward-Port-Of: odoo/enterprise#130003