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

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

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.