Original commit message:

Bank journal can have the same bank account number, to be able to have a difference between them.
We will add an extension number field on the journal that will be displayed only when having a synchronization with codabox or codaclean. This extension number can be found in the CODA file when the second line of the coda start with '12', which means that we have a belgian iban. With that we are able to know the journal to where we want to import the statement.

task-5254158

Backport commit message:

This commit backports the code to handle extension number in stable. Some adaptations were done
to allow this backport.
1. We have a new module for the new field and the view.
2. Except that, the code stays in the existing modules with a condition that check if the extension number is present in the journal's field list. NB: This implementation is pretty bad but the existing code doesn't include hooks to extend to add customization. To avoid a whole refactoring in stable, this approach was chosen.
3. A test and a test file from the codabox module are deleted because we don't want to create a new module for tests only.

task-6116452

Forward-Port-Of: odoo/enterprise#113699

Starting version 2.1.4 of markupsafe, they decided to adapt the `striptags` function to use in-python-loops instead of the original implemenation that relied on pre-compiled regex.

A problem has been spotted with qweb templates that used `striptags` with large inputs, which led to the investigation of this function and it was found that the old implementation is actually faster. In fact, the PR introducing this change in Markupsafe, made these claims with no benchmarks whatsoever: https://github.com/pallets/markupsafe/pull/413/changes 

The new implementation of markupsafe is O(N x M), where n is the number of tags and M being the length of the input string. The old regex approach does a single c-level scan to check the existence of the regex which is performing much better for varying input size.

The benchmark cases below are in the form `<case_description>_<number_of_tags>`. We can see that in the cases where the current implementation is slightly faster is when there are no tags in the input which can be explained by the fact that the while loops will simply exit early. The time lost in the regex implementation is likely due to the deeper call stack to scan for the regex. Apart from that, in the case of an unclosed tag, the regex implementation is also slower because it still needs to scan the entire line. However, in that case the time taken is a handful of milliseconds, so it's not really a performance regression there either.

Apart from that, the old implementation is consistently much more performant, for both small and large inputs.

Benchmarks:

| Case                                      | Regex ms | Current ms | Speedup |
|----------------------------------------------|----------|------------|---------|
| plain_text_50k_words                         | 3.020    | 2.627      | 0.9x ← current_implementation |
| unclosed_tag_then_50kb_text                  | 0.367    | 0.032      | 0.1x ← current_implementation |
| unclosed_tag_then_500kb_text                 | 3.787    | 0.273      | 0.1x ← current_implementation |
| multiple_unclosed_open_tags_then_50kb_text   | 18.912   | 0.371      | 0.0x ← current_implementation |
| multiple_unclosed_open_tags_then_500kb_text  | 189.007  | 8.209      | 0.0x ← current_implementation |
| unclosed_comment_then_500kb_text             | 7.276    | 0.412      | 0.1x ← current_implementation |
| 5k_small_tags                                | 0.986    | 22.096     | 22.4x ← regex_old_implementation |
| 20k_small_tags                               | 4.125    | 492.186    | 119.3x ← regex_old_implementation |
| 50k_small_tags                               | 12.658   | 5499.602   | 434.5x ← regex_old_implementation |
| 1k_nested_divs                               | 0.155    | 0.923      | 5.9x ← regex_old_implementation |
| 10k_nested_divs                              | 1.648    | 48.410     | 29.4x ← regex_old_implementation |
| 2k_tags_with_attrs                           | 1.058    | 12.013     | 11.4x ← regex_old_implementation |
| 20k_tags_with_attrs                          | 13.185   | 6068.755   | 460.3x ← regex_old_implementation |
| 2k_multiline_tags                            | 0.815    | 10.819     | 13.3x ← regex_old_implementation |
| 20k_multiline_tags                           | 8.939    | 4231.768   | 473.4x ← regex_old_implementation |
| 1k_comments                                  | 0.222    | 1.292      | 5.8x ← regex_old_implementation |
| 1k_comments_hiding_tags                      | 0.163    | 1.121      | 6.9x ← regex_old_implementation |
| 2k_mixed                                     | 0.278    | 2.392      | 8.6x ← regex_old_implementation |
| 10k_mixed                                    | 1.400    | 50.959     | 36.4x ← regex_old_implementation |
| qweb_shop_200_products                       | 0.907    | 7.880      | 8.7x ← regex_old_implementation |
| qweb_shop_1000_products                      | 4.296    | 194.647    | 45.3x ← regex_old_implementation |


This PR is needed because requirements.txt in Odoo specifies the following dependency:
`MarkupSafe==2.1.5 ; python_version >= '3.12' \# (Noble)`

This means that all versions running Ubuntu Noble, will be having the same issue introduced in version 2.1.4 of markupsafe.

opw-5999688

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

Forward-Port-Of: odoo/odoo#268580
Forward-Port-Of: odoo/odoo#257889

#### [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

Overview
------

When having a favorite mailing (template) for target model X, and another one for target model Y, and try to create a new mailing for target model X, the theme selector will first show the template X with the correct title and preview, however when switching to model Y, the theme selector will show the title of the tempalte Y but the preview is always the one of template X.

How to reproduce
------

1. Create a new mailing for a target model X (e.g. `mailing.contact`)
2. Set a content for that mailing (you can choose from the existing themes)
3. Set that mailing as a favorite (using the favorite star button)
4. Create a new mailing for another target model Y.
5. Redo steps 2. and 3.
6. Create a new mailing, and set the target model to X (You should see the mailing X in the theme selector with the correct title and preview)
7. Change the target model to Y.

Expected Behavior
------

Both the title and the preview of the mailing X in the theme selector should change into the title and the preivew of mailing Y.

Current Behavior
------

The title of the template is changed into the one of Y however the preview remains the one of mailing X.

Cause of The Issue
------

After the first mount of the `FavoritePreivew` component, when the template changes in the props, the body content of the preivew is not updated with the new value.

Task-6332946



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

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

Currently, flexible employees can request a multi-day leave spanning a public holiday when the leave type includes public holidays in duration. However, requesting the public holiday date alone is rejected.

### **Steps to reproduce:**
- Create a public holiday.
- Create a time off type with "Public Holiday Included" enabled.
- Select/create an employee with a flexible work schedule and its time zone must be same as admin.
- Request a time off on the public holiday date only.

### **Observed Behavior:**
The request is rejected because its duration is computed as 0 days.

### **Expected Behavior:**
The request should be allowed and count as 1 day, consistent with the multi-day request behavior.

### **Root Cause:**
At [1], a dedicated duration computation path is used for single-day leaves of flexible employees. This logic always retrieves overlapping public holidays and computes the leave duration based on the remaining intervals. As a result, a leave requested entirely on a public holiday is computed as 0 days, even when `include_public_holidays_in_duration` is enabled.

[1]- https://github.com/odoo/odoo/blob/242f6d3cf7288853f163ac6986a3b7aa4279efaf/addons/hr_holidays/models/hr_leave.py#L436-L444

### **Fix:**
This commit ensures that the `include_public_holidays_in_duration` setting is taken into account when computing single-day leave durations for flexible employees

**opw-6284768**

Forward-Port-Of: odoo/odoo#271594
Forward-Port-Of: odoo/odoo#269743

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

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

*: website, website_mass_mailing

__Problem__
In some cases, popup snippets can be dropped inside another popup.
This shouldn't be possible. Moreover, it produces the following error:
`TypeError: Cannot read properties of undefined (reading 'after')`.

This can happen in multiple scenarios:
- After saving a custom snippet, the snippets are reloaded but
  `disableUndroppableSnippets` is not called again, although the
  snippets should be filtered again.
- `NewsletterPopupPlugin` registers `.o_newsletter_popup` in the
  `so_snippet_addition_selector` resource, bypassing the more
  restrictive `dropzone_selector` of `PopupOptionPlugin`.
- Popups are not disabled when the cookie bar is open because we don't
  take `excludeAncestor` into account in `DisableSnippetsPlugin`.

__Fix__
- Trigger an event whenever the snippets are loaded and call
  `disableUndroppableSnippets` when it is.
- Remove the redundant `NewsletterPopupPlugin`.
- Filter `dropAreaEls` with `excludeAncestor` in `DisableSnippetsPlugin`.

Forward-Port-Of: odoo/odoo#269864

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

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

When transferring an order to a table that already has an open order, identical products are merged into a single line. If both orders were already sent to the kitchen printer, the merged line was incorrectly marked as new and had to be sent again.

Steps to reproduce:
-------------------
* Open table 1, add product A (2 units) and product B, send to kitchen
* Open table 2, add product A (3 units) and product C, send to kitchen
* On table 2, transfer/merge the order to table 1

> Observation:
product A shows 2 units as new and must be sent to the kitchen printer again, although all quantities were already sent.

Why the fix:
------------
When merging preparation history for identical lines, handlePreparationHistory overwrote the destination sent quantity with the source one instead of summing both. The kitchen diff then treated the missing quantity as new changes.

A unit test will be added in 18.3.

opw-6246470

Forward-Port-Of: odoo/odoo#271392
Forward-Port-Of: odoo/odoo#267915

Description of the issue/feature this PR addresses:

`Registry.check_indexes` derives a column index's name as `<table>__<column>_index`, which does **not** encode the access method, and only creates the index when no index of that name already exists. It never inspects the access method of an existing index.

As a consequence, changing a field's `index=` kind on an **already-indexed** column is silently ignored on existing databases. For example `account.move.name` was changed from a plain btree index to `index='trigram'`:

```python
name = fields.Char(
    ...
    index='trigram',
)
```
On a fresh database this creates the expected GIN/trigram index. On any database that already had the btree index, the old btree index keeps its name, so `check_indexes` finds the name present and does nothing. The `(=)ilike` searches the trigram index was meant to accelerate keep falling back to sequential scans, with no error or warning.

Current behavior before PR:

### Steps to reproduce

1. Install a module on an existing DB while a `Char` field is `index=True` (btree).
2. Change the field to `index='trigram'` and upgrade the module.
3. `\d <table>` in psql — the index is still `USING btree`, not `USING gin`.

Desired behavior after PR is merged:

`check_indexes` now also reads each existing index's access method (`pg_am.amname`). When the method no longer matches what the field expects (`gin` for trigram, `btree` otherwise), the stale index is dropped and recreated. The drop is issued inside the **same savepoint** as the recreate, so a failed rebuild (e.g. a lock timeout) rolls the drop back and never leaves the column without an index.

Scope: only the access method is reconciled. A change that alters solely the partial predicate (`btree` -> `btree_not_null`) keeps the same method and is intentionally left untouched.

### Notes

- This extends the existing index-management logic in place and keeps the current "keep unexpected index" behaviour for fields that dropped `index=` entirely; only fields that still want an index, of a different method, are rebuilt.
- Trigram rebuilds still require the `pg_trgm` extension; without it the GIN index is skipped exactly as before (`self.has_trigram` guard).


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

Forward-Port-Of: odoo/odoo#271891
Forward-Port-Of: odoo/odoo#268505

When a stock move's UoM differs from the product template's UoM, the report aggregation incorrectly shows data for both UoMs of stock move.quantity on the same graph. All moves should be normalized to the UoM of the product for which we are viewing the forecast.

We can do this with:

`m.quantity * move_uom.factor / pt_uom.factor AS quantity`

If the UoMs of the stock move and the product template are identical, as is the case most of the time, this simply multiplies by one, and the query behaves exactly as it did before. But if the units are distinct, the move UoM is converted into
the product template UoM so that the data for stock move quantity is normalized to one shared unit across the entire forecast graph.

**E.g.**:

m.quantity == 500g
m.UoM == g
m.UoM.factor == 1
pt.UoM == kg
pt.UoM.factor == 1000

500g * 1 / 1000 ==> .5kg

**Steps to Reproduce on Runbot**:
1. Create a product which uses kg and g. 
2. Confirm and Validate a receipt for this product (10 kg for example). 
3. Confirm a second receipt for this product in the same UoM kg. 
4. Confirm and Validate a delivery for this product with UoM g (500 g for example).
5. View the forecasted graph for the product, and you will see that the y axis is scaled on grams ~500, and the current / future stock moves in the report are still scaled based on kg. 

opw-6234066

Forward-Port-Of: odoo/odoo#266811

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

Issue:
Sending Debit Notes to a tax authority can cause the following error: "ValueError: The following child node is not defined in the template: DebitNote/cbc:BuyerReference"

Steps to reproduce on any database with DIAN and Colombian localization:

  1. Create a new "Sales" type journal. Then, check the checkbox “Nota de Debito”.
  2. Find a res.partner with a ref field, or add a ref field to any partner.
  3. Make an invoice using the partner found in step 2. Ensure it uses a tax. Confirm it.
  4. Send that invoice to DIAN.
  5. Create a Debit Note for that invoice. Use the journal created in step 1.
  6. Add a product, price, and tax to the debit note. Confirm it.
  7. Send the debit note to DIAN.
  
Explanation:
The `_add_invoice_header_nodes` method on the AccountEdiXmlUbl_21 model adds a BuyerReference node unconditionally. (See account_edi_xml_ubl_21.py.) But the DebitNote XML template does not include a BuyerReference element (see ubl_21_debit_note.py). This caused a ValueError when assembling the XML for debit note documents.

Solution: The fix overrides this in the Colombian localization by clearing the BuyerReference value when the document type is "debit_note". That way, the node is omitted from the output.

opw-6181039

Forward-Port-Of: odoo/enterprise#121422

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

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

1. The `m160` and `m161` mutations for `sign_copy_sale` test didn't set the `l10n_be_short_signature` field on the order, so the `TicketScreen.print` override would fail the check and the `blackbox.signCopy` would not be called, causing the test to fail.
2. The `l10n_be_pos_blackbox_urban_piper` tests would crash on `undefined id` on the prep display path of `pos_enterprise`, where the data service will try to load up the prep display data, but it's not loaded in the test bundle. So I created a special setupEnv method for blackbox with urban piper which unpatches the prep display (same mechanism as pos_enterprise)
3. After removing the path for the tests, they would fail for the `expectGeneralProperties` step. By default it expects the `ticketMedium` to be `PAPER`, but there is no printer configured on the tests, so the actual medium is `DIGITAL`.
4. The tests expect the cost center to be `PLATFORM`. There was a patch on `InputGenerator`, which would return platform if the order has a `delivery_provider_id` set. But the patch never fired. I moved the patch directly on the order model, which is where the cost center value is computed.
5. The `test_l10n_be_pos_blackbox_sign_sale_backend_offline` test would endTour prematurely before the orders finished syncing, then check that all the orders are synced. I added an extra isSynced() step to ensure the orders are synced before ending the tour

Task-[6320705](https://www.odoo.com/odoo/1737/tasks/6320705)

Forward-Port-Of: odoo/enterprise#121455

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