In certain conditions all lines in invoice require a tax. When making
a down payment from an order containing products using fixed price tax,
the corresponding invoice line was created without tax. The issue appear
both when making the down payment from the sale order and from the PoS.

Steps to reproduce:
-------------------
* Create a fixed price tax of 10€
* Create a product with this tax
* Create a sale order with this product and make a downpayment of 10%
> Observation: The down payment line has no tax set.
* Open PoS and make a down payment of 10% for the same order
* Pay and invoice the order
> Observation: The down payment line has no tax set.

Why the fix:
------------
If the tax is required on every invoice line we manually add a 0% tax to
the down payment line to ensure that the invoice is compliant.

At the moment we only add the tax when peppol is activated on the
current company. But the `_require_tax_ids_on_invoice_lines` method can
be overriden by other modules if downpayment lines also require tax.

opw-5853070

# Steps to reproduce:
* Enable **Developer Mode**.
* Go to **Accounting → Configuration → Accounting → Accounting Reports**.
* Create a new report and enable **Composite Report**.
* Add a new line of type **Journal Report**.
* Save the report and create a menu item from the gear icon.
* Open the report from the reporting menu.
* Try to download the report in **PDF** format.

# Observed behavior:
* PDF export fails with a traceback.
* Composite reports containing journal report sections cannot be exported as PDF.

# Cause
When exporting a composite report to PDF, the export flow iterates over each embedded sub-report and generates the HTML body used for PDF rendering.

* The composite export relies on the base [`export_to_pdf`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_report.py#L5875) implementation from `account.report`, which directly calls `_get_pdf_export_html()` for each sub-report.

* For standard reports, this works as expected because they use the base [`_get_pdf_export_html`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_report.py#L5944) method, which renders flat report lines into the default PDF template.

* Journal reports, however, rely on a completely different PDF structure. Their templates expect `document_data` (journal entries grouped by journal/document) instead of flat report lines.

* This `document_data` is generated exclusively by the journal report’s custom handler via its own [`export_to_pdf`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_journal_report.py#L240) flow.

* The handler builds the required `document_data` using [`_generate_document_data_for_export`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_journal_report.py#L261C9-L261C22).

* When a journal report is embedded inside a composite report, the composite export logic bypasses the custom handler and forces the report through the base `_get_pdf_export_html()` pipeline.

* Since the base pipeline does not generate `document_data`, the journal report PDF template fails at render time with `KeyError: 'document_data'`.

In short, journal reports embedded in composite reports were incorrectly routed through the standard PDF export pipeline instead of their specialized handler-based one.



# Fix:
* Add PDF export support to the journal report custom handler.
* Centralize common print option logic in a shared helper.
* Update composite report export logic to delegate PDF generation to custom handlers when available.
* Journal reports inside composite reports now export to PDF correctly.

opw-5477551

When scanning a loyalty card in POS, the customer should be automatically selected. However, this fails when the customer is not in the initial preloaded customer list due to the limited_customer_count setting.

Partial backport of: https://github.com/odoo/odoo/commit/e2843355898d4cce953fba35504170c10910fc35

Steps to reproduce:
-------------------
* Open POS with limited_customer_count set to a low value (e.g., 5)
* Create a loyalty card for a customer that won't be in the top 5 preloaded
* Scan the loyalty card barcode in POS
> Observation:
Customer is not selected, shows "Invalid coupon code" error

Why the fix:
------------
The current implementation only searches for loyalty cards in the local POS cache. When a loyalty card's partner_id is not resolved (because the partner wasn't preloaded), the code fails to set the customer.

This fix backports the 19.0 solution which:
1. Uses server-side lookup via get_loyalty_card_partner_by_code() to find the partner ID from the loyalty card code
2. Explicitly loads the partner on-demand if not in the local cache
3. Works regardless of whether the customer was in the initial preload

The test didn't spot that previously because the default limited_customer_count was big enough.

opw-5778328

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/537e8ecaf7 [REL] 18.0.58 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/0355117fc6 [FIX] Dynamic pivot: header alignment [Task: 5922279](https://www.odoo.com/odoo/2328/tasks/5922279)
https://github.com/odoo/o-spreadsheet/commit/04c2db214f [FIX] dynamic_tables: trim overlap on the correct side [Task: 5905900](https://www.odoo.com/odoo/2328/tasks/5905900)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

__

## Short functional explanation of the error
When we create an invoice for a quotation that holds a timesheet product and recorded timesheets for last month.
In the wizard, we set the timesheet period from the first to the last day of last month.
Then, we set the `Invoicing Switch Threshold` to the day of last month. We record another hour for the timesheet, for this product, for today. When we select last month as timesheet period when creating a new invoice, the 2 hours that have already been invoiced are reinvoiced. Moreover, once we confirm this second invoice, it is possible to create again and again invoices for these already invoiced timesheets, without changing the Invoicing Switch Threshold parameter.

## Reproduction Steps
1. Create a quotation. Add as a line a timesheet product. Set the quantity to 2. Validate and click on the smart button Recorded.
2. Record 2 hours with a random date for last month.
3. Create an invoice. In the wizard, set the timesheet period to the first -> the last day of last month. Confirm, and on the invoice form,
 set the invoice date to last month  (after the day on which you
 recorded the timesheet hours) and confirm.
4. Click on configuration > settings. Search for Invoicing Switch Threshold, and set the date to the last day of last month.
5. Go back to the invoice you created. It should have the ribbon `Ìnvoicing App Legacy`.
6. Go back to the sales order. Click on the smart button Recorded and add one more hour to the timesheets, but this time in February.
7. Create an invoice. On the wizard, set the timesheet period to the first -> last day of last month. Click confirm.

### Expected behavior
The system shouldn't let us create an invoice, as we have nothing to invoice, as all the timesheets have already been invoiced.

### Unexpected behavior
An invoice is created with 2 hours. It doesn't take into account the hours added in February (normal) but reinvoices the timesheets that have already been invoiced (not normal).

## Origin of the issue
When retrieving the quantities to invoice for the timesheets, we don't take into account the quantities already invoiced for the same timesheet.

__
opw-5426434

### Issue:
The pill name contains the hours when it spans over the next day for less than 3 hours but not if more than 3 hours.

### Steps to reproduce:
- Go to Planning app
- Create a shift for an employee from 3pm to 2am (over two days)
- The hours of the shift are displayed
- Modify the shift end to 3am
- The hours of the shift aren't displayed

### Cause:
Before the refactor adapting the gantt view to OWL, when a shift spanned over two days less than three hours, then the gantt view truncated the pill to display it in only one day. (see [`_snapToGrid()`](https://github.com/odoo/enterprise/blame/a16b2ef569903c0ae5803c169dbd68acd0141fe1/web_gantt/static/src/js/gantt_row.js#L1044-L1072)) The same logic was done for the computation of the pill's name in [this commit](https://github.com/odoo/enterprise/commit/98a86cbacf484646f486e4648788cfa53cc9648c).

But as the pills are no longer truncated since 17.0, the computation of pill names is faulty.

### Solution:
We remove the checks of the 3-hour margin. This also makes the variable `spanMoreThanOneDay` useless, so we delete it.

opw-5881532

Forward-Port-Of: odoo/enterprise#107233

**Problem:**
When creating a new stock.move.line in the moves view (accessed via smart button from a picking), the newly created line disappears after any refresh action (manual refresh or triggering "Put in Pack").

**Steps to reproduce:**
1. Open a receipt/picking operation
2. Click on the "Moves" smart button to open the detailed operations view
3. Create a new stock.move.line record
4. Click "Put in Pack" or manually refresh the page
5. Observe that the newly created line disappears

**Current behavior:**
The newly created stock.move.line disappears from the view after refresh, and only reappears if you navigate back to the picking and then return to the moves view.

**Expected behavior:**
The newly created stock.move.line should remain visible in the view after refresh or any action that triggers a view reload.

**Cause of the issue:**
  The action_detailed_operations method uses a static domain [('id', 'in', self.move_line_ids.ids)] that captures a snapshot of move line IDs at the moment the action is opened.
  https://github.com/odoo/odoo/blob/22ac818970f104a732cc7d24afc440cf0e6d74bd/addons/stock/models/stock_picking.py#L1204-L1212 When a new stock.move.line is created in this view, its ID is not included in the original static list. Any refresh (manual or triggered by operations like "Put in Pack") re-applies this static domain, filtering out the newly created lines because their IDs weren't captured in the initial list.

**Fix:**
Using a dynamic domain based on picking_id ensures all move lines belonging to the picking are always visible, regardless of when they were created. This aligns with the expected behavior of showing "all move lines for this picking" rather than "only the move lines that existed when the view was opened". The relational lookup [('picking_id', '=', self.id)] is re-evaluated on each refresh, automatically including any newly created lines that have the correct picking_id set.

opw-5398620

Steps to reproduce:
1. Create a product and two BoMs: BoM A (with operations) and BoM B (empty).
2. Create a Manufacturing Order (MO) for the product selecting BoM A.
3. Switch BoM A to BoM B, then switch back to BoM A.
4. Modify the production quantity field. -> New operation lines are appended every time the quantity is changed.

The issue occurred because _compute_workorder_ids used 'wo.ids' to filter existing workorders. In the "Draft" state (UI/onchange), records exist as "virtual records" (NewIds). For these records, .ids returns an empty list [], which evaluates to False in Python.
Consequently, the existing virtual workorders were filtered out of the dictionary used to map operations to existing lines. The logic assumed the lines didn't exist and used Command.create() instead of Command.update(), causing duplication. Similar issues existed where 'NewIds' were ignored during BoM swaps, leaving "phantom" records in the cache.

Solution:
Removing the '.ids' check and using '.mapped('id')' ensures the computation remains "virtual-aware" and stable across sequential onchanges.

TECHNICAL JUSTIFICATION:
In Odoo 18.0, the ORM explicitly supports using Command.update and Command.delete with virtual records (NewIds) without an origin. This is handled by the 'write_new' method in relational fields:
- Virtual browse wraps IDs in NewId: https://github.com/odoo/odoo/blob/f688c6b66310438fa3e36a207770a63d0d8fffa5/odoo/fields.py#L4826-L4855

opw-5489862

Currently, editing a posted `miscellaneous` journal entry in Chile 
localization incorrectly raises a validation error.

**Steps to reproduce:**
- Install the `l10n_cl` module and switch to the `CL company`.
- Go to Accounting > Accounting > Journal Entries.
- Create a balanced entry using the `Miscellaneous journal `and `post` it.
- Reset it to draft, modify the `name`, and try to `save` it.

**Observation:**
`Validation error`: `The DTE document number (folio) must contain only digits.`

**Root cause:**
At [1], the constraint validation is applied to all journal entries in 
Chilean companies, including `miscellaneous` journals. However, 
`miscellaneous journals (move_type = 'entry')` are not linked to Chilean 
electronic documents, so the numeric folio validation should not apply to them.

**Fix:**
This commit ensures that the validation is not raised for `miscellaneous` journal 
types by excluding miscellaneous journals from the numeric folio validation constraint.

[1]:
https://github.com/odoo/odoo/blob/f39785bcddd1eb5b7fb503d053c9bb66e2a0f15c/addons/l10n_cl/models/account_move.py#L20-L30

opw-5926773

In multi-country databases, a Peruvian company can invoice a foreign customer (e.g., a Colombian company) whose identification type is defined by another localization. Those records typically have an empty l10n_pe_vat_code, since there are no cross-country dependencies between LATAM identification types.

In that case, the generated UBL leaves the receiver identity type empty and SUNAT returns an error like:
```
2015/2015 - El XML no contiene el tag o no existe informacion del tipo de documento de identidad del receptor... (missing schemeID value).
```

Odoo already defines schemeID = 0 for some foreign identification types in l10n_pe data, but it cannot cover identification types coming from other countries’ localizations (e.g. Colombia):
https://github.com/odoo/odoo/blob/18.0/addons/l10n_pe/data/l10n_latam_identification_type_data.xml#L4

This change ensures that, when the partner is not from Peru and the PE VAT code is missing, we fallback the receiver identification type to "0" in:
- PartyIdentification/ID/@schemeID
- AccountingCustomerParty/AdditionalAccountID
- the QR payload identification type field

This prevents generating invalid UBL/QR content for foreign customers in multi-country setups.

## Issue
When creating and confirming an Upsell SO from a Subscription, the preview still shows the Sale Order as a "Quotation", which is inaccurate.

<img width="1330" height="296" alt="5489970" src="https://github.com/user-attachments/assets/cfff4c7a-fff7-4859-861b-c190dab9097d" />

## Steps to reproduce
1. Install *Subscription* (`sale_subscription`)
2. Create a Subscription S00001
    - Any Customer
    - Any Recurring Plan
    - Any Product
3. Create and confirm the invoice for the subscription S00001
4. On the subscription S, click Upsell and confirm the resulting Sale Order S00002
5. On the Sale Order S00002, click Preview
6. **The title of the Sale Order is "Quotation - S000002". In the sale.order list view, the Sale Order is shown as a Sales order, just like the initial Subscription.**

## Cause
The title shown in the preview is defined here:

https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/sale_subscription/views/sale_subscription_portal_templates.xml#L187-L195

The initial subscription falls into the `if` condition, which only shows the name of the SO. The upsell sale order is not considered as a subscription, as explained and showed here:

https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201

The word *"Quotation"* shown in the preview is the `sale_order.type_name`", computed here:

https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L227-L237

The term "Quotation" was chosen in https://github.com/odoo/enterprise/commit/14e5cff65affa888f33d4008d10a32e6992d3a39.

## Fix
Before this commit, an upsell would always be named *"Quotation"*. With this commit, upsells are now added to the `other_orders` variable in `_compute_type_name` and follow the same logic as other SO:

https://github.com/odoo/odoo/blob/a3bf9264ca25ec11b0c9742e142d2404cac6d261/addons/sale/models/sale_order.py#L797-L803

<img width="1316" height="308" alt="5479900_2" src="https://github.com/user-attachments/assets/7cfeb578-2870-43a6-a48b-ba0898718641" />

## Alternative
An alternative to this fix would be to update the condition used to display the name of the subscription in the preview (cf. first code snippet). This would probably result in removing the `sale_order.is_subscription` from the condition, as it is the part of the condition that upsell SOs do not meet.

opw-5489970