### 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#266899
Forward-Port-Of: odoo/odoo#257827

### Description of the issue/feature this PR addresses: 
**Issue:** A recent update to support `certificateFingerprint` introduced a regression for existing users authenticating with standard certificates (AKA `certificateSubject`). Because the matching logic strictly checked for the company NIP within the certificate subject, it failed for users using personal PESEL certificates to act on a company's behalf. 

**Previous PR:** https://github.com/odoo/odoo/pull/264851 

**Solution:** Expanded the string-matching heuristic in the XML signer to strip formatting characters from the NIP and explicitly checks for standard Polish qualified certificate prefixes (VATPL and PNOPL) to accurately get the identifier type.

### Current behavior before PR: 
When a user logs in via a personal PESEL certificate for a company context, the NIP check fails and miscategorizes the payload as a `certificateFingerprint`. KSeF rejects this mismatch, causing a 400 error for previously working setups.

### Desired behavior after PR is merged: 
The authentication flow distinguishes between `certificateSubject` and `certificateFingerprint` by checking for valid Polish prefixes or exact cleaned NIP matches. Existing customers are restored to working order natively, and new customers using manual fingerprints are still supported without requiring any database or UI changes.

opw-6251153

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

Forward-Port-Of: odoo/odoo#267060

The Inventory Valuation report at a past date rebuilds historical value by tracing stock moves. Two product.value lookups run on the hot path and both hit unindexed columns:

- stock.move._get_manual_value() searches product.value by move_id for every traced move;
- product.product._get_last_product_value() searches product.value by product_id.

product.value declares neither column with an index, so each lookup performs a sequential scan of the whole table. This is harmless on small tables but degrades sharply as product.value grows (one row is written per manual standard-price/move revaluation).

On a database where product.value held ~9.6M rows, the per-move move_id lookup seq-scans the entire table only to return nothing (no row carries a move_id), repeated for every traced move, so the historical report never completes.

Index product_id (dense) and move_id (btree_not_null, since it is null for every manual revaluation row). Each lookup then becomes an index scan.

Measured on a ~9.6M-row product.value, historical valuation report, single date:

| product.value lookup        | without index             | with index         |
| --------------------------- | ------------------------- | ------------------ |
| by product_id (DISTINCT ON) | ~0.56s (1.7 GB seq scan)  | index scan         |
| by move_id, per traced move | full seq scan, returns 0  | index scan         |
| report (~3.1M moves traced) | never completes (>20 min) | completes (~3 min) |

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

Forward-Port-Of: odoo/odoo#266790

Issue before this PR:-
========================
Currently, the total remaining time in the MO kanban header is computed by directly summing the `remaining_time` of all manufacturing orders in the column. This also includes overtime (negative remaining time), which incorrectly reduces the actual remaining workload.

Steps to reproduce:
========================
1) Install the `mrp_workorder` module.
2) Create 2 MOs with a work order.
3) Start the work order and wait until the real duration exceeds the expected duration (`real duration > expected duration`).
4) Pause the work order and open the MO kanban view.
5) Observe that the negative remaining time is shown in the column header.

Cause of the issue:
========================
The `groupAggregate` method in the `MrpProductionKanbanHeader` component directly sums all `remaining_time` values, including negative ones. Since negative values represent overtime that has already been consumed, they should not reduce the future workload displayed in the kanban header.

After this PR:
========================
This PR updates the method to treat negative remaining time as `0` when computing the total remaining time, ensuring that the kanban header correctly reflects the remaining future workload.

TaskId:- 6226535

__

## Short functional explanation of the error
When confirming a Purchase Order holding lines with an analytic distribution that has been manually added, and creating a vendor bill out of this PO using the Auto-Complete field. When we change the account of that line, the line loses the manually added Analytic Distribution.

## Reproduction Steps
1. Go to Accounting. Click on the tab Configuration; under the Analytic Accounting section, click on Analytic Distribution Models.
2. Create an Analytic Distribution Model for a product.
3. Go to Purchase. Create a new PO, set a Vendor and select the product you created the Analytic Distribution Model for. On the right side of the form, click on the view menu and check Analytic Distribution to make it appear.
4. Click on the Analytic Distribution of the product and add a new one; for example, select Administrative in the Departments section.
5. Confirm order.
6. Go to Accounting and click on the Vendors tab > Bills. Create a new bill, and in the field Auto-Complete, select the PO you just created.
7. Change the account of the line.

### Expected behavior
Only the account should be changed on the line.

### Unexpected behavior
The manually added Analytic Distribution has disappeared.

## Origin of the issue
When we change the `account_id` field, the compute method `_compute_analytic_distribution` is triggered. This method retrieves the related distributions of the line:
https://github.com/odoo/odoo/blob/af32885ec5f07d492f3b8e8fff1785996a739f72/addons/account/models/account_move_line.py#L1154 which, in the context of Purchase, calls this method: https://github.com/odoo/odoo/blob/af32885ec5f07d492f3b8e8fff1785996a739f72/addons/purchase/models/account_invoice.py#L540-L545 We retrieve the distribution of the related line using `self.purchase_line_id.analytic_distribution`. However, this code isn't triggered when the move line has an analytic distribution, even though the related line `purchase_line_id` might have one! Therefore, we need to execute that code whether or not our move line has an analytic distribution.
Note: the same behavior is to avoid when creating invoices for
quotations.
__
opw-6062466

Forward-Port-Of: odoo/odoo#267274
Forward-Port-Of: odoo/odoo#258380

Currently, an error occurs when a user opens a payslip.

**Steps to Reproduce:**
 - Install the `documents_hr_payroll` module.
 - Go to `Payroll` > `Payslips` > `Payslips` and open an `existing payslip` or `create a new one`.
 - Add `two or more attachments` to the payslip.
 - Go to `Documents` and, in the left panel, navigate to `Company` > `Employees - YourCompany` > 
   `Payroll YourCompany`, then `Move to Trash` all documents related to those `payslip attachments`.
 - Go back to `Payslips` and open the `same payslip` again.

`ValueError: Expected singleton: hr.payslip(4, 4)`

With [this commit], the attachment's "Add to Document" action allows creating a Document from a 
mail.thread record attachment. When the user deletes the documents related to the attachments and 
then opens the payslip again, the compute method runs to calculate the linked document ID for the 
payslip attachments and tries to retrieve attachments without documents [1].
The issue occurs when two or more attachments share the same payslip ID. While mapping the res_id 
of the attachments and grouping them by ID, the same payslip record is included multiple times for a 
single key [2] [3], which raises error here [4].

This commit ensures that the mapped res_id values are wrapped in a set, so duplicate IDs are removed 
and each payslip ID appears only once.

[this commit]: https://github.com/odoo/enterprise/commit/5fa4b74a2345ddd4858585c5e9a780d1ca5add57

[1]- https://github.com/odoo/enterprise/blob/21477b333f7a33cb582cd806236e4f9f8346d022/documents/models/ir_attachment.py#L26

[2]- https://github.com/odoo/enterprise/blob/21477b333f7a33cb582cd806236e4f9f8346d022/documents/models/ir_attachment.py#L45

[3]- https://github.com/odoo/enterprise/blob/21477b333f7a33cb582cd806236e4f9f8346d022/documents/models/ir_attachment.py#L48

[4]- https://github.com/odoo/enterprise/blob/21477b333f7a33cb582cd806236e4f9f8346d022/documents_hr_payroll/models/hr_payslip.py#L74-L76

sentry-7494229711

### Description of the issue/feature this PR addresses:
This PR introduces batch processing to the VAT Books ES (Libros de IVA) report generation. When attempting to export the report for periods containing a massive volume of invoices, the ORM cache continuously accumulates records, leading to severe memory consumption. By implementing batching and explicitly clearing the environment cache, use memory use will remain stable and efficient.

### Current behavior before PR:
Generating the VAT Books report loads all account move lines into memory at once. Because the ORM cache is never cleared during the iteration, RAM usage spikes continuously. On databases with tens or hundreds of thousands of invoices in a single period, this leads to significant performance degradation, worker timeouts, or complete Out-Of-Memory (OOM) crashes.

### Desired behavior after PR is merged:
The report engine now splits the recordset into manageable batches (e.g., 50,000 accounts per batch). After processing each chunk to extract the income and expense line values, invalidate_model() is called to flush the ORM cache related to the searched records. This frees up memory continuously, keeping the server's RAM usage flat and allowing the successful export of massive datasets without crashing.

### Benchmark:
The model is iterating through ~1.1M account move lines when generating the full report. 

For Memory:
| # Input Data | Before PR | After PR|
| -------- | -------- | -------- |
| ~77,000 account move lines | 385 MB | 666 MB |
| ~340,000 account move lines |1.2 GB | 1.5 GB |
| ~1.2M account move lines | MemoryError | 1.5 GB |

For Speed:
| # Input Data | Before PR | After PR|
| -------- | -------- | -------- |
| ~77,000 account move lines | 32s | 12s |
| ~340,000 account move lines | 2:29min | 1:11min |
| ~1.2M account move lines | MemoryError | 4:11min |

### Reference

opw-6037414

-----------------------------------------------------------------
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Forward-Port-Of: odoo/enterprise#116139

## Steps to Reproduce:
1. Install the Accounting module.
2. Go to Accounting > Reporting > Executive Summary.
3. Activate debug mode.
4. Click on the gear icon at the top.
5. In the "Options" tab, disable the "Date Range".
6. Open the report again.

## Error:
`TypeError - unsupported operand type(s) for -: 'datetime.date' and 'NoneType'`

## Cause:
At [1], when the "Date range" option is disabled in the summary report, `date_from` becomes None. The NDays expression still computes `date_to - date_from` at [2], which raises a TypeError because subtraction between a datetime and NoneType is not supported.

## Fix:
This commit takes the fiscal-year's start date, when the date-range feature is disabled.

[1] - https://github.com/odoo/enterprise/blob/a9cadd93b849375edfcc7fd04612d9eb8787043b/account_reports/models/account_report.py#L564-L570
[2] - https://github.com/odoo/enterprise/blob/a9cadd93b849375edfcc7fd04612d9eb8787043b/account_reports/models/executive_summary_report.py#L15-L16

sentry-7455506965

The Inventory Valuation report at a past date rebuilds historical value by tracing stock moves. Two product.value lookups run on the hot path and both hit unindexed columns:

- stock.move._get_manual_value() searches product.value by move_id for every traced move;
- product.product._get_last_product_value() searches product.value by product_id.

product.value declares neither column with an index, so each lookup performs a sequential scan of the whole table. This is harmless on small tables but degrades sharply as product.value grows (one row is written per manual standard-price/move revaluation).

On a database where product.value held ~9.6M rows, the per-move move_id lookup seq-scans the entire table only to return nothing (no row carries a move_id), repeated for every traced move, so the historical report never completes.

Index product_id (dense) and move_id (btree_not_null, since it is null for every manual revaluation row). Each lookup then becomes an index scan.

Measured on a ~9.6M-row product.value, historical valuation report, single date:

| product.value lookup        | without index             | with index         |
| --------------------------- | ------------------------- | ------------------ |
| by product_id (DISTINCT ON) | ~0.56s (1.7 GB seq scan)  | index scan         |
| by move_id, per traced move | full seq scan, returns 0  | index scan         |
| report (~3.1M moves traced) | never completes (>20 min) | completes (~3 min) |

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

Forward-Port-Of: odoo/odoo#266790

When a sale order containing a product with a custom (free text) attribute was settled in POS, the order line displayed the placeholder attribute value name (e.g. "Custom") instead of the actual text entered by the customer.

Steps to reproduce:
-------------------
* Create a product with a free text attribute (create_variant='no_variant', is_custom=True)
* Go to the website's shop (works best in a new private tab)
* Fill the free text attribute and add the product to the cart
* Click on checkout
* In POS, open Quotation/Order and settle the order

> Observation:
the order line shows "Custom" instead of the text

Why the fix:
------------
`SaleOrderLine._load_pos_data_fields` was not exposing `product_no_variant_attribute_value_ids` nor `product_custom_attribute_value_ids`, so the JS `settleSO` function received no attribute data on the `line` object. As a result, the new POS order line was created with empty `attribute_value_ids` and `custom_attribute_value_ids`, leaving `constructFullProductName` unable to find the custom text.

The fix adds both fields to `_load_pos_data_fields` and updates `settleSO` to use them when building the new POS order line. The dynamic fetch path (`_getSaleOrder`) is also updated to explicitly read the `product.attribute.custom.value` records so the data is available for orders loaded at runtime.

opw-5958678

Forward-Port-Of: odoo/odoo#266875
Forward-Port-Of: odoo/odoo#251993

Step to reproduce:
- install "pos_settle_due"
- create a pos order, set order price = 0, select a customer
- go to payment page, select "customer account" as payment method
- here you can set any amount to pay, ex 100$
- fulfill the  order.

Observation:
- the order amount is 0, if we pay 100$ using customer account, it is considered as change (which means we returned it to customer)
- As per PO, this flow doesn't make sense

Issue:
- customer has 100$ due for this order, but he won't be able to settle this as fetch order to settle with amount != 0, after commit [1] 
- [1] https://github.com/odoo/enterprise/commit/12af23d5382e972facfaa999e4c5ab30c97e8d1f

https://github.com/odoo/enterprise/blob/951e5f42884c898bc14d9c32ae6a8f08c31ff06d/pos_settle_due/static/src/app/screens/partner_list/partner_line/partner_line.js#L35

Fix:
- we hide payment method of type "pay_later" in case of 0 price order

opw-6123699

Forward-Port-Of: odoo/enterprise#118296
Forward-Port-Of: odoo/enterprise#116556

Steps to reproduce:
1- Install the Attendance app
2- Enable PIN Identification in setting
3- Go to Admin user (who is also an employee) and remove their admin access on the Employees field and save.

Issue:
`AccessError: You do not have enough rights to access the field "pin" on Employee (hr.employee).`

Expected behavior:
User can change their access rights without getting AccessError

Why this happens:
The addition of the Employee PIN to the Preferences tab in v19.0 (commit edc6562) causes this error. During web_save, a read is triggered for all fields in the view. Since the user just removed their own HR rights, they no longer have access to the PIN field. While the PIN was moved in v19.1 (commit a2e785b), it remains in v19.0.

Fix:
- Removing the field from the xml file was not enough as it introduced another error: 
- `AccessError: You do not have enough rights to access the field "version_id" on Employee (hr.employee).`
- Commit 5024fc7 changes field `work_location_id` to be editable. This field is related to an `hr.employee` field which depends on `version_id`. Saving now causes this field to be read through this chain, which causes an an implicit access.
- Set `related_sudo=True` to allow the user to read their own employee data during the save

Note:
This `version_id` error doesn't exist from v19.1 upwards due to the refactor made in commit 96050453.

opw-6112646

Forward-Port-Of: odoo/odoo#262053

Issue
-----
Traceback when trying to get a rate through the e-commerce if the order has to be split into multiple packages due to weight being too high.

Steps to reproduce
-----
- Setup Sendcloud delivery method
	- make it available in e-commerce
- Create a 150kg product and publish it
- Go to e-commerce
	- Add the product to cart
	- Checkout the cart

> Traceback

Cause
-----
We retrieve the order's weight through the context.

https://github.com/odoo/enterprise/blob/d9a9339e1f30f1e5cc37ebb88949451a6652f83b/delivery_sendcloud/models/delivery_carrier.py#L108

If the call to `_get_shipping_rate` returns that the delivery requires multiple packages, we go into

https://github.com/odoo/enterprise/blob/d9a9339e1f30f1e5cc37ebb88949451a6652f83b/delivery_sendcloud/models/delivery_carrier.py#L126-L128

If `order_weight` was not present in the context, this will cause an error in `sendcloud_convert_weight` since it expects a numerical value but receives the `None` fallback. This context key is only present when going through `choose.delivery.carrier` (so not in the e-commerce flow).

https://github.com/odoo/odoo/blob/058e640e6687ed3f709dc846f0fa7a1f45226849/addons/delivery/wizard/choose_delivery_carrier.py#L69

-----
Ticket:
opw-6210398

Forward-Port-Of: odoo/enterprise#117028

When creating a calendar event by dragging on the calendar view, modifying the end time in the quick-create popover, and then clicking "More Options", the duration shown in the full form is the original drag value instead of the value implied by the user's updated stop.

calendar's makeContextDefaults seeds default_start, default_stop, default_duration, and default_allday from the drag extent. In the quick-create popover, changing stop triggers _compute_duration on that record so its duration becomes correct. On "More Options", goToFullEvent extracts a whitelist of fields from the quick-create record as default_X and merges them with the original drag context.

https://github.com/odoo/odoo/blob/c82341c503ac/addons/calendar/static/src/views/calendar_form/calendar_quick_create.js#L9-L19

duration is missing from that whitelist, so the merged context still carries the stale default_duration from the drag. In the full form, that default is applied to the duration field and _compute_duration does not run because a default was provided for a stored, writable field.

Adding duration to the whitelist forwards the quick-create's recomputed value as default_duration so the full form opens with the correct duration.

Steps to reproduce:
1. Open Calendar, drag to create a 2-hour event (e.g. 10:00-12:00)
2. In the quick-create popover, change the end time to 14:00
3. Click "More Options"
4. Check the Duration field in the full form

=> Duration shows the original drag value (02:00) instead of 04:00

opw-6087449

Forward-Port-Of: odoo/odoo#257294

Issue:
----------------------------------------
When searching for a field from `hr.version` without any rights on Employees, we get an access error.

Steps to reproduce:
----------------------------------------
- Timesheet > To Validate > All timesheet
- Filter on Employee > Department (is set for example)
- An error pops up

Cause:
----------------------------------------
The field `department_id` of `hr.employee` belongs to `hr.version` and is accessible through the `_inherits` and the field `version_id`. When doing the search above, during the optimization of the domain, we end up trying to read `department_id` on `hr.employee.version_id`. But the field `hr.employee.version_id` is not accessible to users without Employee access rights. They only have rights on the field  `hr.employee.current_version_id`.

This occurs from version saas-19.1 because the access check was added in this version. ([commit](https://github.com/odoo/odoo/commit/aa58663a271e24a1fcb3f59e6bddfac50054703c))

Solution:
----------------------------------------
We remove the group restriction on `version_id`. The group restrictions are done with the fields of `hr.version`. As `version_id` is only a computed field from `current_version_id` which has `bypass_search_access=True`, this should not expose any field that wasn't already. `bypass_search_access=True` was added on `current_version_id` for the same reason. ([src](https://github.com/odoo/odoo/commit/94bb4a29189400d6bd0c2ca97eba271601262e1b))

opw-6149198 
opw-6251866

The Inventory Valuation report at a past date rebuilds historical value by tracing stock moves. Two product.value lookups run on the hot path and both hit unindexed columns:

- stock.move._get_manual_value() searches product.value by move_id for every traced move;
- product.product._get_last_product_value() searches product.value by product_id.

product.value declares neither column with an index, so each lookup performs a sequential scan of the whole table. This is harmless on small tables but degrades sharply as product.value grows (one row is written per manual standard-price/move revaluation).

On a database where product.value held ~9.6M rows, the per-move move_id lookup seq-scans the entire table only to return nothing (no row carries a move_id), repeated for every traced move, so the historical report never completes.

Index product_id (dense) and move_id (btree_not_null, since it is null for every manual revaluation row). Each lookup then becomes an index scan.

Measured on a ~9.6M-row product.value, historical valuation report, single date:

| product.value lookup        | without index             | with index         |
| --------------------------- | ------------------------- | ------------------ |
| by product_id (DISTINCT ON) | ~0.56s (1.7 GB seq scan)  | index scan         |
| by move_id, per traced move | full seq scan, returns 0  | index scan         |
| report (~3.1M moves traced) | never completes (>20 min) | completes (~3 min) |

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

Forward-Port-Of: odoo/odoo#266790

Importing attendees on an event that has an `after_sub` mail scheduler (the default on every event) fails with `savepoint "..." does not exist` and the import is aborted.

[`_update_mail_schedulers`](https://github.com/odoo/odoo/blob/b2f3270271f6/addons/event/models/event_registration.py#L298) runs the attendee scheduler synchronously on every registration create. The scheduler commits after each mail batch, which is fine from cron but problematic during an import: since [29460b723f49](https://github.com/odoo/odoo/commit/29460b723f49) [`load`](https://github.com/odoo/odoo/blob/b2f3270271f6/odoo/orm/models.py#L884) uses a single savepoint for the whole run, and any commit underneath releases it, so the next `ROLLBACK TO` / `RELEASE SAVEPOINT` raises `InvalidSavepointSpecification`.

When `import_file` is in context, trigger the cron like the async path already does so the mails are queued instead of running inline.

Steps to reproduce:

0. Have Contacts and Events installed
1. Events > Events, create a published event
2. Open the event, Attendees tab > Favorites > Import records
3. Upload a file with new attendees (Name, Email, no external id)
4. Click Import

=> "savepoint ... does not exist", import fails

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

Forward-Port-Of: odoo/odoo#260648

Step to reproduce:
- install "pos_settle_due"
- create a pos order, set order price = 0, select a customer
- go to payment page, select "customer account" as payment method
- here you can set any amount to pay, ex 100$
- fulfill the  order.

Observation:
- the order amount is 0, if we pay 100$ using customer account, it is considered as change (which means we returned it to customer)
- As per PO, this flow doesn't make sense

Issue:
- customer has 100$ due for this order, but he won't be able to settle this as fetch order to settle with amount != 0, after commit [1] 
- [1] https://github.com/odoo/enterprise/commit/12af23d5382e972facfaa999e4c5ab30c97e8d1f

https://github.com/odoo/enterprise/blob/951e5f42884c898bc14d9c32ae6a8f08c31ff06d/pos_settle_due/static/src/app/screens/partner_list/partner_line/partner_line.js#L35

Fix:
- we hide payment method of type "pay_later" in case of 0 price order

opw-6123699

Forward-Port-Of: odoo/enterprise#118093
Forward-Port-Of: odoo/enterprise#116556

When a mass mailing block uses a `bg-o-color-N` theme color class, the mailing's `body_arch` stores the class and `convert_inline` correctly inlines the resolved color into `body_html`, matching the website palette at save time. The class also stays on the element in `body_html`. The stylesheet rule that gives `bg-o-color-N` its color is declared with `!important`. When the website palette is later rebuilt (any change to the primary colors), the new `bg-o-color-N` rule wins over the inline color whenever `body_html` is rendered. So an already-sent mailing reopened in the backend shows the new palette's color instead of the one that was picked, and resaving the mailing bakes that new color into `body_html`.

`classToStyle` already does the right thing for the property value. What was missing is dropping the class itself from `body_html` once its style has been inlined, so no future `!important` palette rule can override the inline color. `body_arch` keeps the class, so the editor preview stays theme-aware while editing, but `body_html` is now stable across palette rebuilds.

Steps to reproduce:
1. Open Email Marketing and create a new mailing using the Welcome Message template
2. Select a content block, open Customize, set the background to the 5th theme color
3. Save the mailing
4. Open the Website editor and change the 5th primary color to a different value
5. Reopen the saved mailing in the backend

=> the block's rendered background follows the new website color instead of the one picked at design time

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

Forward-Port-Of: odoo/odoo#253934

**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a `GT Company`.
- Navigate to Invoicing > Vendors > Bills.
- Create a new vendor bill.
- Observe that `GT Document Type` includes `NABN - Nota de Pago Electrónica` option.
- `Confirm` the bill.
- Click `Credit Note`, add a reason, and click `Reverse`.
- Observe the available options in the `GT Document Type` field.

**Observation:**
The `NABN - Nota de Pago Electrónica` option is not available for 
vendor credit notes (`in_refund`), even though `NABN` is a GT-specific 
credit note document type.

**Root Cause:**
At [1], `NABN` is added for vendor bills (`in_invoice`, `in_receipt`) 
instead of vendor credit notes (`in_refund`).

**Fix:**
This commit ensures users can correctly select `NABN - Nota de Pago Electrónica` 
on GT vendor credit notes.

[1]:
https://github.com/odoo/enterprise/blob/c7fa8c9c6f6830f5702fab4f6efaf3ac33f7fe72/l10n_gt_edi/models/account_move.py#L159-L160

opw-6252256

Forward-Port-Of: odoo/enterprise#118711

**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a `GT Company`.
- Navigate to Invoicing > Vendors > Bills.
- Create a new vendor bill.
- Observe that `GT Document Type` includes `NABN - Nota de Pago Electrónica` option.
- `Confirm` the bill.
- Click `Credit Note`, add a reason, and click `Reverse`.
- Observe the available options in the `GT Document Type` field.

**Observation:**
The `NABN - Nota de Pago Electrónica` option is not available for 
vendor credit notes (`in_refund`), even though `NABN` is a GT-specific 
credit note document type.

**Root Cause:**
At [1], `NABN` is added for vendor bills (`in_invoice`, `in_receipt`) 
instead of vendor credit notes (`in_refund`).

**Fix:**
This commit ensures users can correctly select `NABN - Nota de Pago Electrónica` 
on GT vendor credit notes.

[1]:
https://github.com/odoo/enterprise/blob/c7fa8c9c6f6830f5702fab4f6efaf3ac33f7fe72/l10n_gt_edi/models/account_move.py#L159-L160

opw-6252256

Forward-Port-Of: odoo/enterprise#118711

**Problem:**
A combo product's parent line appears in the "Invoiced Not Delivered" report (Accounting > Review) and stays there permanently, even after all of its combo items are delivered.

**Steps to reproduce:**
1. Create a combo product bundling two storable items.
2. Sell the combo on a sale order, confirm and invoice it.
3. Deliver every combo item.
4. Open Accounting > Review > Invoiced Not Delivered.

**Current behavior:**
The combo parent line is listed. While items are partially delivered, both the parent and the items are listed, duplicating the same information.

**Expected behavior:**
The combo parent is not listed; only the combo item lines, which carry the real delivery state, appear when they are genuinely not delivered.

**Cause of the issue:**
A combo parent is a virtual sale order line with no stock move of its own, so its delivered quantity is never advanced and always reads 0. The accrual report selects lines where
`qty_invoiced_at_date > qty_delivered_at_date`, so the parent (which does receive an invoiced quantity from the combo logic) matches forever.

**Fix:**
Combo parents carry no delivery information of their own, so excluding them from the accrual search domain is more accurate than inventing a delivered quantity for them. Their combo item lines already represent the real delivery state, so the report stays correct.

opw-6215110

Issue
-----
Labels generated with DHL do not respect the template (dimensions) set on the
delivery method.

Steps to reproduce
-----
- Set up DHL
	- set label template as 6X4_A4_PDF
- Create a delivery using the method
- Validate the delivery

> The generated label is in 8x4 inch format instead of 6x4 full page

Explanation
-----
All info below was found in DHL's API doc from the following YAML file

https://developer.dhl.com/sites/default/files/2026-05/dpdhl-express-api-3.3.0.yaml

There are 2 issues with the current implementation regarding the label format.

1. The formats defined on the model (the `ProviderDHL` `delivery.carrier`) do not match the ones of the API. From the API, the accepted values are the following:

- ECOM26_84_A4_001
- ECOM26_84_001
- ECOM_TC_A4
- ECOM26_A6_002
- ECOM26_84CI_001
- ECOM26_84CI_002
- ECOM26_84CI_003
- ECOM_A4_RU_002
- ECOM26_84_LBBX_001
- ECOM26_64_LBBX_001

(values taken from the excerpt below)

```
templateName:
    description: >-
      Please enter DHL Express document template name.
      <BR>                Sample Transport label
      templates:<BR>                ECOM26_84_A4_001
      <BR>                ECOM26_84_001 - default<BR>
      ECOM_TC_A4<BR>                ECOM26_A6_002<BR>
      ECOM26_84CI_001<BR>                ECOM26_84CI_002 - supported
      single customer barcode<BR>                ECOM26_84CI_003 -
      to be used if customer barcodes are used<BR>
      ECOM_A4_RU_002<BR>
      ECOM26_84_LBBX_001 - supported for loose BBX shipment<BR>
      ECOM26_64_LBBX_001 - supported for loose BBX shipment<BR>
      [...]
    type: string
    maxLength: 25
    example: ECOM26_84_001
```

[...]: additional info unrelated to labels (useful only for other `typeCode` values)

Since `ProviderDHL` is a model, the `dhl_label_template` selection values cannot be changed and must thus be mapped to the corresponding API values.

- 8X4_A4_PDF => ECOM26_84_A4_001
- 8X4_thermal => ECOM26_84_001
- 8X4_A4_TC_PDF => ECOM_TC_A4
- 6X4_thermal => ECOM26_A6_002
- 6X4_A4_PDF => ECOM26_A6_002
- 8X4_CI_PDF => ECOM26_84CI_001
- 8X4_CI_thermal => ECOM26_84CI_001
- 8X4_RU_A4_PDF => ECOM_A4_RU_002
- 6X4_PDF => ECOM26_A6_002
- 8X4_PDF => ECOM26_84_001

Couple notes about this matching:
- There is no 6x4 in the API, so A6 is used instead (A6 is 105x148mm, 4x6 is   101.6x152.4mm so not a perfect match but the best option still)
- ECOM26_84_001 and ECOM26_A6_002 are used as default values for the respective   formats when there is no exact match possible (eg 6x4 only has one option in the API, the default one)
- "A4" is being ignored, because of point 2

2. There is a specific field to force the label to be in A4 format (according to the API, see excerpt below)

```
fitLabelsToA4:
  description: >-
    To print respective Transport Label and Waybill document into
    A4 margin PDF.<BR>                Note:
    ECOM26_A6_002,ECOM26_84CI_001,ECOM26_84CI_002,ARCH_6X4,ARCH_8X4
    template. <BR>                This option is applicable only
    for PDF encodingFormat selection.<BR>                false:
    Transport Label and Waybill document will use default margin
    settings (default behavior) <BR>                true:
    Transport Label and Waybill document will print into A4 margin
    PDF
  type: boolean
  example: false
```

-----
Ticket:
opw-6148713

### Description of the issue/feature this PR addresses:
**Issue:** When processing incoming EDI/Peppol invoices, multiple contacts (parent companies, joint ventures, child contacts) frequently share the same VAT number. Because the parser's tie-breaker relies primarily on VAT, invoices are often incorrectly assigned to individual child contacts or newly created joint ventures rather than the correct vendor.

**Solution:** Prepend is_company DESC, supplier_rank DESC to the SQL search order in the _import_retrieve_customer fallback domain. This ensures that the matching logic explicitly prioritizes business entities over individual contacts, and active vendors over other records.

### Current behavior before PR: 
When searching by VAT with limit=1, the parser uses order='company_id, parent_id DESC, id DESC'. If a parent company and a child contact share a VAT, the query frequently returns the child contact or a newer joint venture due to the id DESC fallback.

### Desired behavior after PR is merged: 
The parser will correctly prioritize main companies over individual contacts when VAT numbers are shared. If multiple companies share the same VAT, the most active vendor will be selected.

opw-6174628

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

***Steps to reproduce*:**

- Create an Argentinian company and create a branch company under the same company.
- Set the same Tax ID for both the main and branch company.
- Archive the branch company.
- Go to Settings -> Accounting.
- Select any Argentinian Fiscal Localization for the main company.

***Observed behavior*:**

- An access error is raised: `Access to unauthorized or invalid companies.`

***Cause*:**

- In `_get_branches_with_same_vat`, the following logic: `current.root_id._accessible_branches()` and `self.env['res.company'].sudo(). search([('id', 'child_of', current.root_id.ids)])` was also including archived branch companies.
- These archived companies were later involved in access and company validation flows, causing the access error.
- The same issue also affected demo data loading for such company setups.

***Fix*:**

- Add a filter to include only active companies and branches while fetching related companies.
- This prevents archived branch companies from being included in the validation flow.
- Also fixes the issue preventing demo data from loading correctly for these company configurations.

Related Community PR :- [odoo/community](https://github.com/odoo/odoo/pull/266321)

opw-6197313

Issue:
----------------------------------------
When in a negative timezone, the "Out of Office until..." text in discuss shows the day before.

Steps to reproduce:
----------------------------------------
- Change the timezone of the user to "America/Toronto" for example
- Have an employee currently on leave until tomorrow
- Open discuss to chat with this employee
- The "Out of Office until..." shows today's date

Cause:
----------------------------------------
When calling `toLocaleString()` without a timezone specified in the options, the date is converted to local time (in the browser's timezone).

Here `persona.out_of_office_date_end` is just a date, `deserializeDateTime()` converts it to a timestamp, so the same day at 0am. Then if the timezone is negative, the timestamp becomes an hour the previous day when calling `toLocaleString()`. The format we give `DateTime.DATE_MED` doesn't include hours, so we just display the previous date.

Solution:
----------------------------------------
Add `timeZone:"UTC"` in the options to avoid the timezone conversion.

opw-6252040

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