**Steps to reproduce:**

1. Install the Accounting module.
2. For partner X, create minimum 90 invoices for `See more/Load more` option into page.
3. In the partner form view, click the Customer Statement smart button.
4. Change the Report Type from Customer Statement to Follow-Up Report.
5. In the report, click `See more` in the dropdown → traceback occurs.

**NOTE**
-  You can easily create invoices using this cron job to generate 90 invoices.
```py
for i in range(90):
    invoice = env['account.move'].create({
        'move_type': 'out_invoice',
        'partner_id': 10,
        'company_id': env.company.id,
        'invoice_line_ids': [(0, 0, {
            'product_id': 16,
            'quantity': 1,
            'price_unit': 100.0,
        })],
    })
    invoice.action_post()
```

 **Issue:** 

`UncaughtPromiseError > OwlError
Uncaught Promise > Got duplicate key in t-foreach: ~account.report~17|~res.partner~42|Due~~
Occured`
- A traceback occurs due to a duplicate key error.

 **Cause:** https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/account_reports/static/src/components/account_report/account_report.xml#L72-L73

- In account_report.xml component uses line.id as a key.
<img width="781" height="176" alt="image" src="https://github.com/user-attachments/assets/57bf36ea-6890-45ef-8414-5522d71ece7b" />

- When expanding `See more` headings like `Overdue` are rendered again with the same ID causing a duplicate key error.
<img width="754" height="194" alt="image" src="https://github.com/user-attachments/assets/0eba65e0-0bf2-4f64-a997-27a25e5de5fe" />


**Solution:**
- Use the `line_index` instead of `line.id` as the key, ensuring a unique key for every line and preventing the traceback.

**opw - 5083894**

Forward-Port-Of: odoo/enterprise#95103

## [FIX] l10n_cz: prevent error with misaligned accounting date and sequence number of demo moves

#### Description of the issue/feature this PR addresses:
Editing CZ Company address while having demo data throws Validation Error

#### Current behavior before PR:
When trying to change address of CZ Company while l10n_cz with demo data is present an error popup is displayed and it's not possible to to save the changes. Steps to reproduce:
 - Install l10n_cz with demo data
 - Open CZ Company in form view
 - Change address (e.g. change city Praha -> Brno)
 - Click Save

#### Desired behavior after PR is merged:
The address changes are saved without any error.

#### Solution:
This change adds `taxable_supply_date` date values for CZ demo moves that are compatible with `invoice_date` values to make sure that accounting date values are the same on each recomputatation and do not lead to new sequence numbers that are not aligned with the previous ones which would cause errors being raised by sequence mixin.

Related to: #226152







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

Forward-Port-Of: odoo/odoo#227847

Description of the issue/feature this PR addresses:

This commit fixes the issue where the pickup location does not get set even though it is present on the checkout page. This happens when the user directly adds an item to cart without specifying the pick up location before adding to cart. This results in the location not being set but at the checkout page, the default pick up location appears as one of the warehouses given the way the default pickup location is set when loading the checkout page values.

This makes the user think that the pickup location is set, but when they try to go to the pay page, an error is thrown saying the pick up location was not specified. This commit sets the pickup location data in such a case.

[This commit] refactored the way in which the default location would be set on the checkout page but did not take into account the possbility that the customer might not select the pickup location when they are adding to cart, thus only rendering the value at the checkout page but not actually setting it.

Refactored the test cases to avoid the redundancy in the setup process.

Steps to reproduce on runbot:
1. Set the pick up in store as the default delivery method by updating the sequence
2. Go the shop on the website and add any item to cart which has stock in the specified pickup location, but don't select the pickup location here
3. Go to the cart and click checkout
4. The default pickup location will be set here
5. Click on Confirm
6. An error will appear saying the location was not set

opw-4954187

[This commit]: https://github.com/odoo/odoo/commit/1d3942c75e59ac9538d112df43b4e39f2462fee4

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

## Issue:
For employees with flexible working hours, when a Public Holiday is added, the timesheet was filled with 8h based on the company’s default calendar instead of the employee’s flexible schedule

## Cause:
When creating `resource.calendar.leaves`, timesheets call `_work_time_per_day()`
This method uses `work_hours_data` containing half-day intervals (tmp_start/tmp_end)
These data come from `_attendance_intervals_batch()`, but we were passing an empty resource, so the check for `flexible_hours` failed:
https://github.com/odoo/odoo/blob/bd7d5fdf8df3a4d544de3e2493cd4b3966fa7d0b/addons/resource/models/resource_calendar.py#L382-L393
We want to use the calendar itself as the calendar resource to get the `work_hours_data`

## Steps to reproduce:
- On an employee, in Work Information, set the Working Hours to Flexible 40 hours/week
- Modify Flexible 40 hours/week (Hours per Week: 30, Average Hour per Day: 6)
- In Time Off > Configuration > Public Holidays, add a New holiday (You can leave default values)
- Go in Timesheets > All Timesheets, before the fix, the flexible employee have 8h in internal for Time Off

opw-4881758

Forward-Port-Of: odoo/odoo#225876

**Issue**
When importing an XML invoice of document type TD01, it is incorrectly assigned type TD05 after processing.

**Steps to Reproduce**
1. Install Accounting, l10n_it and l10n_it_edi
2. Go to Accounting > Vendors > Vendor Bills
3. Upload an XML invoice with TD01 as the document type
4. Upon confirming the bill, observe that the document type is incorrectly set to TD05

**Root Cause**
The document type matching logic fails to assign TD01 because the uploaded invoice has move_type = in_invoice, while TD01 was only configured to match out_invoice. https://github.com/odoo-dev/odoo/blob/7436e8cee2f605c6d5d559cb410e7a3dc8f372b9/addons/l10n_it_edi/models/account_move.py#L886-L891

**Fix**
According to Italian e-invoicing specifications, TD01 applies to both sales and purchase invoices ("Fatture di vendita" and "Fatture d’acquisto"). To reflect this, in_invoice is now added to the list of supported move_types for TD01, allowing correct detection during XML import.

opw-4931438

Forward-Port-Of: odoo/odoo#219310

**Issue**
When the delivered quantity of a product is less than the originally demanded quantity, the generated Delivery Guide XML shows the demand (product_uom_qty) instead of the actual delivered quantity (quantity). This results in an incorrect quantity being displayed in the DTE.

**Steps to Reproduce**
1. Install the Accounting module, Chilean localization, Sales module, and l10n_cl_edi_stock.
2. Create and confirm a new Sale Order.
3. Click on the Delivery smart button.
4. Adjust the delivered quantity to a value lower than the demand, save, and validate with no backorder.
5. Generate the Delivery Guide.
6. Open the generated DTE XML and observe that the quantity is incorrect.

**Root Cause**
The quantity displayed in the DTE is taken from product_uom_qty, which represents the planned quantity to be moved, not the actual delivered quantity. The correct field to use is quantity, which reflects the real delivered amount.

**Fix**
Change the XML output to use quantity instead of product_uom_qty to accurately reflect the actual delivered quantity in the DTE.

Opw-4892276

Forward-Port-Of: odoo/enterprise#89633

**Before**
- the active_test context key is part of the main base_automation
  action (base_automation_act), but this context key stays in the
  context further, leading to unwanted filtering in i.e. the
  action_server_ids.resource_ref search view dialog.
- Steps to reproduce:
  - have base_automation installed
  - create an automation rule targeting the res.users model
  - add an Update server action targeting the Partner field
  - in the resource_ref autocomplete, click on Search More...
  - the search view dialogs displays archived records

**After**
- we chose to instead have a default filter in the base_automation_act
  action to include archived records by default. As the context key
  to activate the default filter starts with 'search_default_', it
  is already cleared from the context when opening the form view
  (standard behavior).
- when you reproduce the same steps as before, the archived records
  are no longer displayed in the search view dialog.

**Additional Note**
This fix requires to upgrade the base_automation module.

opw-4886487

Forward-Port-Of: odoo/odoo#225146

If a fiscal position is not related to any tax, when selecting said fiscal position in the pos, the tax from the product is kept. When looking at the paid order in the backend the tax is removed on the order line and the price unit and price with taxes are different (although no tax recorder on the line).

Steps to reproduce:
-------------------
* Create a fiscal position and assign no tax to it
* On the pos config, add this fiscal position and the domestic one to the available fiscal positions
* Open pos session
* Select a product that has a 15% tax
* Change the fiscal position to the one just created
> Observation: We still see that the tax is computed based on the 15%
* Pay the order
* Go see the order in backend
> Observation: price unit: 100, no tax, price with taxes 115

Why the fix:
------------
A recent refactoring happened on the accounting side related to fiscal positions: https://github.com/odoo/odoo/commit/9a97157920c845120861dda49d81d3150e015974

https://github.com/odoo/odoo/blob/e284dfd80bde632e6446fc0b8d3276689da35200/addons/account/models/partner.py#L155-L163

The behavior after this refactoring is the following: When changing fiscal position:
- If the original tax is available for the fiscal position, we use it
- If the original tax is not available but the fiscal position has an available tax that is set to be replacement for the original one, we use the replacement tax
- If the original tax is not available but the fiscal position has an available tax which is NOT a replacement for the original one, we keep the original one
- If the fiscal position has no tax available, we remove the tax

In this fix we apply the same logic inside the pos.

Without the fix we would keep the original tax in the frontend but when passed in the backend the tax with fiscal position was recomputed with the logic from accounting. This explained the difference we observed.

opw-4978056

**Steps to reproduce:**

- Installed industry_fsm (Field Service) module
- Navigate the menu Field Service -> Configuration -> Project
- Create a new project
- Then Navigate the menu My Tasks -> Tasks
- Create a new task with the new created project
- Then using the keyboard shortcut ctrl + k for command search, an error occurs

**Cause:**
- When the `stage_id` statusbar had no possible values,
`this.getAllItems()` returned an empty array.
- The command `isAvailable` unconditionally accessed
`this.getAllItems().at(-1).isSelected`, which is undefined,
causing a crash.[see](https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/fields/statusbar/statusbar_field.js#L147-L148)

**Fix**
- Add safe check in the command action so it does not attempt
to select a non-existent "next" item.

**Result**
- The command palette no longer crashes when the `stage_id` field has no
available items. Instead, the command is simply unavailable.

opw-5084130
upg-3130405


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#228130
Forward-Port-Of: odoo/odoo#227440

Issue:
---------------------------------
When a serial-tracked product has a quantity-type quality point and a check is failed, the system incorrectly marked it as passed.

Steps to reproduce:
---------------------------------
- Install the `quality_control` module.
- Create a quantity-type quality point for a serial-tracked product and a receipt operation type.
- Do not set a failure location on the quality point.
- Create a receipt for the serial-tracked product with 3 units.
- Assign serial numbers to the receipt.
- Perform the quality checks:
  * Pass 2 checks
  * Fail 1 check
- Result: all checks are marked as passed.

Cause:
---------------------------------
When a quantity-type quality check without a failure location is failed, the `do_fail` method directly calls `confirm_fail`. In this method, `qty_failed` was set to 0, which caused the system to treat the failed check as if all quantities had passed.

Fix:
---------------------------------
Ensure that `qty_failed` is correctly set in this case, so failed checks are properly recorded. This allows the quality control flow to behave as expected and gives users accurate results for passed and failed quantities.

Description of the issue/feature this PR addresses:
When doing online payment in POS, customer may take some time and the POS may go to idle state. This causes when it goes to idle and back to alive, it will direct to the first screen.
Steps to reproduce:
- Create POS & setup POS online payment (use Demo online payment)
- Open POS, add a product, go to payment screen, select the online payment method
- Let it go to idle state (triggered by useIdleTimer)
- Move the cursor, or at least make it back to active state
- You'll see the screen be redirected to first screen
- Do the payment, it will redirect to TicketScreen with empty order info, and when you click new order the previous one is still hanging there

Alternatively take a look at the recording:
https://github.com/user-attachments/assets/b8e8ae81-df04-41e0-b122-002413714735

Current behavior before PR:
- Because it bounces to first screen, when attempting payment the pos does not have the order state 

Desired behavior after PR is merged:
- Do not redirect if in payment screen, so that order context won't be lost

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

Forward-Port-Of: odoo/odoo#205249
Forward-Port-Of: odoo/odoo#202220