This commit adds 4 attachments to the Latvian tax report
and an XML export for the tax report (including the attachments).

The attachments are the following
- PVN 1-I: domestic purchase / import
- PVN 1-II: EU purchase
- PVN 1-III: domestic sales / export
- PVN 2: EU sale

The attachments give more details for the tax report.
The lines of the attachments are "transactions"
A "transaction" is identified by the move and the transaction type or document type.
The transaction type is given via a tax tag (see community PR).
- PVN 1-I: transaction type, move
  - Small transactions (< 150€) are aggregated separately under transaction types 'V' or 'T'
    independently of the move
  - 'V': All small transactions of a partner in case the total of all their small transactions reaches 150€
    - There is max 1 line per partner
  - 'T': All small transactions that are not grouped under some 'V' line
    - There is max 1 line like this; it has no partner information
- PVN 1-II: transaction type, move
  - Small transactions (< 150€) are aggregated separately under transaction types 'V' or 'T'
    (like PVN 1-I)
- PVN 1-III: document type, move and line in the main tax report
  - All transactions with (document) type 'X' are aggregated on a single line
  - Small transactions (< 150€) are aggregated separately under document types 'V' or 'T'
    (like PVN 1-I)
  - The line in the main tax report is ignored for 'X' and small transactions
- PVN 2: transaction type, move
  - No aggregation is performed here

Only account move lines that are tagged with a transaction type (1-I, 1-II, 2)
or a relevant tag for the main report (1-III) are shown in the reports.

The tags `Rep` and `C (car)` only take 40% and 50% respectively of the
base amounts. The tax amount is assumed to be split correctly.

task-4251184

Forward-Port-Of: odoo/enterprise#84135

Issue:
The Item Trace Number according to CPA-005 standard should be a nonzero sequence that serves as unique reference ID for payments. Currently, Odoo sets the Item Trace Number of all payments as a zero-filled sequence 

According to CPA-005 standards on the Item Trace Number:
"The data elements (b), (c) and (d) each must be greater than zero or the TRANSACTION WILL BE REJECTED" (page 36).
https://www.payments.ca/sites/default/files/standard005eng.pdf

Steps to reproduce:
1. Install the module l10n_ca_payment_cpa005
2. Go into "CA Company"
3. In the configuration for "CA Company", add something to the fields "Short Name used in Canadian EFT" and "Company ID" i.e. "CCC"
4. Set all the fields in the "Canadian EFT/CPA Configuration" section of the bank journal
5. Set the bank record on the bank journal. Set the field "Financial Institution ID Number" field of the "Account Number" record of the bank journal to any numerical sequence
6. Create a bank account on "Azure Interior" and make sure to check the field to trust the bank account that you created (otherwise there will be an error)
7. Create two payments with the vendor of "Azure Interior" using the payment method of "Canadian EFT"
8. Create a batch payment for both payments created
9. Validate the batch payment and the export file should show up in the chatter
10. Note that in the export file, the Item Trace Number for each payment is set to be all zeros, whereas it should be a nonzero identification sequence

Solution:
Set the Item Trace Number to be the payment's id

opw-6323432

Forward-Port-Of: odoo/enterprise#123707
Forward-Port-Of: odoo/enterprise#123633

### Issue:
On Chilean export invoices, the customs information table may display data in the wrong columns

When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by QWeb, causing the remaining columns to shift left

This results in `Qty of Packages` appearing under `Origin Port` or `Destination Port` in the printed document

### Cause:
`l10n_cl_port_origin_id` and `l10n_cl_port_destination_id` have no default value and are optional fields
`t-out` on a falsy value omits the `td` entirely in QWeb, breaking the column alignment

Adding `or ''` ensures an empty `td` is always rendered, preserving the table structure regardless of whether the fields are set

### Steps to reproduce:
- Install `l10n_cl_edi_exports` and switch to CL Company
- Create an Invoice (any customer, any line)
- In the gear menu, select Print > Invoice PDF copy (Chile)

Before the fix, `Qty of Packages` appears under `Origin Port` when neither port field is set

opw-6304670

Forward-Port-Of: odoo/enterprise#121923

Issue
-----
Delivery does not always work from/to some cities in Colombia, like Antioquia.

Cause
-----
There was an oversight in fix 7654c55 where only 5 digit postal codes taken from the colombian localisation were padded in

https://github.com/odoo/enterprise/blob/390acf532e8932fd9b9a708382a5e36cdbb35754/delivery_envia/models/envia_request.py#L726-L727

However, some of the colombian cities listed in `l10n_co_edi/data/res.city.csv` have 4 digit codes (like `SANTA FÉ DE ANTIOQUIA`, code `5042`).

https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/l10n_co_edi/data/res.city.csv#L12


These 4 digit codes have to be right-padded to 5 characters before the left-padding to match the official colombian zip codes. See colombian gov official document (PDF download) where the code is actually `05042`.

https://www.dane.gov.co/files/censo2005/provincias/subregiones.pdf

-----
Ticket:
opw-6248252

Forward-Port-Of: odoo/enterprise#123344
Forward-Port-Of: odoo/enterprise#120164

## [FIX] industry_fsm_sale: fix invoice status for zero price lines

### Issue:
Without Anglo-Saxon accounting, the system incorrectly sets the invoice status of all zero price sales order lines linked to an FSM task to 'no'

This includes pre-existing lines that were already present on the quotation before confirmation. If a zero price line is pre-existing, it should follow the standard flow and be marked as 'to invoice'
Only lines added as materials from the field service task at a zero price should be considered included in the price and marked as 'no'

### Cause:
In `SaleOrderLine._compute_invoice_status`, the system forced `invoice_status = 'no'` for all zero price lines when Anglo-Saxon accounting was disabled
It failed to check if the lines were actually materials added via the FSM task or original quotation lines

### Fix:
A new `material_sale_lines` compute field is added to `project.task` to distinctly isolate and track lines added specifically as materials during the task execution

In `SaleOrderLine._compute_invoice_status`, the logic is updated to ensure that only zero price lines identified as FSM materials are set to 'no' when Anglo-Saxon accounting is disabled
Other pre-existing zero price lines properly remain as 'to invoice'

### Steps to reproduce:
- Install `industry_fsm_sale`
- In Settings > Users & Companies > Companies > Any company, add the field Anglo-Saxon using Studio (In 19.0+)
- Disable Anglo-Saxon on the current company
- Create a product Service (Fixed Price, that create a task in a Field Service Project)
- Create and confirm a Sale Order with the Service and one product with unit price 0
Before the fix, the pre-existing SO line with price 0 is 
incorrectly considered as not to invoice ('no')

opw-6169802

------------------------------

## [FIX] industry_fsm_sale: sync sale order invoice status

### Issue:
When a sale order contains FSM material lines with a price of zero and Anglo-Saxon accounting is disabled, the overall sale order invoice status remains stuck on 'to invoice' even after all other invoiceable lines are fully invoiced

### Cause:
The standard `SaleOrder._compute_invoice_status` does not handle FSM business rules regarding zero price material lines that are marked as `invoice_status = 'no'`
Because these lines are never technically invoiced, the global order status fails to transition to 'invoiced'

### Fix:
Override `SaleOrder._compute_invoice_status` to recompute the status of confirmed orders linked to FSM tasks

We use the task's `material_sale_lines` to filter out material components
If all lines on the order are either 'invoiced' or are zero price FSM material lines with Anglo-Saxon disabled, the global sale order status is forced to 'invoiced'

### Steps to reproduce:
- Install `industry_fsm_sale`
- In Settings > Users & Companies > Companies > Any company, add the field Anglo-Saxon using Studio (In 19.0+)
- Disable Anglo-Saxon on the current company
- Create a product Service (Fixed Price, that create a task in a Field Service Project)
- Create and confirm a Sale Order with the Service and one product with unit price 0
- Add a Product from the Task (Use a price 0 product, or set the unit price to 0 on the SO)
- Create the invoice for the Sale Order
Before the fix, the Service and Pre-existing product are invoiced, but in the Other Info Tab of the SO, the status stays on 'To Invoice' instead of 'Fully Invoiced'

opw-6169802

Forward-Port-Of: odoo/enterprise#119238

**Description of the issue/feature this PR addresses:**

When a POS user attempts to open the Kitchen Display app from the main dashboard, they are blocked by an Access Error, despite being able to access the interface from within the POS app's sub-menu.

This occurs because the dashboard menu triggers a server action (`action_pos_preparation_display_kitchen_display`) to route the user. When a server action has no explicitly defined `group_ids`, Odoo's `_can_execute_action_on_records` method falls back to requiring `write` access on the underlying model (`pos.prep.display`) to execute the code. Since standard POS users do not have 'write' access to this model, the execution engine blocks the routing attempt.

This commit resolves the issue by explicitly appending the POS User group to the server action's `group_ids`.

opw-6305014

**Steps to reproduce:**

- As Mitchell Admin:
    - Settings > Users & Companies > Users > Marc Demo > Access Rights > Sales > set POS to User
- As Marc Demo:
    - Attempt to access Kitchen Display app > observe Access Error
    - POS > Orders > Preparation Display > observe no error


**Current behavior before PR:**

- POS Users receive an Access Error when attempting to access the Kitchen Display app from the main dashboard

**Desired behavior after PR is merged:**

- No Access Error when POS Users access the Kitchen Display app

Forward-Port-Of: odoo/enterprise#121419

Issue
-----
When making an international delivery to a partner with different invoice and delivery addresses, we send the delivery address as the `Sold To` address as well.

Problematic case 1
-----
- Create a belgian company
- Setup UPS
- Create a French customer
	- Add a different french delivery address
- Create a product (with some weight)
- Create a SO (with UPS delivery) to the customer & confirm
- Validate the transfer

> Commercial invoice `Sold To` uses the delivery address

Solution for case 1
-----
Use the delivery address' `commercial_partner_id`. This leads to another issue in some edge cases...

Problematic case 2 (caused by case 1 fix)
-----
- Create a belgian company
- Setup UPS
- Create a French customer
	- Add a delivery address in Switzerland
- Create a product (with some weight)
- Create a SO (with UPS delivery) to the customer & confirm
- Validate the transfer

> UPS error `The Sold To party's country code must be the same as the Ship To party's country code with the exception of Canada and satellite countries.`

Solution for case 2
-----
Default back to delivery address for the `Sold To` field when countries don't match, as this is a limitation of the UPS API. Warn the user, either on the SO or the transfer itself (if no SO).

Warning looks like this (on SO):
<img width="1914" height="716" alt="image" src="https://github.com/user-attachments/assets/f7aa73c4-f24c-42da-8f3e-6a58765ef020" />

-----
Ticket:
opw-6200263

Forward-Port-Of: odoo/enterprise#121479
Forward-Port-Of: odoo/enterprise#118031

# How to reproduce
- In the settings, enable Absence Mangement
- Create an employee with a Contract
- Create a Time off for that employee for yesterday
- Manually run the scheduled action "Attendance: Detect Absences for employees"
- Go to the attendance dashboard for that employee

# The issue
An attendance with no overtime was created for yesterday for that employee with a log note
saying "This attendance was automatically created to cover an unjustified absence on that day."
However, the absence was justified as the employee took a time off.

# Cause of the issue
When running the `_cron_absence_detection` cron job, we create "empty" attendances for the employees
that were absent yesterday. If those attendance's `overtime_hours` are 0, then we unlink them :
https://github.com/odoo/odoo/blob/a73428187112b3948a11810abae2a3c82c9c7bcd/addons/hr_attendance/models/hr_attendance.py#L659-L666

But, since `check_in` and `check_out` cannot be the same, we cannot really create an empty attedance.
We instead create an attendance of 1 second :
https://github.com/odoo/odoo/blob/a73428187112b3948a11810abae2a3c82c9c7bcd/addons/hr_attendance/models/hr_attendance.py#L652-L653

This will create an overtime of 0.003 seconds if there was a leave that day (which is our case).
This duration will be reflected in the attendance's `overtime_hours`. The issue is that we simply do
`== 0` when trying to find the attendances without overtime, so we don't unlink them.

The issue was introduced by :
https://github.com/odoo/odoo/commit/8d7859a569d9ac7303ca0b9be6c56496be14c544

Because `round(0.003, 3)` => 0 but `round(0.003, 4)` => 0.003

The issue is not present in 18.0+ because we don't create overtime if the duration is
`float_is_zero(overtime_duration, 2)` :
https://github.com/odoo/odoo/blob/39cce855aa27aa4af9225a61a3e1425383a9f49f/addons/hr_attendance/models/hr_attendance.py#L405

opw-6321883

Forward-Port-Of: odoo/odoo#274865
Forward-Port-Of: odoo/odoo#272089

**Steps to Reproduce:**
- Create an employee with at least one validated work entry.
- Modify the employee's resource_calendar_id.
- The schedule change triggers work entry recomputation.
- During regeneration, the employee is excluded because of the validated work entry.
- No valid employees remain for regeneration.

**Issue:**
- Employees with validated work entries are excluded from: `valid_employees = self.employee_ids - self.validated_work_entry_employee_ids`
- When all employees are excluded, `valid_employees` becomes empty.
- The flow still calls: `valid_employees.generate_work_entries(date_from, date_to, True)`
- An empty employee recordset causes `generate_work_entries()` to follow the global generation path and fetch all employee versions in the requested period. `_get_all_versions_with_contract_overlap_with_period(date_start, date_stop)`
- This can trigger unintended global work entry regeneration and cause severe performance issues on large databases.

**Root Cause:**
- The regeneration flow does not stop when no valid employees remain after excluding employees having validated work entries.

- As a result, generate_work_entries() is called with an empty employee recordset, which falls back to the global generation path.

**Solution:**
- Stop the regeneration flow when the valid employee recordset is empty Because the employee already has a valid work entry, there is no need to regenerate.

**Result:**
- Prevents unintended generation on all employee versions.
- Avoids unnecessary performance degradation on large databases.

**OPW-6290122**

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#274787
Forward-Port-Of: odoo/odoo#270728

Currently, flexible weekly overtime deducts the raw leave interval duration.

## **Steps to reproduce:**
- Install hr_holidays and hr_attendance
- Create an employee with flex 40h/week working schedule.
- Employee profile>setting>Default Ruleset>Employee schedule Rule and set `If the worked hours on a`: `week`.
- Create a public holiday on Monday.
- Record daily 8h from Tue to Sat (12 AM to 8 AM).

## **Observed Behavior:**
Attendance List View computes "Worked Extra Hours" incorrectly as 20:30h

## **Expected Behavior:**
"Worked Extra Hours" should be computed as 8h

## **Root Cause:**
In [_get_daterange_overtime_undertime_intervals_for_quantity_rule](https://github.com/odoo/odoo/blob/53448e5445c8bcbf12126bf27bd675f4b9883d05/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L290-L342), the system manually calculates overtime for flexible employees by deducting `schedule['leave']` durations from the expected working hours at [1]. However, for global public holidays, the system mishandles the timezone conversion within this schedule dictionary. Because public holiday intervals are stored and processed using UTC datetimes before being converted to the employee's local timezone, converting it to the employee's local timezone causes the holiday hours to shift and overlap into the next calendar day. As a result, the `schedule['leave']` calculation incorrectly thinks the employee had time off on normal working days, which throws off the final overtime amount.

[1]: http://github.com/odoo/odoo/blob/53448e5445c8bcbf12126bf27bd675f4b9883d05/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L304-L307

## **Fix:**
Replace the manual leave subtraction logic with the existing `_get_expected_hours_from_contract` method. This method naturally handles global public holidays and computes attendance intervals safely across different timezones without shifting hours into the wrong day.

**opw-6259328,6284145**

Forward-Port-Of: odoo/odoo#269293

Bug :
	- Create a new employee (also works with old employees)
	- Create an allocation of Paid Time Off that is available in the future.
	- Create a Time Off request for this employee in the future.
	- When Selecting Time off type you'll see that he has (0 remaining out of 0 days) even though he has just be allocated leaves. 

Reason :

clicking on the many2one field => triggers web_name_search (line 53 in web/models/modeld.py) => triggers name_search (line 1514 in orm/models.py) , here we fetch the searched records with sudo , and when switching to sudo we call a function called clean_context this function (line 952 in odoo/tools/misc.py) remove elements from the context that start with the prefix default_ , in our case , we when clicking on the field we pass the target date through default_date_from , thus we lose it , and instead we make the calculations as if the target date was today

Fix :
pass the date_from through 'leave_date_from' given that _ compute_leaves already checks this context entry, this way we make sure to keep our start_date in the context even if we switch to sudo during some point in the calculation.


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

Forward-Port-Of: odoo/odoo#273670

This commit introduce two corrections.

A.
Since commit[^1], it is not necessary to check the fingerprint at the
start of the service. It is the first `CheckIdentityException` which
will trigger the verification mechanism and, as a result, will update or
check the fingerprint. The first request to a auth route will initialize
the "bootstrapping" of the session fingerprint.

B.
The function `updateFingerprint` must return a negative response if an
error occurs and thus continue the verification process (which requires
that the system not be offline). For information, we cannot ignore an
error. This is because the original RPC will be replayed (without the
wrapper that handles the `CheckIdentityException` exception). It is
therefore necessary to remain in a state where the user can verify his
identity.

This fix solved an undesirable side effect.
The update of the fingerprint according to the event `WEB_CLIENT_READY`
occurs at an arbitrary time. If a form is currently being mounted
(because an untrusted device is being used) but the fingerprint update
marks that device as trusted in the backend (no matter the reason), then
when we call `/web/session/identity/check` without any data to retrieve
the reauthentication methods, the fingerprint check method will no longer
be possible[^2].
As a result, the form is mounted for a trusted device (and not perform
fingerprint check).

[^1]: https://github.com/odoo/odoo/commit/a43dee53f103f8ce19e5c84ca7d515e2a27e03ff
[^2]: https://github.com/odoo/odoo/blob/7c6f31d730304bca3f6c996800e76d1e40ce4adf/odoo/addons/base/models/ir_http.py#L563

Task-6373219

_**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% EU S**.
* 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_9` field.

**_Cause:_**

* For down payment invoices involving services taxed with **0% EU S**, the value corresponding to `P_13_9` 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_9` during KSeF XML generation for service down payment invoices, ensuring the field is correctly included in the exported XML.
* This PR updates the computation of tag `P_13_10` 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#270986

## Problem:
when snippets with identical images are added in the e-commerce website product page, the "Optimize SEO" option in debug mode causes an error to occur with a traceback. The traceback calls out a duplicate key in the `t-foreach` of a loop over `state.altAttributes`. the `t-key` for this loop is `img.id` which is generated by the `/website/get_alt_images` controller endpoint.

## Steps to reproduce:
1. Go to a product page and click on "go to website" smart nav btn.
2. Add a snippet with an image in the `description_ecommerce` field
3. Add a snippet with the same image in the `website_description` field.
4. In debug mode, open `site > Optimize SEO`
5. An error `Got duplicate key in t-foreach` is thrown.

## Solution:
The solution was simple to add a qualifier in the compound key generated by the controller action for the `id` field. The chosen qualifier in this case was `model['field']`. `field` is the position in the template where the image came from.

So now the keys for the two identical images go 

FROM
 
> `${model}-${id}-${index}`
>
> 1st image of `website_description`:
>    `product.template-6-0`
> 
> 1st image of `description_ecommerce`:
>    `product.template-6-0`

TO

> `${model}-${id}-${field}-${index}`
>
> 1st image of `website_description`:
>    `product.template-6-website_description-0`
>
> 1st image of `description_ecommerce`:
>    `product.template-6-description_ecommerce-0`

task-6325786

Forward-Port-Of: odoo/odoo#275649
Forward-Port-Of: odoo/odoo#272846

**Problem:**
On a job position whose company is left empty ("Visible to all"), the Recruiter dropdown does not propose any user anymore: only the "Create" option is offered. The same happens on applicants without a company. Only saas-19.2 is affected: 19.0/19.1 still use the res.users-based recruiter field, and on saas-19.3 the company became mandatory on job positions.

**Steps to reproduce:**
1. Install Recruitment
2. Open a job position whose Company is "Visible to all" (e.g. any demo job position)
3. Edit the Recruiter field

**Current behavior:**
The dropdown shows no user, only the "Create" option.

**Expected behavior:**
The dropdown lists the recruiters of all companies, as it does (per company) when a company is set.

**Cause of the issue:**
Commit 05e22346050d replaced the res.users-based `user_id` recruiter field with the hr.employee-based `recruiter_id`, declared with `check_company=True`. For check_company fields, `_description_domain()` sends the client `company_id and [('company_id', 'in', [company_id, False])] or [('company_id', '=', False)]`. When the record has no company, the domain falls back to `[('company_id', '=', False)]`, and since `hr.employee.company_id` is required, no employee can ever match. This reintroduces the issue previously fixed by 5dfe494e62af for the old user_id field: the `allowed_user_ids` mechanism introduced there was dropped by the field replacement.

**Fix:**
`check_company=True` brings nothing to these models server-side (neither `hr.job` nor `hr.applicant` has `_check_company_auto`): its only effect is that client-side domain. Folding the company condition directly into the recruiter domain with `('company_id', '=?', company_id)` keeps the per-company filtering when a company is set and degrades to no filtering when it is not, mirroring what is already done for `interviewer_ids` on the job position. The domains become strings so the client keeps evaluating `company_id` per record.

opw-6290312

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/99a9aef31 [REL] 19.2.20 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/3912ef44a [FIX] conditional_formatting: handle zero color scale midpoint [Task: 6312961](https://www.odoo.com/odoo/2328/tasks/6312961)
https://github.com/odoo/o-spreadsheet/commit/4eb05e8cb [FIX] config: filter-out claude folder from prettier [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)

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>