Fixed an issue where exporting the Thai Sales Tax Report (xlsx) would fail when using a branch company. The system now correctly looks up tax group information from the parent company when it's not found in the branch, allowing the export to complete successfully.

### Steps to reproduce

* install `l10n_th_reports`
* create a Thai company and its branch
* using the company selector, ensure the current company is the branch company, while selecting both parent and branch company
* open the Thai Tax Report
* attempt to export the "Sales Tax Report (xlsx)"

You should be met with a traceback about a tax group External ID not being found

### Cause

The system looks for an XML ID which is only present in the parent company, while using the branch company

opw-4181071

This update fixes a tooltip positioning issue in the Documents module's search panel. The change aligns the Documents tests with improvements made to the core platform, ensuring the search interface displays correctly and provides better user experience when hovering over search options.

This commit adapts documents tests to changes made in https://github.com/odoo/odoo/pull/180776

This fix restores the date display on receipts for Chilean Point of Sale transactions. Previously, a system update removed the date field, causing receipts to appear without transaction dates. The fix ensures dates are properly shown on all POS receipts for Chilean companies.

When validation an order in a Chilean shop, the date is not show on the receipt.

Steps to reproduce:
-------------------
* Change the company for the Chilean one **CL Company**
* Go to the **Point of sale** App
* Open shop session
* Make and order and validate it
> Observation: The date is not reported on the receipt

Why the fix:
------------
Commit https://github.com/odoo/enterprise/commit/1ce4eaa025426354c640e6e6c69269b1e6b2c7d1 moved the date on receipt in the header for the chilean localization.

Header uses the data from `props.headerData`
https://github.com/odoo/odoo/blob/5f748c9d5731fe2e7e519ee9625da25e2bb219bc/addons/point_of_sale/static/src/app/navbar/cash_move_popup/cash_move_receipt/cash_move_receipt.xml#L6

The date field in `headerData` is computed in `getReceiptHeaderData` https://github.com/odoo/enterprise/blob/923dfe962b714797ee41e8f7beed2cb2d6df7048/l10n_cl_edi_pos/static/src/overrides/models/pos_store.js#L48

However, this commit https://github.com/odoo/odoo/commit/5cb7639160cef5401ada8cdde5a5522d8d29c9a9 removed the field `receiptDate` on the pos order. We thus use the same logic to set the date in `headerData`.

opw-4136943

The Accounting and Benchmark dashboards had a problem where selecting quarterly filters would cause errors because the underlying formulas were only designed to work with monthly data. This fix disables the quarter filter option to prevent users from encountering broken dashboards and ensure the filtering functionality works as intended.

The Accounting and Benchmark dashboards were designed with a global filter working with months.
But when filtering by quarter, everything breaks because formulas do not expect an input such as "Q4/2020".

This commit disable the possibility to select quarters.

Task: 4184088

The eBay module was logging complete API responses at INFO level, which caused excessive log file growth and disk space issues for customers. This fix changes API response logging to DEBUG level, reducing unnecessary log bloat while keeping detailed information available when needed for troubleshooting.

## Description
Currently the ebay module logs as `INFO` the whole content of the JSON response coming from the Ebay API. This can bloat excessively the logs of databases, forcing customers to quickly exceed their disk quotas. We can just log this type of information as a DEBUG log.

## Reference
opw-4192547

Forward-Port-Of: odoo/enterprise#70626

This update fixes the Swiss HR payroll module (l10n_ch_hr_payroll_elm) to properly handle module updates. The change ensures that payslip processing works correctly when the module is updated, preventing potential data inconsistencies or processing errors for Swiss payroll operations.

This fix resolves an issue where only the first bank account could be added to a customer during bank reconciliation. Previously, when reconciling multiple bank accounts with the same customer, only the first account would be saved. Now all bank accounts are properly added to the customer record, allowing businesses to maintain complete banking information for their partners.

Create a bank statement line with:
- Label
- No partner
- Bank Account number [BNK1]
- Amount

Go to reconciliation widget
Reconcile with a manual statement having partner [TEST]
[BNK1] will be added to the bank accounts of [TEST]
Repeat the steaps with another account [BNK2]

Issue: [BNK2] will not be added to the bank accounts of [TEST]

This occurs because, when validating a statement line, we don't
add a new bank account to the partner if there is already one defined


opw-4145124

This fix resolves an issue where completing a repair order would incorrectly duplicate the original return item in the product return list. When ending a repair, the system was mistakenly linking the repair's internal stock movement to the customer's return shipment, causing the returned item to appear twice. This fix ensures repair movements are properly separated from return shipments.

### Steps to reproduce:

- Create a Helpdesk team with the options "Return" and "Repairs"
- Create a product, sell 1 unit and deliver it.
- Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket.
- Create a repair order and mark it as done.

#### > If you go back to the product return, the stock move of the original return appears twice.

### Cause of the Issue:

Clicking on the `End Repair` button of the repair will call the `action_repair_end` with a `default_picking_id` equal to the `picking_id` of the `repair.order` in the context. However, during this call a stock move groing from repair location to the repair location will be created and mark as done for the final product to be assocaited with the repair order:
https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L379-L382 https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L417-L442 https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L444-L449 Since no `picking_id` is specified in its `move_vals`, the default `picking_id` (that is the return) will be added to the vals of the create here:
https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/odoo/models.py#L4564 So that the newly created move will be linked to the return move even thought this makes no sense.

opw-4159779

This update fixes the IoT (Internet of Things) integration in the manufacturing shop floor system, enabling proper communication with IoT devices like cameras and sensors. The changes allow workers to scan workorder barcodes and use IoT equipment for quality checks, improving the efficiency and accuracy of the manufacturing process.

Make ShopFloor use IoT

task: 4017327

This fix corrects an error where the system was using the wrong XML template (from Trial Balance instead of Chart of Accounts) when uploading account data to the Mexican tax authority (SAT). This was causing cryptography errors during the submission process. The fix ensures the correct template is applied for Chart of Accounts submissions.

Está tomando el xlst de balanza de comprobación en lugar del xlst de catalogo de cuentas. Me genera error de criptografía al subir al sat el catálogo de cuentas

Fixed a bug in the manufacturing shop floor where the Quality Checks button would remain visible and cause an error when clicked after quality checks were already completed. The issue was that production data wasn't being refreshed properly on screen. This update ensures the system always displays the most current production status, preventing users from attempting duplicate quality checks.

## Steps to reproduce:
1. Create a quality control point for the operation type Manufacturing
2. Create a manufacturing order and plan it
3. Go to the Shop floor
4. Register the production & do the quality checks
5. The Quality Checks button is still there; clicking again displays a traceback because the quality checks are already done.

## Before this commit:
Upon reloading the production, the new data is not propagated to `this.record`.

## After this commit:
Change `this.record` to a getter so it always contains the correct reference to the record.

opw-4176393