This update corrects a calculation error in the Point of Sale system when applying taxes. Specifically, it ensures that the total price displayed accurately reflects the base product price plus the correct tax amount, regardless of how taxes are configured. This fix resolves an issue where tax calculations were inconsistent, leading to incorrect totals.

When a fiscal position maps a tax-included tax to a tax-excluded tax (or
vice versa), the price unit must be adjusted to keep the base amount
consistent. This adjustment was missing in the POS frontend after the
tax computation refactoring in v18+.

Background:
In v17, the computePriceAfterFp method handled this price adaptation:
https://github.com/odoo/odoo/blob/36688ce4dad4b3d508b4fd3d778a06a5a7036408/addons/point_of_sale/static/src/app/store/pos_store.js#L1102-L1133

This method was removed in:
https://github.com/odoo/odoo/commit/ab0bdf019212

The refactoring introduced:
https://github.com/odoo/odoo/blob/0d7e3d4c0ea976e37871ca44a10a442cce7caa85/addons/account/static/src/helpers/account_tax.js#L472-L481

However, the POS module was not updated to call this helper when
preparing base lines for tax computation.

Steps to reproduce: 
1. Create a tax configured as "Included in Price" (21)
2. Create a tax configured as "Excluded from Price" (21)
4. Create a fiscal position that maps the included to the excluded tax
4. Add the fiscal position to a contact
5. Create a product with the included tax, priced at 100
6. In POS, add the contact as the client and add the product
7. Total incorrectly shows 121 (or 100 + tax) instead of 100

Ticket [link](https://www.odoo.com/odoo/project.task/5877918)
opw-5877918

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

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

This update allows for seamless payment matching between parent and child companies within Odoo. Previously, matching was limited to purchase orders; now, it extends to bills, streamlining financial reconciliation across company structures. This enhancement improves accuracy and efficiency in managing intercompany transactions.

On bills, the `purchase_vendor_bill_id` field already allows matching with cross-company purchase orders. This commit extends this behavior to payment matching.

Steps to reproduce:
- Create a child company from a parent company.
- Create a purchase order in the child company.
- Create a bill in the parent company.
- In the bill’s payment matching, the child company’s purchase order should be available.

opw-5416947

This update resolves a bug where syncing an order with point changes could incorrectly trigger processing for all orders, including draft ones. This change ensures that draft orders are not unnecessarily processed, improving order stability and preventing potential errors. It addresses a technical issue impacting order processing reliability.

Before this commit, when a draft order with point changes existed, syncing an order would trigger the post processing of all orders, including draft ones. This could lead to issues.

opw-5370267

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

This update optimizes how Odoo retrieves messages, leading to faster loading times and a smoother user experience, particularly when accessing email activity records. The changes address a previous issue where message access was slow, especially when browsing records multiple times. This enhancement improves overall system responsiveness and efficiency.

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#245744

This update resolves an issue with Spanish tax reporting (l10n_es_reports) related to withholding taxes. Specifically, the system now correctly handles the 'type for 347' field in invoices, ensuring accurate tax calculations and compliance. This change improves the reliability of financial reporting for Spanish businesses using Odoo Enterprise.

- Moves that use withholding taxes should have the `type for 347` unselected and left blank.

Related PR : https://github.com/odoo/odoo/pull/245828

task-5732679

Forward-Port-Of: odoo/enterprise#105597

This update fixes a bug where appointment slots remained available to customers even when a user was marked as being on time off. The fix ensures that unavailable dates are correctly blocked, preventing appointments from being scheduled during a user's scheduled time off. This improves scheduling accuracy and prevents double-booking.

__
## Short functional explanation of the error
When setting a time off for a user, it doesn't prevent customers from selecting an appointment slot during this time off with said user.

## Reproduction Steps
1. Go to Users. Create a user U and a corresponding employee E.
2. Click on the smart button Employee, and in Work Information tab, under Schedule, set the Working Hours as a working schedule you'll remember. Let's call it WS.
3. In debug mode, go to Employees > configuration > Working Schedules. Select the working schedule WS and click on Time Off.
4. Click on new. Give the time off a name, and in the field Working Hours, enter the working schedule WS. As resource, select the employee E.
5. Go to Appointments and click on New. Let the Availability based on Users, and add user U to users. Hit save and preview.

### Expected behavior
The date on which the user has a time off shouldn't be selectable.

### Unexpected behavior
The date is selectable, and the slots a user can select appear as usual.

## Origin of the issue
In the method
https://github.com/odoo/enterprise/blob/99231105268a74b24a396903cecc3699b16121b0/appointment/models/appointment_type.py#L1088
 we only check if the user has a meeting for a time slot,
but no holiday.
This issue doesn't appear if the availability is based on resources: we do check leaves on resource for a given time slot with https://github.com/odoo/enterprise/blob/99231105268a74b24a396903cecc3699b16121b0/appointment/models/appointment_type.py#L1481

__
opw-5419376

This update resolves an issue where accents were unintentionally removed from legal names used in Mexican electronic invoicing (EDI). This ensures accurate recognition of these names by the SAT (Servicio de Administración Tributaria), preventing potential processing errors and compliance issues. The change specifically addresses the 'ë' character, a common requirement for Mexican tax documents.

Previus commit (odoo#95207) removed accents for names including
character ë which indeed its recognized for SAT

opw-5897333

This update resolves an issue where reports would display outdated data while waiting for new variants to load. By preventing the initial display of the first variant, we ensure a smoother and more responsive user experience when switching between report options. This improves report loading times and data accuracy.

Previously, when a report was loading if a variant was selected, it would display the first one when it loaded and display the second one when it loaded.

With this, we wont show the first one as we are waiting for the new one.

To reproduce:
- load the Demo data on the demo company
- Add time.sleep(5) in _get_lines
- load the Generic Tax report and wait for it to load
- click on the Group by: Account > Tax and wait for 3s
- click on the Group by: Tax > Account
- Watch the Account > Tax load and still being displayed for 3s while the Tax > Account variant is loading.

This update standardizes the way time off and absences are recorded and transmitted for payroll reporting in Switzerland (CH). It backports a fix from a previous Odoo release, ensuring accurate and compliant reporting related to employee leave and absence data. This improves the reliability of the ELM (Einmalige Leistungen) transmission.

Backport of https://github.com/odoo/enterprise/commit/f238e04f3f6c39b61d0449a0766809df06eb6980

task-5384297

Forward-Port-Of: odoo/enterprise#101449