#### [IMP] account_peppol,l10n_fr_pdp: rework PDP registration
If PDP is not installed but Peppol is installed we suggest
installing the PDP module for French companies
- in the send & print instead of the following warnings
  - "You can send this invoice electronically via Peppol." (what is peppol)
  - "partner has requested electronic invoices reception on Peppol."
- in the send & print for any French company that is not on PDP
  (this warning can be disabled by setting the system parameter
   `account_peppol.disable_pdp_warning` to true)
- in the peppol registration wizard by adding a warning

If PDP is installed we make the following changes to the send & print
- change the wording mentioning "Peppol" to mention the French e-invoicing instead
- make a PDP version of the "Peppol Info" (`account_peppol.WhatIsPeppol`)
  - it explains what French E-Invoicing is
  - it provides a button to open the registration wizard
  - in case the company is registered on Peppol it deregisters the
    company first (just like the "complete registration" button)
- display the "You can send this electronically via Peppol" warning
  also for French companies (with the wording and "Peppol Info" mentioned above)
  - It is displayed in case we are opening the Send & Print wizard from a French
    company for a partner on peppol but the "Peppol" / "French
    E-invoicing" checkbox is not checked
- Change the wording of the French company non-PDP warning to encourage
  the user to register

In the PDP registration wizard
- make all the fields visible directly (already at the start of the KYB/KYC)
- make the SIREN part of the identifier readonly
- make the fields readonly after the verification
- automatically "validate" / register to PDP when we receive the KYC success

task-6320246

#### [IMP] l10n_fr_pdp: add system param for kyc siren
After the previous commit it is not really possible anymore
to use a different SIREN for the KYC than the one in the pdp identifier.
This is because:
- We derive the SIREN directly from the
Identifier in the registration wizard.
- The registration will be validated automatically after the KYC
- The values are readonly after the KYC in any case

That is a problem for testing because we have 1 SIREN to test the
KYC and it is independent from the identifiers provided by the French
datasets for the PDP test environment.

task-None

Forward-Port-Of: odoo/odoo#271733

### Issue:
Importing a UBL invoice containing a line with `LineExtensionAmount=0`, `InvoicedQuantity=0` and a non-zero `PriceAmount` failed with a `ZeroDivisionError`, reported in the chatter as an import error

Such lines are valid UBL but carry no meaningful value, so they are silently skipped after the fix

### Cause:
After this commit: https://github.com/odoo/odoo/commit/a7f77f3cfc42764328e7da73a60df8d4cafc968f
The `line_extension_amount` was able to go in new parts of the code with a 0.0 value
When `line_extension_amount` is set and `invoiced_quantity` is 0, `quantity` is computed as `subtotal * price_quantity / (...)` which resolves to 0 since `subtotal` is also 0
`price_unit = subtotal / quantity` then divides by zero

### Steps to reproduce:
- Install `l10n_be`
- Import a UBL invoice with a line where `LineExtensionAmount=0`, `InvoicedQuantity=0` and `PriceAmount` is non-zero (You can use the xml on the ticket)

Before the fix, the import failed with an error in the chatter

opw-6234453

Forward-Port-Of: odoo/odoo#271001

When opening Studio → Contacts → Accounting Tab, Owl raises the following error:

```py
Odoo Client Error

Occured on 114697239-saas-19-2-all.runbot254.odoo.com on 2026-06-19 07:01:00 GMT

UncaughtPromiseError > OwlError
Uncaught Promise > Invalid props for component 'BankTag': 'onDelete' is undefined (should be a value)
OwlError: Invalid props for component 'BankTag': 'onDelete' is undefined (should be a value)
    Error: Invalid props for component 'BankTag': 'onDelete' is undefined (should be a value)
        at Object.validateProps (https://114697239-saas-19-2-all.runbot254.odoo.com/web/assets/5482857/web.assets_web.min.js:1001:67)
        at FieldMany2ManyTagsBanks.slot1 (eval at compile (https://114697239-saas-19-2-all.runbot254.odoo.com/web/assets/5482857/web.assets_web.min.js:1387:421), <anonymous>:16:13)
        at callSlot (https://114697239-saas-19-2-all.runbot254.odoo.com/web/assets/5482857/web.assets_web.min.js:968:25)
        at TagsList.template (eval at compile (https://114697239-saas-19-2-all.runbot254.odoo.com/web/assets/5482857/web.assets_web.min.js:1387:421), <anonymous>:22:30)
        at Fiber._render (https://114697239-saas-19-2-all.runbot254.odoo.com/web/assets/5482857/web.assets_web.min.js:797:96)
        at Fiber.render (https://114697239-saas-19-2-all.runbot254.odoo.com/web/assets/5482857/web.assets_web.min.js:796:6)
        at ComponentNode.initiateRender (https://114697239-saas-19-2-all.runbot254.odoo.com/web/assets/5482857/web.assets_web.min.js:867:47)
```
Note: The error only occurs when the contact has at least one bank accounts (bank_ids) in the Accounting tab.

`FieldMany2ManyTagsBanks` inherits from `Many2ManyTagsField`, whose `getTagProps()` [method](https://github.com/odoo/odoo/blob/saas-19.2/addons/web/static/src/views/fields/many2many_tags/many2many_tags_field.js#L165-L173) intentionally sets `onDelete` to [undefined](https://github.com/odoo/odoo/blob/saas-19.2/addons/web/static/src/views/fields/many2many_tags/many2many_tags_field.js#L168) when the field is rendered in readonly mode.

However, `BankTag` declares `onDelete` as a required [prop](https://github.com/odoo/odoo/blob/saas-19.2/addons/account/static/src/components/many2many_tags_banks/many2many_tags_banks.js#L18). Since Studio renders the field as readonly, `onDelete` is undefined, causing Owl prop validation to fail.

Make `onDelete` optional in `BankTag` to match the behavior of the parent widget and the underlying `BadgeTag` component, which already defines `onDelete` as [optional](https://github.com/odoo/odoo/blob/saas-19.2/addons/web/static/src/core/tags_list/badge_tag.js#L12).

This fixes the Owl error when opening the Accounting tab in Studio.

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

**Steps to reproduce:**
- Install the `accountant` module and log in as admin.
- Create and confirm a vendor bill.
- Send an image in the chatter of the vendor bill.
- Open a new tab and log in as a demo user.
- Open the same vendor bill.
- Click the gear icon.

**Observation:**
An access error is raised, and the gear icon is not accessible.

**Root Cause:**
At [1], the method `_should_attach_to_record` incorrectly excludes
image attachments, causing them to be treated as `extra_files_data`
at [2]. As a result, in `_fix_attachments_on_record_from_files_data` at [3],
these attachments are assigned `res_model=False` and `res_id=0`. When the
code tries to access these attachments at [4], it leads to an access error.
Additionally, when we try to print `Original Bills`, we get the same access 
error at [5], and later the code calls the `browse` function on 
`self.env[attachment.res_model]`, but for `extra_files_data` we set the 
`res_model=False`, which results in a `KeyError`(see [6]).

**Fix:**
This commit prevents the error and ensures that users can access
the gear icon when an image is attached in the chatter and 
print the `Original Bills`.

[1]:
https://github.com/odoo/odoo/blob/95864190a71b68eb10ae59ae8f38ac35b0cb6a97/addons/account/models/account_document_import_mixin.py#L416-L429

[2]:
https://github.com/odoo/odoo/blob/95864190a71b68eb10ae59ae8f38ac35b0cb6a97/addons/account/models/account_move.py#L6668-L6672

[3]:
https://github.com/odoo/odoo/blob/95864190a71b68eb10ae59ae8f38ac35b0cb6a97/addons/account/models/account_document_import_mixin.py#L409-L414

[4]:
https://github.com/odoo/odoo/blob/7e874e7db30e05a02d6eeb26d9d67ed6176b9704/addons/account/models/account_move.py#L6944-L6949

[5]:
https://github.com/odoo/odoo/blob/7e874e7db30e05a02d6eeb26d9d67ed6176b9704/addons/account/models/ir_actions_report.py#L30-L34

[6]:
https://github.com/odoo/odoo/pull/261463#issuecomment-4602692978

opw-6119155

Forward-Port-Of: odoo/odoo#261463

**Steps to reproduce:**
* Install the **l10n_in_reports** module.
* Go to **Accounting → Configuration → Settings**, and enable **Multi-Currencies**.
* Activate a foreign currency (e.g., USD) and set an exchange rate.
* Create a new vendor bill for an Indian vendor, setting the currency to USD.
* Add lines to the bill and apply IGST/GST taxes, then confirm the bill.
* Go to **Accounting → Reporting → GST Return Period** and initiate GSTR-2B matching for the period corresponding to the bill (using a valid JSON payload where the amounts are correctly reported in INR).

**Observed behavior:**
* The vendor bill is incorrectly marked as "Partially matched" instead of "Fully matched", accompanied by an exception stating that the total amount as per GSTR-2B does not match.

**Cause:**
* The GSTR-2B data fetched from the GST portal always reports values in the company's base currency (INR).
* The `match_bills` method was directly comparing the GSTR-2B INR amounts ( `bill_total` and `bill_taxable_value`) against the bill's `amount_total` and `amount_untaxed` fields.
* Because these fields return values in the document's foreign currency (e.g., USD), the mismatch triggers an exception and flags the bill as partially matched.

**Fix:**
* Modified the matching logic to compare GSTR-2B values against `abs(amount_total_signed)` and `abs(amount_untaxed_signed)`.
* This ensures that the amounts evaluated during reconciliation are always correctly converted and compared in the company's base currency (INR).

opw-6311097

Forward-Port-Of: odoo/enterprise#121677
Forward-Port-Of: odoo/enterprise#120967

[[FIX] mrp: calculate real duration excluding non-productive intervals](https://github.com/odoo/odoo/pull/248381/changes/fac6b2540a32a015f56085c2c27ba4281eb659cf)
and deduplicating overlaps

* Current Situation: Currently real duration is total duration of each
time tracking which
is not consistent with the time that use to calculate the cost for
valuation , see https://github.com/odoo/odoo/pull/205154 .The real
duration of a work order was incorrectly summing all time tracking
entries regardless of their loss type, and using simple addition which
double-counts overlapping intervals.

* Solution:
- Filter time entries to only 'productive' and 'performance' loss types,
  excluding 'availability' and 'quality' as they represent
downtime/blocking
  time, not actual work duration.
- Pool all productive and performance entries into a single Intervals
call
  so that overlaps across both types are merged in one pass.

Note: the enterprise17 implementation groups time entries by loss_type
into
separate buckets before calling Intervals, which means overlaps between
'productive' and 'performance' entries are not merged and get
double-counted.
Pooling both types together before the Intervals call avoids this.

* This also fix:
- Fix _set_duration to ensure newly created time entries start after the
  latest existing entry's end date. Without this, calling _set_duration
  twice in quick succession (e.g. in tests) produces two entries with
  overlapping timestamps, which Intervals correctly merges into one,
  causing the computed duration to be half the expected value.




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

Forward-Port-Of: odoo/odoo#248381

The tag remapping was running in pre-migrate, before the module's data files are loaded. This caused the tag swap to be silently skipped for any new tag that didn't exist yet, and the subsequent cleanup to fail with a FK violation on account_account_account_tag.
```py
 File "/home/odoo/src/odoo/saas-19.2/odoo/sql_db.py", line 417, in execute
    self._obj.execute(query, params)
psycopg2.errors.ForeignKeyViolation: update or delete on table "account_account_tag" violates foreign key constraint "account_account_account_tag_account_account_tag_id_fkey" on table "account_account_account_tag"
DETAIL:  Key (id)=(356) is still referenced from table "account_account_account_tag".
```

Moving to post-migrate ensures all new account tags are present in the database before the remapping and cleanup run.

upg-[4341331]

[4341331]: https://upgrade.odoo.com/odoo/upgrade.request/4341331?debug=1


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

Forward-Port-Of: odoo/odoo#269809

### Issue
`l10n_es_edi_verifactu` builds an inheritance on `certificate.certificate` and loads that module's views/demo, but only declares `depends: ['l10n_es']`. With `certificate` not guaranteed to load first, building the registry without it already present raises:

```
TypeError: Model 'certificate.certificate' does not exist in registry.
```

### Cause
`models/certificate.py` → `_inherit = 'certificate.certificate'`; manifest `data` loads `views/certificate_certificate_views.xml` and `demo/demo_certificate.xml`. Yet `certificate` is absent from `depends`. Every sibling (`l10n_es_edi_facturae`/`sii`/`tbai`, `l10n_sa_edi`) already depends on `certificate`. Present since the module was added in `02f8d5525eb7`.

### Notes
- Opened on **18.0** so it **forward-ports to 19.0** (both stable branches carry the bug). `master` already has the equivalent change via #234729 — the forward-port there should be a no-op.
- Surfaced via an 18.0→19.0 OpenUpgrade migration that force-updates `verifactu` before `certificate` loads; also reproducible on a plain install where `certificate` isn't otherwise pulled in first.

Forward-Port-Of: odoo/odoo#271827
Forward-Port-Of: odoo/odoo#271496

The Time Off Balance report shows incorrect remaining days when overlapping allocations exist and a leave only overlaps the later one.

### **Steps to reproduce:**
1) Install time off app.
2) Create a simple time off type.
- Create Allocation A (10 days, 01-01-2024 to 31-12-2025)
- Create Allocation B (10 days, 01-01-2025 to 31-12-2026) 
3) Create a leave of 1 day on 01-01-2026
4) Open the Balance report

### **Observed Behavior:**
The report shows 20 remaining days.

### **Expected Behavior:**
The report should show 19 remaining days (20 allocated - 1 taken).

### **Cause:**
In the taken_per_allocation CTE at [1], each leave is joined to every allocation it overlaps. The [fifo_balances] CTE then uses the formula:
```
GREATEST(alloc_days - GREATEST(taken - prior_cumulative_alloc, 0), 0)
```
This subtracts the prior allocation capacity (A = 10 days) from the taken count (B = 1 day). Since 1 - 10 = -9, GREATEST(-9, 0) = 0, so zero days are deducted from B. The formula wrongly assumes that prior allocations can absorb leaves that do not overlap with them.

[1]- https://github.com/odoo/odoo/blob/f0fa79fa21d2005dd5cd132c18b2be45424166a6/addons/hr_holidays/report/hr_leave_employee_type_report.py#L126-L142

[fifo_balances]: https://github.com/odoo/odoo/blob/f0fa79fa21d2005dd5cd132c18b2be45424166a6/addons/hr_holidays/report/hr_leave_employee_type_report.py#L145-L164

### **Fix:**
Ensure that leaves are only deducted from allocations they actually
overlap by calculating the balance using the delta of cumulative leaves
within an overlap group. This prevents earlier allocations from absorbing
leaves that occur outside their validity period.

**opw-6150161**

Forward-Port-Of: odoo/odoo#271596
Forward-Port-Of: odoo/odoo#263029

Steps to reproduce:
===================
1. Install website_customer, set a Google Maps API key and publish a few companies with coordinates
2. Open /customers
3. Open the map and zoom in a few times

=> stale blue cluster bubbles remain on the map

Cause:
======
On the partner map, zooming or panning left old cluster bubbles behind: the blue count icons piled up and never disappeared, even at the closest zoom level.

`ClusterIcon` is meant to be a google.maps.OverlayView. The bundled `markerclusterer.js` wires that up by copying every enumerable https://github.com/odoo/odoo/blob/aed1619c34b1f65bd9a3d155fe76a82d404ef5e7/addons/website_google_map/static/src/lib/markerclusterer.js#L213-L221 OverlayView.prototype member onto ClusterIcon.prototype. Google Maps now ships its own OverlayView.prototype.remove, and that copy overwrites ClusterIcon's own `remove()` with it, As a result, when a cluster icon is removed, `ClusterIcon.remove()` is never executed. Consequently, `ClusterIcon.prototype.onRemove()` is not triggered, the cluster icon's DOM element is never detached from the map,
https://github.com/odoo/odoo/blob/aed1619c34b1f65bd9a3d155fe76a82d404ef5e7/addons/website_google_map/static/src/lib/markerclusterer.js#L1167 and stale cluster bubbles accumulate after every redraw, zoom, or pan operation.

Solution:
=========
Inherit from OverlayView through the prototype chain instead of copying it, so ClusterIcon's own remove() is kept and actually detaches the icon.

opw-6128531

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

Forward-Port-Of: odoo/odoo#270733

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
- Inventory > Configuration > Warehouse Management > Routes
- Unarchive MTO
- Create a storable product P with MTO buy and a set vendor
- Create and confirm a sale order for 1 unit of P
- Confirm the assocaited PO and change the pol quantity from 1 to 10
> the associated receipt is updated from 1 to 10
- Change the pol quantity from 10 to 7
#### > The quantity on the receipt is updated from 10 to 16.

### Cause of the issue:

Changing the quantity of the POL will adapt the picking related quantity via these lines:
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L115-L117 https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L342-L349 by creating new stock moves to be merged:
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L220-L251 Now, the issue is that this flows relies both on a negative `qty_to_attach` of `1 - 10 = -9` and a positive `qty_to_push` of `7 - 1 = 6`. However, the `qty_to_attach` is only used if is positive: https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L243-L251 The receipt is therefore updated by a `+6` move to push but not by the `-9` move to attach. Leading to a 10 -> 16 rather than 10 -> 7 result.

opw-6218307

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

Forward-Port-Of: odoo/odoo#270547
Forward-Port-Of: odoo/odoo#264994

Steps to reproduce:
-------------------
- Create a Purchase Order with an expected Arrival date in the past
- Confirm the Purchase Order
- Validate the receipt partially and create a backorder
- Cancel the generated backorder
- Open the Purchase Orders list and check the 'Late Receipts'

Issue:
------
The Purchase Order still appears in the 'Late Receipts' filter even
though there is no remaining receipt to process.

Cause:
------
The 'Late Receipts' filter relies on the computed search field
`is_late`:
https://github.com/odoo/odoo/blob/324df67c099ab18c6fe7c8f77212cf809debf383/addons/purchase/views/purchase_views.xml#L439

The search domain for this field is generated by
`purchase.order._search_is_late()`:
https://github.com/odoo/odoo/blob/324df67c099ab18c6fe7c8f77212cf809debf383/addons/purchase/models/purchase_order.py#L176

In `purchase_stock`, `_get_domain_is_late()` extends the base domain to
identify Purchase Orders that still have receipts pending:
https://github.com/odoo/odoo/blob/324df67c099ab18c6fe7c8f77212cf809debf383/addons/purchase_stock/models/purchase_order.py#L264-L267

After a partial receipt:
- the original receipt is in state `done`,
- a backorder is created and linked to the Purchase Order,
- the backorder is later cancelled and moves to state `cancel`,
- the Purchase Order line still has `qty_received < product_qty`.

The existing domain excludes only `done` pickings when determining
whether a receipt is still pending. As a result, a cancelled backorder
is still treated as an unfinished receipt, causing the Purchase Order
to remain visible in the 'Late Receipts' filter.

Fix:
----
Exclude both `done` and `cancel` pickings when determining whether a
Purchase Order has pending receipts.

A cancelled backorder indicates that the remaining quantity will not be
received through that transfer. Therefore, once all related pickings are
either completed or cancelled, the Purchase Order should no longer be
considered late.

---
opw-6266046

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

Forward-Port-Of: odoo/odoo#268488

Module: l10n_it_pos

Steps to reproduce:
- In the POS settings, enable "Automatic Receipt Printing";
- Enable "ePos Printer" to make the "Skip Preview Screen" option appear;
- Disable "Skip Preview Screen";
- Disable "ePos Printer";
- Set up an Italian Fiscal Printer;
- Open a POS session and process a first order.

Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required.

Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required.

Cause:
When "Automatic Receipt Printing" is true but "Skip Preview Screen" is false, a race condition occurs. `afterOrderValidation` triggers a print job while simultaneously transitioning to the `ReceiptScreen`. When the `ReceiptScreen` mounts, it triggers a second fiscal print job before the first has resolved. This creates a deadlock in `toHtml` of  `renderService`, permanently blocking the printer queue.

Solution:
Since the italian localisation sending the receipt to the fiscal printer is mandatory, the printing route is now tied to the "Skip Preview Screen" option.

Enterprise PR: https://github.com/odoo/enterprise/pull/112654

[opw-5979212](https://www.odoo.com/odoo/project/49/tasks/5979212)

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

Forward-Port-Of: odoo/odoo#271191
Forward-Port-Of: odoo/odoo#256932

Module: l10n_it_pos

Steps to reproduce:
- In the POS settings, enable "Automatic Receipt Printing";
- Enable "ePos Printer" to make the "Skip Preview Screen" option appear;
- Disable "Skip Preview Screen";
- Disable "ePos Printer";
- Set up an Italian Fiscal Printer;
- Open a POS session and process a first order.

Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required.

Cause:
When "Automatic Receipt Printing" is true but "Skip Preview Screen" is false, a race condition occurs. `afterOrderValidation` triggers a print job while simultaneously transitioning to the `ReceiptScreen`. When the `ReceiptScreen` mounts, it triggers a second fiscal print job before the first has resolved. This creates a deadlock in `toHtml` of  `renderService`, permanently blocking the printer queue.

Solution:
Since the italian localisation sending the receipt to the fiscal printer is mandatory, the printing route is now tied to the "Skip Preview Screen" option.
UI settings are adjusted to hide the redundant auto-print checkbox when an IT fiscal printer is configured.

Community PR: https://github.com/odoo/odoo/pull/256932

[opw-5979212](https://www.odoo.com/odoo/project/49/tasks/5979212)

Forward-Port-Of: odoo/enterprise#121257
Forward-Port-Of: odoo/enterprise#112654

Steps to reproduce:
------------------------
1. Install Helpdesk
2. Go to All Tickets and check the kanban state selection value
3. Go to Settings > Field Selection and search for kanban_state in `helpdesk.ticket` model
4. Change one of the state selection values (e.g., "Ready" to "Testing Ready")
5. Go back and check the state selection value in list and form views

Current behavior:
-----------------------
Kanban view correctly shows the updated label (e.g., "Testing Ready"),
but list and form views still display the old default value (e.g., "Ready").

Root cause:
---------------
The [state_selection](https://github.com/odoo/odoo/blob/c09cefdb0ed68b1b7367b77b18a5ee5d66c94900/addons/web/static/src/views/fields/state_selection/state_selection_field.js#L57-L65) widget uses `legend_${state}` field values when available.
Since list and form views included these legend fields, the widget resolved labels from them
instead of the actual selection values, causing inconsistent display.

Fix:
-----
Remove `legend_normal`, `legend_blocked`, and `legend_done` fields from the list and form views,
So the widget falls back to the real selection labels, consistent with how the kanban view behaves.

Reference commit: https://github.com/odoo/enterprise/commit/65f3b88254e3a66e2c5dcb5142d30f6b1996d999

opw-6238765

Forward-Port-Of: odoo/enterprise#119707