This update resolves an issue where setting up accounting periods for tax returns would fail when the Invoicing module was also installed. The change ensures the necessary setup process runs correctly regardless of which modules are used, improving the reliability of accounting configurations. This prevents potential errors and ensures a smoother setup experience.

To align with the changes introduced in **community PR** [1], this commit moves the `_initiate_account_onboardings()` method in the `account` module to ensure it is executed even when Invoicing is installed.

[1] - https://github.com/odoo/odoo/pull/248790

sentry-7064593163

Forward-Port-Of: odoo/enterprise#107476

This update fixes an issue where changing the Payment Partner in the accounting system didn't correctly update the associated bank partner. The fix removes a restriction preventing the system from saving these changes, ensuring that payment partner selections are reliably saved and reflected after refreshing records.

**Steps to reproduce:**
1. Install Accounting.
2. Go to Return Type.
3. Create a record and set a Payment Partner Bank.
4. Change the Payment Partner.

**Issue:**
Changing the Payment Partner creates a log entry but does not update partner on the selected Payment Partner Bank. After refreshing the record the value is reverted to the previous partner.

**Cause:**
The field payment_partner_id is defined as `readonly` at the model level.
As a result, when the ORM attempts to update this field, the write operation is silently ignored.

Although the field appears editable in the view due to `readonly="0"`, model-level `readonly=True` still prevents the value from being saved.

**Fix:**
Make the field writable at the model level so that ORM updates are persisted,
This ensures that changes to Payment Partner are properly saved and no longer reverted after refresh.

**opw-5423029**

Forward-Port-Of: odoo/enterprise#103041

A bug was causing the total time displayed in the Timesheets list view to be formatted incorrectly after a page refresh. This update ensures the total time is always displayed in the correct time format, regardless of whether the user is viewing the data in a list or grid view. This improves the accuracy and usability of the Timesheets feature.

# Steps to reproduce
- Open Timesheets
- Go to list view
- Refresh page
- Total is formatted as regular float instead of time

# Cause of the issue
The list view uses the `timesheet_uom_timer` widget for the `unit_amount` field. While the row entries were formatted correctly since the widget is added to the fields registry in `timesheet_uom_timer.js`, the aggregate (total sum) is not formatted in the same way because the formatters registry is missing that particular widget.

Switching to the grid view and going back to the list view would solve the formatting. That is because the `timesheet_uom_timer` widget is added to the formatters registry when loading the grid view (in `timesheet_grid_uom_service.js`).

We ensure the formatter is registered globally by patching the `timesheetGridUOMService` outside the grid view context, ensuring consistent aggregate formatting in list view, even after a page refresh.

task-5907954

Forward-Port-Of: odoo/enterprise#107203
Forward-Port-Of: odoo/enterprise#107006

This update ensures Odoo's Mexican payroll system accurately reflects the latest Social Security Law regulations. Specifically, it handles scenarios where employee earnings are at or below the minimum wage, correctly zeroing out related deductions and ensuring accurate XML generation for compliance. This update is crucial for accurate reporting and adherence to Mexican tax laws.

According to the Mexican Social Security Law, when an employee's total monthly earnings (including bonuses and commissions) are equal to or less than the monthly minimum wage (l10n_mx_daily_min_wage * 365 / 12), they are exempt from social security contributions and income tax, also they lost the subsidy benefit.

- The next rules are zeroed out when the gross salary is equal or less  than the minimum wage:
  - IMSS_EMPLOYEE: IMSS Total (Employee)
  - ISR: ISR (Income Tax)
  - SUBSIDY: Used Subsidy
- IMSS_EMPLOYEE and ISR are omitted from the generated XML.
- As the ISR is zero, the `totalDeducciones` attribute on the `nomina12:Nomina` node should be removed.
- The SUBSIDY should be present in the `SubsidioCausado` attribute on the `nomina12:SubsidioAlEmpleo` node, but the `Importe` attribute on the `nomina12:OtroPago` node should be 0.0.

This change requires updates to existing standard tests, as some previous test cases used amounts lower than the minimum wage.

target: 19.0
task-5226971

Forward-Port-Of: odoo/enterprise#104668

This update fixes a problem preventing the correct automated sending of wage statements for Swiss payroll. The issue was resolved by correcting a process within the HR payroll module, ensuring accurate and timely delivery of these important documents. This ensures compliance and provides employees with the necessary financial information.

Forward-Port-Of: odoo/enterprise#107827

This update addresses a recent finding that the SAT now accepts accented characters in tax documents. Previously, the system removed accents to comply with SAT standards. This PR temporarily allows the 'É' character, acknowledging ongoing SAT acceptance of accented names, and will be re-evaluated as needed.

An improvement in September (PR #95207) began removing accents from names in documents sent to the SAT, in order to comply with their own practices.

In recent months, it has become clear that the SAT does accept accents sometimes. First with umlauts on the `ü` in October (PR #96043), then all umlauts in February (PR #106557). As this PR has found another accepted accented character `É`, it may be necessary to undo the original improvment entirely.

The [Anexo 20 Guía de llenado de los comprobantes fiscales digitales por Internet](http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Anexo_20_Guia_de_llenado_CFDI.pdf), pg 17, indicates that accented characters are maintained in legal names. At least, `Í` is allowed. At this point in time I only added the exception for `É`.

Steps to reproduce are [on the ticket](https://www.odoo.com/mail/message/999357619), as it requires a real person's tax information.

[opw-5915515](https://www.odoo.com/odoo/project.task/5915515)

----
*Edit: Miguel (mial) confirmed that names are not always sanitized, but that we expect them to be.*

Forward-Port-Of: odoo/enterprise#107677

This update resolves a problem where salary inputs needed manual triggering, hindering the correct calculation of advance salary recovery. The changes improve the clarity and functionality of salary structure data files, ensuring accurate salary calculations and recovery processes. This fix addresses a technical detail impacting payroll accuracy.

Purpose: the salary inputs have to be manually triggered, which causes issues when it comes to populating the salary input for the advance salary recovery. 

Fix: moved the function `update_properties_definition_domain` to each salary structure data file to be more obvoius and removed `l10n_tr_hr_payroll_data` as the file wasn't in the manifest

task-id: 5912475

Forward-Port-Of: odoo/enterprise#106576

This update prevents users from accidentally selecting multiple accounts during the account synchronization process. Previously, clicking on one account could lead to unintended selections, causing confusion and potential errors. This change enhances the stability and user experience of the account synchronization feature.

Before this commit, it was possible to click on multiple card when doing the account selection from the wizard. This commit will add a disable feature so that when clicking on the card, other account cannot be clicked.

task-5943474

Forward-Port-Of: odoo/enterprise#107637

This update fixes an issue where the system incorrectly rounded amounts when settling customer deposits (payments made via methods other than cash). Previously, rounding was always applied, regardless of the payment method. Now, the system respects cash rounding configurations and only rounds the deposit amount if the chosen payment method requires it, ensuring accurate accounting for all payment types.

Steps to reproduce:
-------------------
1. Enable cash rounding, only for cash payment method
   - Rounding method doesn't matter, I tested with 0.05 nearest rounding
2. In PoS, make an order with the customer account, such that the total amount is not divisible by 0.05, i.e. when rounded, it's not the same amount. For instance, $5.27.
3. Close the session and reopen it, then select that customer, and click settle due
4. Select the Bank payment method, so a NON-Cash payment method.

Notice that the amount is being rounded, even though we have only enable rounding for cash methods. If we take my example of step 2, the amount became $5.25 instead of $5.27.

That is understandable when we settle with Cash, however, for Bank (non-cash), we should not round.

The fix
-------
Now when choosing a payment method to settle due, we also round the amount if needed, in `getTotalDueOfPartner`. Before, we always set the exact amount, regardless of the payment method and the rounding settings.

We now also apply rounding on the payment screen based on the selected payment method. Previously, the change was always rounded whenever rounding was enabled, ignoring whether rounding was restricted to cash methods. This behavior made sense for normal orders—where change is typically given in cash—but not when settling a due amount, since the customer can pay using any method. During due settlement, the change represents the amount the customer must pay, so rounding must follow the rules of the chosen payment method.

opw-5222985

Forward-Port-Of: odoo/enterprise#105368
Forward-Port-Of: odoo/enterprise#100278

This update prevents discounts from being incorrectly reset when an upsell is added to a subscription order. Previously, an upsell would erase the original subscription discount. This change ensures that discounts are accurately applied across the entire order lifecycle, improving the accuracy of pricing and subscription revenue.

Before this commit, the discount of recurring lines in a sub would be reset in the following case:
1) create a sub, add a discount on recurring line
2) invoice the sub
3) create an upsell, add quanitty on the recurring product, change the
   start date of the upsell to trigger computation
4) confirm the upsell

The discount of the parent order was reset.

task-5886270

Forward-Port-Of: odoo/enterprise#105750

This update fixes a bug where inactive accounts were excluded from key financial reports (P&L, Balance Sheet, Accounts Coverage). The change adjusts how the system searches for accounts, now considering both active and inactive ones. This ensures all accounts are accurately reflected in financial reporting.

Purpose: In P&L, Balance Sheet and Accounts Coverage Report, inactive accounts are not considered.

Root cause: `deprecated` field on `account.account` is replaced with `active`, and orm search by default returns only active records.

Solution: add `active_test=False` in the context.

task- 5906024

Forward-Port-Of: odoo/enterprise#106956

This pull request resolves a minor issue within the account reports audit tour, ensuring the tour functions correctly. The fix corrects a problem that was preventing the tour from completing successfully. This update improves the user experience for account reporting.

This update resolves a bug in a test tour for the payroll attendance module. The tour was incorrectly triggering a search that caused unexpected behavior. The fix streamlines the tour process by directly selecting the correct employee, eliminating unnecessary searching and ensuring consistent test results.

runbot-error-id~238494

This update resolves a technical issue that previously caused the AI field cron job to fail. By correctly handling expected exceptions, the cron job is now more reliable and stable, ensuring consistent operation of the AI field functionality. This improves the overall performance and dependability of the Enterprise module.

This commit updates the exception handling to
correctly catch the expected exception.

Task-5894552

This update resolves a bug in the Peruvian reporting module's test cases. A recent change introduced incorrect tax settings into test expense accounts, causing test failures. This commit corrects the default expense account used in tests, ensuring accurate test results and maintaining the integrity of the reporting functionality.

In the community PR for l10n_pe https://github.com/odoo/odoo/pull/240831 , some new expense accounts are added and some existing accounts are modified. This change added default tax to the expense accounts which was being used in test cases for `l10n_pe_reports_lib`. Due to this, a new tax line was added in line_ids, and certain tests were failing since tax line was not at all taken into consideration.

This commit updates default expense account to another account without any default tax for tests.

Task [link](https://www.odoo.com/odoo/project.task/5149253)
task-5149253