When reconciling bank statements with an account, the system will look for past statement lines already reconciled with that account and create a reconciliation model based on common substring in payment_ref.

If this payment refs contains only spaces (eg. ' '), it will trigger an index out of range traceback. This is explained by the fact that spaces are striped then '' is considered as False in some filtering leaving the list empty.

From the UI, putting ' ' is not supposed to be possible because spaces are striped before write but there is many ways to import statement lines which may lead to this hence the decision of handling this scenario to make the code more robust.

Steps to reproduce:
1/ Create two statement lines with payment_ref as ' ' (you can force it using a write)
2/ Click "Set account" on first one and pick 100000 Issued Capital
3/ Do the same for the second statement line
=> Traceback

In this commit, we do not check for common substring if there is less than two
labels.

opw-6379977

Forward-Port-Of: odoo/enterprise#125779

Before this commit, this test sometimes failed because it couldn't find a dialog containing "camera" within 200ms.

In the test scenario, we click to open the BarcodeDialog, which uses the BarcodeVideoScanner. The latter, in its `onMounted`, checks whether it has the necessary permission, which isn't the case as the `getUserMedia` function is mocked in the test to return a rejected promise. As a consequence, the `onError` callback given in props is called, which changes the state of the parent component, which re-renders itself so display "Unable to access camera" instead of the BarcodeVideoScanner.

To make this test more robust, we do 2 things:
1) load the zxing library before running the test, which avoids the BarcodeVideoScanner component to load it in onWillStart. 2) explicitly wait for the 2 animationFrames, as in the scenario, we must wait for the BarcodeDialog to be rendered twice, and those renderings are now synchronous.

runbot error-237933

Forward-Port-Of: odoo/odoo#280613

Currently, users encounter a traceback when attempting to print the traceability report for a manufacturing order.

## Steps to produce:
- Install Manufacturing without demo data.
- Enable Lots & Serial Numbers in Settings.
- Create two products: Car and Engine.
- Configure Engine to use Unique Serial Number tracking (Inventory →Traceability).
- Set the on-hand quantity of Engine to 1 with serial number 0001.
- Create a BoM for Car using Engine as a component.
- Create and confirm a manufacturing order for Car.
- Click `Consumed` for the component and click Produce All.
- Navigate to Lots & Serial Numbers → Engine → 0001 → Traceability.
- Click the arrow next to the manufacturing order reference, then click Print.

## Observed Behavior:
An `Arbitrary Uncaught Python Exception` traceback is raised, resulting in a 404 error.

## Root Cause:
This issue occurs because, when the user clicks the arrow button in the traceability report, the template [1] invokes the `onClickUpDownStream` function.

This function adds the URL `/stock/output_format/stock/active_id` to the context , as shown in [2]. Later, when the user clicks the Print button, `onClickPrint()` [3] constructs the print URL using the `controllerUrl` value by replacing the active model and active ID placeholders with values from the context.

However, the URL stored in the context contains `/active_id` instead of `:active_id`. As a result, the placeholder replacement does not occur, leaving the URL unchanged. This causes the print action to use an invalid URL, ultimately resulting in a 404 error.

As shown in [4], `controllerUrl` is assigned directly from the context.

[1]:
https://github.com/odoo/odoo/blob/a398ade607940a281552f8cba2c1cf80bb0e77f6/addons/stock/static/src/client_actions/stock_traceability_report_backend.xml#L52-L56 [2]:
https://github.com/odoo/odoo/blob/a398ade607940a281552f8cba2c1cf80bb0e77f6/addons/stock/static/src/client_actions/stock_traceability_report_backend.js#L105-L118 [3]:
https://github.com/odoo/odoo/blob/a398ade607940a281552f8cba2c1cf80bb0e77f6/addons/stock/static/src/client_actions/stock_traceability_report_backend.js#L120-L131 [4]:
https://github.com/odoo/odoo/blob/a398ade607940a281552f8cba2c1cf80bb0e77f6/addons/stock/static/src/client_actions/stock_traceability_report_backend.js#L53-L55

## Solution:
Pass the correct URL in the context so that the active ID placeholder can be replaced correctly during the print action. This ensures that the generated print URL is valid, allowing the user to print the report without encountering any errors.


opw-6372834

Forward-Port-Of: odoo/odoo#279844
Forward-Port-Of: odoo/odoo#276449

Steps to reproduce
------------------
1. Install `l10n_pe_pos`.
2. Create a contact with the identification type DNI and a number.
3. Sell a product to this contact and print the receipt. -> the receipt shows "RUC" in front of the number, even though the number is a DNI and not a RUC.

Why it's happening
------------------
Since `aeaca097ae39` the number of the contact is printed with a label in front of it, before there was no label at all. This label is the `vat_label` of the country, so "RUC" for Peru. But in Peru each contact can have a different identifier, and the type is on the contact in `l10n_latam_identification_type_id`.

The fix
-------
In `l10n_pe_pos` we set `partner_vat_label` with the name of the identification type of the contact. If the contact has no identification type we keep the number alone.

Before vs After for a customer identified with DNI
-------------------------------------------------
<img width="465" height="203" alt="Capture d’écran 2026-07-30 à 14 45 17" src="https://github.com/user-attachments/assets/85c921df-c1fd-430b-b4e6-341bc183bd61" />

<img width="467" height="253" alt="Capture d’écran 2026-07-30 à 14 49 36" src="https://github.com/user-attachments/assets/3ac243c6-04fe-47a4-a662-c59b88276db7" />





opw-6422619

Issue:
The MyInvois payload computed `cbc:PrepaidAmount` as `amount_total - amount_residual`, treating every reconciled payment as a prepayment. A payment made on or after the invoice date is an ordinary settlement, not a deposit, but the code recognized it as one anyway. The values reported for `PrepaidAmount` were wrong regardless of the invoice date, and for a fully paid invoice this also collapsed `PayableAmount` to 0.00, which LHDN rejects.

Root Cause:
LHDN only considers a reconciled payment a genuine deposit if it was received before the invoice date. The code applied no date condition at all, so any payment reconciled against the invoice was added to `PrepaidAmount` and reduced `PayableAmount` accordingly.

Fix:
Only sum reconciled payment partials whose date is strictly earlier than the invoice date as prepaid, so regular payments are no longer misclassified as deposits. As a safety net, if the valid prepaid sum still covers the full invoice amount (e.g. a full advance payment), reset it to 0 so `PayableAmount` always reflects the full amount_total instead of being reported as 0. Also omit the `PrepaidPayment` node entirely when there is no genuine prepayment, rather than emitting it with a 0.00 amount.

[Task-6404296](https://www.odoo.com/odoo/my-tasks/6404296)

Forward-Port-Of: odoo/odoo#280569
Forward-Port-Of: odoo/odoo#278010

Steps to reproduce:
- From the website editor, open the Theme tab.
- Upload a custom font.
- Open the media dialog and go to the "Documents" tab.

Issue:
The uploaded font files appeared in the Documents tab. When a zip file was uploaded, every font it contained appeared individually, along with the generated "CSS font face" attachment.

Cause:
Fonts uploaded through `/website/theme_upload_font` are created as public attachments. The Documents tab of the media dialog lists every public attachment that is not an image or an asset, so the font files (mimetype `font/...`), their font face declaration (mimetype `text/css`) and googleFontMetadata (server caches it as public attachment) were listed.

Fix:
Exclude those attachments from the Documents tab domain:
- whose mimetype starts with `font/`,
- whose description matches the font face declarations created in `snippets.options.js`.
- whose name equals "googleFontMetadata".

task-[4771523](https://www.odoo.com/odoo/project/974/tasks/4771523)

Forward-Port-Of: odoo/odoo#280563
Forward-Port-Of: odoo/odoo#275838

**Steps to reproduce:**

- Install l10n_pl_edi and enable Allow KSeF integration from 
  **Accounting** settings. 
- Switch to a Polish company.
- Create an EU customer with a valid VAT number.
- Create a sale order containing a service product taxed 
  with 0% Steel (or any tax that has a tag of K11).
- Confirm the sale order and create a down payment invoice. 
- Send the invoice to KSeF and inspect the generated XML. 

**Observed behavior:**

The generated KSeF XML does not contain the `P_13_8` field. 

**Cause:**

For invoices involving the tax of tag `K11` (mainly these taxes are used for the supplies 
that are outside the territory of Poland), the value corresponding to `P_13_8` was not 
being assigned during XML generation, causing the tag to be omitted from the exported 
KSeF document.

**Fix:**

Populate the value of `P_13_8` during KSeF XML generation for invoices, ensuring the 
field is correctly included in the exported XML. 

This PR updates the computation of tag `P_13_10` with its test case to ensure consistency 
with the expected reporting logic, where the tag is computed solely from `K_31`.

Here is the [Documentation](https://ksef.podatki.gov.pl/media/gtjhkeek/information-sheet-on-the-fa-3-logical-structure-04032026.pdf) link for the reference of the Ksef structure. 

**opw**-6294181

Forward-Port-Of: odoo/odoo#280830
Forward-Port-Of: odoo/odoo#276887

Issue:
---
Fiscal position is wrongly set to `self.env.user.partner_id.country_id`
instead of `partner_shipping` country, if `partner_shipping_id` is not
changed in the checkout process.

Steps:
1- Create two auto detect fiscal positions: France, Germany
2- Set portal user's partner address country to France.
3- Using portal user, shop from website, and create a delivery address.
4- Pay and confirm the order.
5- Using the admin user, you check the SO's FP which is correctly set
   to Germany.
6- Using portal user, again shop from website, and don't change
   address. Keep previous shipping address which is Germany.
7- Confirm and pay the order.
8- Using admin user, check the new SO's FP. It's set to France.

Cause:
---
`_compute_fiscal_position_id` in SO depends on `partner_shipping_id`.
When the `partner_shipping_id` is not changed, the fiscal position
value set in create will remain.
This value is set in `Website._prepare_sale_order_values()`.
The `fiscal_position_id` is set to self.fiscal_position_id, which is
`_get_fiscal_position(self.env.user.partner_id)`.

Fix:
---
If the user has already a SO, we can use last SO's shipping address
and invoice address to calculate FP in `_prepare_sale_order_values`.

opw-6357638

Forward-Port-Of: odoo/odoo#279716
Forward-Port-Of: odoo/odoo#276485