**Steps to reproduce:**
- Install the `l10n_fr_account_loans` module and switch to a `FR Company`.
- Navigate to Accounting > Accounting > Assets & Liabilities > Loans.
- Create a new loan record.
- Click `Add a line`, set a `Date`, and `save` the record.
- Click `Add a line` again.

**Error:**
`TypeError: '>' not supported between instances of 'datetime.date' and 'bool'`

**Root Cause:**
At [1], when adding a line after the record has already been saved with 
at least one existing line, the existing line has a valid `datetime.date` 
value for `l.date`, while the newly created unsaved line still has `line.date` 
set to `False`. This results in a comparison between a `datetime.date` object 
and a boolean value, causing an error.

**Fix:**
This commit prevents the errors when adding multiple lines after saving the 
record by applying a fix similar to [2].

[1]:
https://github.com/odoo/enterprise/blob/54eef93f295eaebd98d24730d108b1203ca7b35a/l10n_fr_account_loans/models/account_loan_line.py#L21

[2]:
https://github.com/odoo/enterprise/blob/54eef93f295eaebd98d24730d108b1203ca7b35a/account_loans/models/account_loan_line.py#L61-L63

opw-6244973

## [FIX] web_gantt,planning: apply hasGroup before compute params

Before this commit, some actions like drag and drop gantt pills are
blocked for planning manager instead of being allowed only for them. The
reason is because the compute params is something made before checking
if the user is a planning manager and so the system will consider the
user is not a planning manager. The compute params is something made
before because the methods are executed inside 2 distincts onWillStart
hook and so OWL framework cannot know one hook depends on the other one.

This commit creates a method `onWillStart` in the main gantt controller
to be able to override it and be able to wait a rpc before processing
the compute params.

## [FIX] planning_field_service_sale_timesheet: don't count unscheduled intervention

This commit filters the interventions counted to display the field
service stat button in the form view of Sale Order. Now the intervention
unscheduled will no longer be counted and also the one linked to
plannable SOL.

## [FIX] planning_field_service: send email to customer when intervention published

Before this commit, the template "Field Service Scheduled" was unsused.

This commit uses that template to send an email to the customer once the
intervention is scheduled.

## [FIX] planning_field_service: send report when intervention completed and signed

Before this commit, the customer signs the intervention completed and
does not received any email with the intervention report. He has to
create an account in the DB as portal user to be able to see his
intervention or ask to contact person to send him the report by mail.

This commit will automatically send the intervention report by mail to
the customer once the intervention is completed and signed by the
customer.

## [FIX] planning_field_service: fix label and record_name in email sent for Field service

Before this commit, the button sent to the customer to see the
intervention is `View Planning Slot` and the record name used inside the
same email is the display name which is not useful for the customer.

This commit changes the label of the button displayed to see `View
Report` and change the record_name to show `Field Service -
<intervention date>` as shown in the portal view.

## [FIX] planning_field_service: no login required to access to intervention

Before this commit, the customer cannot access to the intervention
without begin log in even if he has the access token.

This commit changes the route access to let the user access to the
intervention completed and he can also sign it.

## [FIX] planning: hide duplicated name field in kanban displayed in gantt

This commit hides the duplicated name field displayed in the popover of
the gantt view in the planning.slot model.

## [FIX] planning_field_service: rename module name

This commit renames the module to call it `Field Service` instead of
`Planning - Field Service`.

## [FIX] worksheet: only show property warning message in mobile

## [FIX] planning: define employee_public_ids field in planning.slot

Before this commit, when a planning user goes to a shift he will see
Assign to me button on a shift assigned to another human resource which
is normally not allowed. The reason because the button is visible is
because `employee_ids` field is always empty for users who are not HR
user.

This commit adds `employee_public_ids` field which is also a computed
field non stored to get the employee for the user who is not a HR user.

## [FIX] planning_field_service: always compute break_time

This commit removes the default value on break_time field to always
trigger the compute of that field, the reason is because by default the
allocated_hours computed when we create a shift, will not always cover
the whole duration of the shift, the allocated hours of the shift is
computed based on the working schedule of the shift and so the
break_time field has to be computed afterwards to make sure the break
time is correctly set instead of having 0 by default when we create a
shift.

task-6060493

**Issue**
The scrap location provided by the user may be overridden while confirming a scrap move

**Steps to reproduce**
- In settings, enable the tracking of location in the warehouse
- Have two location of type 'Inventory loss'
- Create a scrap move and change the scrap location
- confirm the move
-> The scrapped move will be created using the scrap location already present before the user changes it

**Cause**
The regression has been introduce by this refactoring commit: https://github.com/odoo/odoo/commit/1c7d80a10b5d7db1c4163166bf52b3f3c77044ba

While confirming the scrap move:
https://github.com/odoo/odoo/blob/f68473898b97db55a1ef5bee1d4f7865fb6b6d8a/addons/stock/models/stock_move.py#L2726
https://github.com/odoo/odoo/blob/f68473898b97db55a1ef5bee1d4f7865fb6b6d8a/addons/stock/models/stock_move.py#L2731
It needs to access the `stock.move` record:
https://github.com/odoo/odoo/blob/f68473898b97db55a1ef5bee1d4f7865fb6b6d8a/addons/stock/models/stock_move.py#L2133
Since this is the first access, it triggers the compute method of `location_dest_id`:
https://github.com/odoo/odoo/blob/f68473898b97db55a1ef5bee1d4f7865fb6b6d8a/addons/stock/models/stock_move.py#L227-L228
Which sets it to the company's scrap location, regardless of the value provided by the user:
https://github.com/odoo/odoo/blob/f68473898b97db55a1ef5bee1d4f7865fb6b6d8a/addons/stock/models/stock_move.py#L237-L238
This value is compute here:
https://github.com/odoo/odoo/blob/f68473898b97db55a1ef5bee1d4f7865fb6b6d8a/addons/stock/models/res_company.py#L62-L65
This value is computed by taking the first scrap location found for this company

opw-6125152

When a receipt dest location or delivery source location get archived, the corresponding move may not be taken into account when computing the total_value / avg_cost at date.

OPW-6099192

---

### Test result without fix

```
2026-04-23 06:30:34,016 10516 INFO oes_test_19 odoo.addons.stock_account.tests.test_stockvaluation: Starting TestStockValuation.test_archived_location_valuation ... 
2026-04-23 06:30:34,255 10516 INFO oes_test_19 odoo.addons.stock_account.tests.test_stockvaluation: ====================================================================== 
2026-04-23 06:30:34,255 10516 ERROR oes_test_19 odoo.addons.stock_account.tests.test_stockvaluation: FAIL: TestStockValuation.test_archived_location_valuation
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/19.0/odoo/addons/stock_account/tests/test_stockvaluation.py", line 3326, in test_archived_location_valuation
    self.assertEqual(self.product_avco.with_context(to_date=date_1).avg_cost, 10)
AssertionError: 20.0 != 10
 ```

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

Forward-Port-Of: odoo/odoo#263354
Forward-Port-Of: odoo/odoo#260922

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

Steps to reproduce:
--------------------

1.Install modules `sale_management`, `purchase`, and `mrp`.
2. Go to Settings and enable the MTO (Replenish on Order) route.
3. Create a product with:

       i. Configure a Vendor under the Purchase tab.
      ii. Set the route to MTO.
     iii. Create a Bill of Materials for the product.
5. Create a Sale Order with the configured product and confirm it.
6. Open the generated Manufacturing Order.
7. Duplicate the Manufacturing Order.

Issue:
------

* The duplicated Manufacturing Order shows a smart button
linked with the Sale Order, which is incorrect.

Root Cause:
------------
 This issue is coming form this [Commit](https://github.com/odoo/odoo/commit/2713876dbc70d3984e584a9037a2206dcda4e84a#diff-2b9de2e50ff5e1dc0362b825bac2b07623770fb3275b3257ef972f255f3ccb8b) 

* During Sale Order confirmation, the flow
`action_confirm` → `_action_confirm` → `_action_launch_stock_rule`
→ `run` → `_run_pull` → `_action_confirm` calls
`_prepare_procurement_values`.
which gather all procurement values.
In sale_stock, the super call adds `sale_line_id` to the
generated Manufacturing Order when using MTO:
https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/sale_stock/models/stock.py#L138-L140

* So, when the Sale Order is confirmed, the generated
Manufacturing Order contains sale_line_id, and when this
Manufacturing Order is duplicated, the sale_line_id is also
copied.

* In sale_mrp, the smart button uses sale_line_id to compute
the linked Sale Order count:
https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/sale_mrp/models/mrp_production.py#L19

Solution:
-----------
* Prevent copying of sale_line_id when duplicating a
Manufacturing Order, ensuring duplicated records are not
linked to any Sale Order.

---

opw-6113149


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

Forward-Port-Of: odoo/odoo#259128

Sending the final invoice of a sale order to ZATCA crashed with `ValueError: Expected singleton: account.move(a, b)` when the sale order had multiple down-payment references.

Steps to reproduce:
1. Configure a SA company and setup ZATCA
2. Create a sale order and confirm it
3. Deliver the product line.
3. From the sale order, create a down-payment invoice (fixed amount, e.g. 115) and post it (DP1).
4. On DP1, click "Credit Note" and choose "Full refund and new draft invoice"; validate. DP1 becomes `reversed` and a new draft down-payment DP2 is created. Post DP2.
5. From the sale order, create the final regular invoice and post it.
6. Send the final invoice to ZATCA (or generate its XML) -> `ValueError: Expected singleton: account.move(a, b)`.

Root cause: _l10n_sa_get_line_prepayment_vals looks up the related down-payment move through the down-payment sale order line shared with the product line. The filter matched any out_invoice with _is_downpayment() == True, so the reversed DP1 and the active DP2 both ended up in the recordset, and reading .name raised the singleton error.

Prefer non-reversed down-payment moves when available, but fall back to reversed ones if no alternative exists (e.g.
when generating a credit note of the final invoice after the original down-payment was itself reversed).

opw-6116265

Forward-Port-Of: odoo/odoo#264435
Forward-Port-Of: odoo/odoo#259384

### Issue before this commit:
Importing a simplified Italian electronic invoice or credit note (e.g., TD08) fails with a float division by 0 traceback if a document line consists entirely of taxes (where the total line amount equals the tax amount).

### Steps to reproduce the issue:
1. Download Accounting and l10n_it
2. Switch to IT company
3. Go to Vendors > Refunds
4. Try to import the xml from the ticket

### Cause of the issue:
The XML parser attempts to dynamically calculate the tax percentage using the formula tax_amount / (amount - tax_amount). When a line is purely a tax adjustment, the taxable base (amount - tax_amount) evaluates to exactly zero, triggering the critical division by zero crash.
https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/l10n_it_edi/models/account_move.py#L1863-L1867

### Reason to introduce the fix:
To ensure Odoo successfully imports valid, tax-only EDI documents already accepted by the Agenzia delle Entrate.

Ticket [link](https://www.odoo.com/odoo/project.task/6217373)
opw-6217373

Forward-Port-Of: odoo/odoo#266930
Forward-Port-Of: odoo/odoo#266374