The CTE `model_fees` is supposed to get the reconciliation models that match conditions that involves a join with the ir.model.data table. One of these conditions is filtering based on the `name` field with an `LIKE` operator.

On databases that has a GIST index on the field `name`, the planner will prefer to filter the records based using the GIST index and add the extra filters as a filtering criteria after the index condition if the index-condition wasn't possible to be switched to a range-query. The condition is supposed to be a prefix-matching, which can be evaluated directly by a B-TREE if the field had an index and the planner can convert the condition to a range-query.

Apparently the `_` in `account_reco_models_fees_%%` was evaluated as a wild-card, making the condition a substring-matching rather than direct prefix-matching. In this PR, I have modified the condition to escape the '_' wildcards.

The benchmark done below was on a database that has around **10^7** `ir.model.data` records and 1K `account.reconciliation.model` records. I have split the benchmark into two cases, a case where the buffer-pool of
postgres warmed-up and a case where it is not.

After Worst case -> https://explain.dalibo.com/plan/975geg1f1h109d5c
Before Worst case -> https://explain.dalibo.com/plan/0ce9bf3g0ad8f98b

After Best Case -> https://explain.dalibo.com/plan/1a77459dadb0gfc4

Definition of ir_model_data_name_idx2  -> CREATE INDEX ir_model_data_name_idx2 ON public.ir_model_data USING gist (name gist_trgm_ops)

Definition of ir_model_data_module_name_uniq_index -> CREATE UNIQUE INDEX ir_model_data_module_name_uniq_index ON public.ir_model_data USING btree (module, name)


| PostgreSQL Buffer Pool Status | Before | After |
| :--- | :--- | :--- |
| Not warmed up (Cold) | 11s | 130ms |
| Warmed up (Hot) | 0.022ms | 0.097ms |

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

Before this commit, if the `_l10n_mx_edi_cfdi_invoice_append_addendas` method was executed more than once on the same invoice, the resulting CFDI would contain multiple `<cfdi:Addenda>` nodes.

This occurred because the method manually injects the new Addenda string at the end of the XML without checking if one was already present from a previous execution.

According to the SAT's Anexo 20 and the CFDI 4.0 XSD, the Addenda must be a single node and the last element of the Comprobante. Duplicating root-level nodes like `cfdi:Addenda` is a bad XML formation practice that can cause rejection by the recipient's automated systems.

This fix ensures the CFDI structure remains valid by:
1. Searching for an existing `{*}Addenda` node in the CFDI string.
2. Removing the old node before reconstructing the XML.
3. Preventing the string replacement logic from stacking multiple Addenda blocks.

This ensures that the CFDI remains clean and compliant with the official standard even if the process is triggered multiple times.

Forward-Port-Of: odoo/enterprise#109760

**Steps to reproduce:**
- Create a flexible 32h/week calendar (8h/day, 4 days)
- Assign it to an employee with the Default Ruleset
- Create attendances: 8h on Monday, Tuesday, Friday, and Saturday (32h total, matching the weekly budget)
- Select the list view and go to the month of the attendances
- Employee shows 16:00 Worked Extra Hours (8h on Fri + 8h on Sat)

**Cause:**
`resource.calendar._attendance_intervals_batch` generates work intervals for flexible calendars by front loading the weekly hour budget onto the first days of the week (Mon 8h, Tue 8h, Wed 8h, Thu 8h for a 32h calendar), But days beyond the budget (Fri, Sat, Sun) get zero hours.

The two overtime rule paths relies on these synthetic intervals:

1) The quantity rule: `_get_daterange_overtime_undertime_intervals_for_quantity_rule()` computed `expected_duration` by intersecting the synthetic schedule with each day. For Fri/Sat the intersection was empty (expected = 0) -> all worked hours counted as overtime.

https://github.com/odoo/odoo/blob/b31fd6816521ff43fb3a9ec37e79e9a9d628d357/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L302-L304

**update** solved by: https://github.com/odoo/odoo/pull/265120/changes/94d4bfffa053cd78ce07ff07ab14b53e8d931053

2) The timing rule: `_get_rules_intervals_by_timing_type()` derived "work_days" from the synthetic schedule and inverted them to get "non_work_days". (Fri, Sat, Sun) were classified as non-working days, therefore, any attendance on those days triggered full overtime.

https://github.com/odoo/odoo/blob/b31fd6816521ff43fb3a9ec37e79e9a9d628d357/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L421-L433

**Solution:**
For flexible calendars in the overtime rule consumer:
- Quantity rules: read expected hours directly from the calendar's `hours_per_day` / `hours_per_week` instead of the synthetic schedule intervals, subtracting any leaves in the period
- Timing rules: treat the entire attendance date range (minus leaves) as potential work days, so that `non_work_days` is empty for flexible employees (they can work any day of the week)

opw-6067063

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

Forward-Port-Of: odoo/odoo#263840

# How to reproduce
- Go to the Form view of a model to which you can Add Properties
(e.g. Project > Tasks)
- Click on the gear icon > Add Properties
- Create a property field with :
	- Name : X
	- Field Type : Decimal
- Create two records for that model and set the value of the property to 1 & 2
- Go back and Add a custom filter with ('Properties.X', '=', 1)

# The problem
We see both records even tho we should only see one

# Cause of the issue
When doing the search, we transform the domain into the where clause of a
query. This transformation is done with the `condition_to_sql()`
function of the concerned field (`fields_properties` in our case):
https://github.com/odoo/odoo/blob/ba9e18688cc9c6e0d4da5ab60acf08d4c49b99d7/odoo/orm/fields_properties.py#L589

In this function, we manipulate a bit the condition depending on the value,
notably if the value is/contains True. To check it does, we do this :
https://github.com/odoo/odoo/blob/ba9e18688cc9c6e0d4da5ab60acf08d4c49b99d7/odoo/orm/fields_properties.py#L601

The issue is that in python, True in [1] and evaluates to True
because bool is a subset of int. This changes the condition and replaces it in
our case with ('Properties.X', '!=', 'False'), which is obviously not what
was initially asked for.

opw-6224811

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

Forward-Port-Of: odoo/odoo#266231
Forward-Port-Of: odoo/odoo#265835

### Issue before this commit:
Opening the Purchase Matching wizard would crash if the vendor bill contained lines with a description and a Unit of Measure (UoM), but no product selected.

### Steps to reproduce the issue:
1. Enable Units of Measure in Settings
2. Create and confirm a Vendor Bill setting a description and a UoM, but leave the Product field empty.
3. Click on "Purchase matching" smart button
4. The system throws a traceback with the error: "The unit of measure Unit defined on the order line doesn't belong to the same category as the unit of measure False defined on the product."

### Cause of the issue:
In the purchase.bill.line.match model, the field product_uom_qty was computed by calling _compute_quantity using line.product_uom_id. Since product_uom_id is a related field on product_id.uom_id, it returns False when no product is set. The UoM conversion logic cannot handle a False destination category, leading to the crash.

### Reason to introduce the fix:
Make purchase matching robust when imported vendor bills contain lines identified only by their description and not by a product. Note that for `purchase.bill.line.match` corresponding to an account.move.line but not related to any product, the `product_uom_qty` should match the quantity of the `aml_id` instead of attempting a UoM conversion based on a missing 
product UoM for the behavior to be consistent with the inverse method:

https://github.com/odoo/odoo/blob/59d6232979b8499fde6cb700df1870e2e38d0d3e/addons/purchase/models/purchase_bill_line_match.py#L45-L54

opw-5911526

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

Forward-Port-Of: odoo/odoo#266269
Forward-Port-Of: odoo/odoo#257827

Step to reproduce:
- install point_of_sale with demo
- have two company and 1 pos in each company
- install pos_hr
- install pos_sale

Observation:
- we get a traceback
```
File "/src/saas-19.2/odoo/orm/fields_misc.py", line 115, in __get__
    raise ValueError("Expected singleton: %s" % record) from None
ValueError: Expected singleton: res.company(7, 8)
 ```
- and pos_sale is not installed

Cause:
- when installing `pos_sale`  `_ensure_downpayment_product` is called.
- this sets downpayment product on every `pos.config` record.
- this triggers write call from pos_hr, which tries to identify users for pos
- this uses `with_company(self.company)`   <-----  actual issue
- here self has two config, each from different company, hence `with_company`
raises singleton error

why not in earlier verison:
- before commit [1] we only set downpayment product on only pos_config_main
- now we set it on every pos.config, so now self contain multiple records

[1] https://github.com/odoo/odoo/commit/a3f9114434c7cab8757b0283698662792e6b7946

Fix:
- compute users by first grouping them over company_id
related pr: https://github.com/odoo/odoo/pull/254026


opw-6217135

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

Issue:
----------------------------------------
The default values aren't kept when using the previous/next arrows in planning calendar view.

Steps to reproduce:
----------------------------------------
- Go on a Project task
- Click the "To Schedule" button
- Switch to calendar view
- If we create now, the new slot will have the task as default value
- Click the arrow to switch to next week
- If we create there will be no default values

Cause:
----------------------------------------
Since 7b844902e5c3a7aeedda6cc2be61366caad2d144 the context is lost when using the arrows.

When switching to calendar view `load()` is called with the context in the params:

https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/web/static/src/model/model.js#L163-L164

But when using the arrows, it is called with only a date:

https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/web/static/src/views/calendar/calendar_controller.js#L426

So `...params.context,` is empty, and the context is only `hide_planned_dates: true,`.

Solution:
----------------------------------------
If no context is specified in params, we use the one in `this.meta` to allow changing the context by giving it in the params but keeping the previous context when it's not given.

opw-6211055

Currently invoices generated from pos orders do not show the product referense alongside the product name.

Steps to reproduce:
-------------------
* Open shop and select Cabinet with doors
* Add customer to order
* Pay the order
* Wether you selected to invoice or you didn't, does not matter, you can invoice from the backend
> Observe on the invoice that the product does not show the internal reference "Cabinet with Doors"
* Create a sale order for the same product, deliver and invoice
> Observe the invoice, the product shows reference "[E-COM11] Cabinet with Doors"

Why the fix:
------------
After this commit: https://github.com/odoo/odoo/commit/aff477805577cb7ed00fb94440dda5cf2f29cb44
we're using `full_product_name` to set the name on move line name.

We could simply add the reference when computing the product name but the logiq used to computed the display name is a bit more complex than simply adding it always.

Instead we use both display_name and full_product_name to build the final name. This way it has the reference if any and all information about variants are kept as well.

opw-5950016

Forward-Port-Of: odoo/odoo#253540

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

**Problem:**
When the user has dark mode enabled and a sign template contains a Selection field, both the displayed value and the dropdown option list are unreadable: the selected value renders white-on-white in the field, and clicking the dropdown shows an empty-looking popup (white options on white system menu).

**Steps to reproduce:**
1. Enable dark mode in user preferences
2. Open Sign > Templates > duplicate any template
3. Add a Selection field with a few options (e.g. Low / Medium / High)
4. Save and Sign Now
5. Reach the Selection field and click it
6. Observe: the dropdown options are invisible (white on white) and, after picking one, the selected value in the field is also invisible

**Cause of the issue:**
The Selection sign item is rendered with a native `<select>` element inside the PDF.js iframe (`sign_items.xml`, `t-if="type == 'selection'"` branch). The iframe's stylesheet (`sign/static/src/css/iframe.css`) declares the `select` rule with `background: transparent` but no explicit `color`, and never styles `<option>` at all. When the OS or the user activates dark mode, the iframe document resolves to a `color-scheme: light dark` root, so the browser's UA stylesheet paints form controls with the dark palette (white text). The popup background stays white (`<option>` has no explicit background), so options render white-on-white. The same UA-white propagates to the displayed value of the `<select>` inside the pink-tinted sign item, which is also nearly white.

**Fix:**
Pinning the `<select>` text color and the `<option>` color/background to fixed light-mode values restores predictable contrast inside the iframe regardless of the surrounding color scheme. We deliberately do not rely on `color-scheme: dark` here — that would only swap which side of the contrast issue we land on (browsers don't reliably honor it for `<option>` background painting), and the sign item background (the pink dashed default style) is itself light, so dark option text on a white popup is the readable target in all themes.

opw-6197638

Forward-Port-Of: odoo/enterprise#117697

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

__

## Short functional explanation of the error
When we have a subscription product that has already been sold. If we try to import a product with the same ID but where we change the subscription type of the product, the import is executed without issue. However, this leads to undesired behavior:
when we go to the product page and try to manually change the subscription type (set it back to subscription), the change is not applied as a warning is raised.

## Reproduction Steps
Make sure you have debug mode enabled.
1. Create a product, and check the Subscription box.
2. Click on Orders and create a Quotation with this product, then confirm.
3. Go to Products > Products. Select the list view and search for the product you just created. Select it, and click Actions > Export.
4. Check the import compatible field. Select the fields to export: name, id and recurring_invoice. Upon exporting, a file is downloaded.
5. Access that file and change the recurring_invoice to FAUX or FALSE if your computer is in English. Save the changes.
6. Unselect the product and click on the cog, top right > Import. Click on Upload Data File and select the file that you have downloaded upon exporting, then import.

### Expected behavior
A user warning is raised: we shouldn't be able to change the subscription type of the product when it has already been sold.

### Unexpected behavior
The import is processed normally. Then, when we access the product page, and try to check the Subscriptions box again, a warning is raised.

## Origin of the issue
Nothing prevents the import from occurring in that case.

__
opw-6143789

Forward-Port-Of: odoo/enterprise#117318
Forward-Port-Of: odoo/enterprise#115046

**Description of the issue/feature this PR addresses:**
This PR fixes an "Invalid Operation" UserError during the Bill Matching process. The error occurs when Odoo attempts to call the line addition method on a Posted Vendor Bill, even when there are no new residual lines to add. This triggers a write attempt on read-only fields (such as invoice_line_ids) of a validated account move, which is prohibited by Odoo’s ORM.

Furthermore, this addresses a functional inconsistency: Odoo allows users to select "Posted" bills in the matching view, but the underlying code is not prepared to handle a "zero residual" scenario on a validated move. If Odoo intends to prevent matching on posted bills, they should be filtered out from the view; since they are available to select, the system must be able to process them when no further modifications to the accounting entries are required.

**Current behavior before PR:**
When performing a match between a posted Vendor Bill and Purchase Order lines where the "residual" (lines left to add) is zero:

The system executes _add_purchase_order_lines() regardless of whether the recordset of lines is empty.
Odoo's ORM detects an update attempt on a posted record.
A UserError is raised: "You cannot modify the following readonly fields on a posted move: invoice_line_ids".
This blocks the user from completing the matching process even if the lines are already technically accounted for.

**Desired behavior after PR is merged:**
The system will check if residual_purchase_order_lines contains any records before attempting to update the bill.
If there are no lines to add, the method call is skipped.
The matching process completes successfully without attempting an illegal write on a posted move.

**Steps to Reproduce**
1) Create a Purchase Order (PO): Add a product (e.g., "Acoustic Bloc Screens") and confirm the order.
2) Create a Vendor Bill manually: Do not use the "Create Bill" button from the PO. Instead, go to Accounting -> Vendors -> Bills and create a new bill for the same vendor and product.
3) Post the Bill: Set a bill date and click Confirm to move it to the "Posted" state.
4) Open Bill Matching: Go back to the Purchase Order and click the Bill Matching button (or navigate to the matching view).
5) Select Lines: Select the PO line and the corresponding Bill line (which are already equal in quantity/price).
6) Trigger the Match: Click on the Match button.

Observe Error: An "Invalid Operation" popup appears, preventing the link because Odoo tries to "add" zero lines to a posted invoice.


**Video:**
https://drive.google.com/file/d/12aeZIx1JRRSKA9TaWfXy0TeSOgMUMQcg/view
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#241171

Steps to reproduce:
- Install `Accounting` module
- Search `Analytic Report` > Click on `Total` > `Custom Group`
- Select `Journal Item` > Now again close and select `Journal Item`

Traceback:
```js
TypeError: Cannot destructure property 'fieldName' of 'searchItems.find(...)' as it is undefined.
    at AnalyticPivotRenderer.onGroupBySelected (http://localhost:8069/web/assets/3b7bf10/web.assets_backend_lazy_dark.min.js:434:7)
    at Object.onSelected (eval at compile (http://localhost:8069/web/assets/b0799bf/web.assets_web.min.js:1376:421), <anonymous>:78:62)
    at DropdownItem.onClick (http://localhost:8069/web/assets/b0799bf/web.assets_web.min.js:2373:24)
 ```

Cause:
Custom groupBys were not being added to the search items list in `onGroupBySelected`, causing a lookup failure when selecting a custom groupBy from the dropdown.

Solution:
Added custom groupBys to the search items list so they can be found and applied correctly.

opw-6227164

Forward-Port-Of: odoo/odoo#265810

### Steps to reproduce:

- In the settings enable dropshipping
- Create a storable product P, enable the dropshipping and set a vendor
- Create and confirm a sale order for a field service
- Open the related task > Products > Add 1 unit of P
- Go back to the sale order > an RFQ has been created
#### > The delivered quantity of P is set to 1

### Cause of the issue:

Since 2361368acfe7fecbffde2ca26392eb89aecdc9e1 the `_inverse_fsm_quantity` method manually adapts the delivered quantity based on the fact that the `product.service_type` is `manual` rather than the `qty_delivered_method` of the line or future line is. In particular, because these lines: https://github.com/odoo/enterprise/blob/8f4fe902cb71c49bdb3caf9915f9a5abfe6f237f/industry_fsm_sale/models/product_product.py#L82-L83
provide a value of the `qty_delivered` to the created purchase order line and since the `qty_delivered_method` is a precomputed field: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L225-L237
The fact that the purchase order line will be created with a `stock_move` `qty_delivered_method` and that the generated PO does not generate any move prior to confirmation will not trigger the dependency of the `qty_delivered` to retrigger a computation of the `delivered_qty` of the product which is suppose to be based on stock pickings: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L871-L876 https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale_stock/models/sale_order_line.py#L193-L198
Leaving the created sol with a delivered quantity of 1 prior to confirmation of the PO (which will generate move_ids related to the sol and trigger the compute).

Fix:

The changes of 2361368acfe7fecbffde2ca26392eb89aecdc9e1 regarding the `_inverse_fsm_quantity` appears unjustified with respect to the purpose of the fix. In addition, the `qty_delivered` and changes are already expected to be properly computed when the `qty_delivered_method` is not manual, particularly since the '`manual'` `service_type` is actually the default `service_type` corresponding to any 'consu' product and looks unrelated by any mean to the `delivered_qty` computation: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/product_template.py#L165-L167

opw-6104326

Forward-Port-Of: odoo/enterprise#117727
Forward-Port-Of: odoo/enterprise#115760

**Steps to reproduce**
1. Create a customer invoice with Invoice Date `2025-05-27` and accounting Date `2026-05-04`.
2. On the *Other Info* tab, set the Delivery Date to `2026-05-04` and post the invoice.
3. Generate the FA(3) XML.

**Issue**
`P_6` is omitted from the payload even though the delivery date differs from the invoice issue date.

The FA(3) information sheet (Warsaw, September 2025, binding from 1 February 2026) defines `P_6` as *"the date of delivery [...] if such date is specified and differs from the date of issue of the invoice"*, where the date of issue is `P_1` (Art. 106e sec. 1 item 1 of the VAT Act). In Odoo `P_1` maps to `invoice_date`, but the template at
https://github.com/odoo/odoo/blob/4890b8021af2a5c025944220043d295bb7bbbb9b/addons/l10n_pl_edi/data/fa3_template.xml#L132 compares `delivery_date` against `invoice.date`, the accounting/entry date. When the invoice is posted on the delivery day the accounting date equals the delivery date, the guard evaluates to false, and `P_6` is wrongly dropped.

Comparing against `invoice.invoice_date` aligns the guard with `P_1` as the spec requires.

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

Forward-Port-Of: odoo/odoo#266667

### Issue:
When creating a company with CUIT 30999003156, any child contact added under it is incorrectly considered as a company

### Cause:
In `l10n_ar`, `_compute_is_company()` relies on:
`l10n_ar_afip_code` and the prefix of `l10n_ar_vat`

However, these fields are propagated to child contacts
As a result, child contacts inherit the same values as the parent company and are incorrectly computed with `is_company = True`

### Note:
This same fix also fix the issue on `l10n_latam_base` and `l10n_co`

### Steps to reproduce:
- Install `l10n_ar` and switch to an AR Company
- Create a Partner in Contacts (Name: Test Company, Country: Argentina, Identification Number: CUIT 30999003156)
- Add a Contact (Name: Test Contact)
- Go in Contacts and add a Filter for Name: Test

### Before the fix:
The Contacts are: Test Company and Test Contact

### After the fix:
The Contacts are: Test Company and Test Company, Test Contact

opw-6140921

Forward-Port-Of: odoo/odoo#263503

### Issue:
When a Sale Order is delivered but later reimbursed (e.g., via a credit note without a return), it is still considered as to invoice
As a result, it continues to impact the partner’s credit limit

### Cause:
Sale Orders remain included in the `credit_to_invoice` computation even when invoicing is manually considered finished
There was no way to exclude such orders from the credit limit calculation

### Fix:
Use the `invoicing_closed` field to mark Sale Orders as fully processed
When set, the order is excluded from the credit limit computation

### Steps to reproduce:
- Install `sale_management`
- In Settings, enable Sales Credit Limit (default: 3000)
- Create, confirm, and deliver a Sale Order for a new customer (any product, price: 2000)
- Duplicate the Sale Order → a credit warning is displayed
- Go back to the original Sale Order and use Close Invoicing from the gear menu
- Return to the duplicated Sale Order
The warning disappears as the closed order is no longer included in the credit computation

### Note:
For a complete business scenario, refer to the steps described in the related ticket

opw-6013369

Forward-Port-Of: odoo/odoo#262720

Description of the issue/feature this PR addresses:

Prevent an internal server error when a customer cancels a Redsys payment
and returns to Odoo.

Current behavior before PR:

When the customer cancels the payment from the Redsys checkout page,
Redsys redirects back to Odoo without the `Ds_MerchantParameters`
parameter.

The payment flow assumes the parameter is always present and tries to
decode it unconditionally, causing an internal server error.

Desired behavior after PR is merged:

Odoo gracefully handles payment cancellations when
`Ds_MerchantParameters` is missing from the callback parameters.

The customer is redirected correctly without triggering a server error.

Steps to reproduce:

1. Install the Redsys payment provider.
2. Configure a test environment.
3. Create a sales order or invoice.
4. Start the payment process.
5. Cancel the payment from the Redsys checkout page.
6. Return to Odoo.
7. Observe the internal server error caused by the missing
   `Ds_MerchantParameters` parameter.


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

Forward-Port-Of: odoo/odoo#265655

### Issue
In the Italian annual tax report, both VL3/VL4 and VL32/VL33 values could be displayed at the same time

However, according to the report logic, only the positive balance should be shown for each pair:
- VL3 (Tax Due) or VL4 (Tax Credit)
- VL32 (Tax Due) or VL33 (Tax Credit)

The other one should stay 0
If the global balance is null, both can be 0

### Cause
The lines VL3, VL4, VL32, and VL33 were using the shortcut field `aggregation_formula` directly on the `account.report.line` record
This shortcut format does not evaluate or support conditional subformulas like `if_above(EUR(0))`
As a result, the report computed and displayed both lines of each pair without filtering out the negative or unwanted values

### Steps to reproduce
- Install `l10n_it` and `accountant` and switch to IT Company
- Create a balanced Journal Entry for any account
- Add the Tax Grid v20 on one of the lines to impact the annual report
- Open the `Annual Tax Report (IT)` 
- Go to the `VL` section
- Check the value of VL3/VL4 and VL32/VL33
After the fix, only one value can be positive and the other 0

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

Forward-Port-Of: odoo/odoo#264294

Problem: When both line discounts and global discounts are applied on a product in an invoice, the method `_add_and_round_raw_gross_total_excluded_and_discount` does not return the exact raw_gross_total_excluded before the modification done by other AccountTax helper methods, such as dispatching and squashing global discount lines.

Current Behavior: The calculation is done in the wrong order of operations. For example, there is an invoice for Product A valued at $100 with a discount of 10% and a global discount of $10. The raw_total_excluded will be $80 after the both discounts. The discount_factor is based on only the line discount of 10%. The formula of the current calculation for raw_gross_total_excluded is: (raw_total_excluded / (1 - (line_discount / 100))) - global_discount = (80 / 0.90) - (-10)
= 98.889
This does not equal the expected outcome of $100.

Expected Behavior: Based on the previous example, the formula for the calculation should be:
(raw_total_excluded - global_discount) / (1 - (line_discount/100)) = (80 - (-10)) / 0.9
= 100
The global discount needs to be added back to the raw_total_excluded to get the line discounted amount in order to divide by the discount_factor to gain the expected raw_gross_total_excluded before taxes and discounts.

Steps to reproduce the issue:
- Bug was encountered when implementing a global discount solution for l10n_co_dian.
- Create an invoice with a product line and in-line discount and another line for global discount
- Setup the base lines for the invoice and attempt the following:
 - _dispatch_global_discount_lines
 - _squash_global_discount_lines
 - _add_and_round_raw_gross_total_excluded_and_discount

opw-5412446


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

Forward-Port-Of: odoo/odoo#266584
Forward-Port-Of: odoo/odoo#262137