This update incorporates the National Bank of Kazakhstan as a currency provider, aligning with local regulations. This change ensures Odoo Enterprise can accurately handle financial transactions within Kazakhstan, meeting compliance requirements. It’s a necessary step for businesses operating in that region.

This PR adds the National Bank of Kazakhstan as a provider in order to meet the requirements of the Kazakhstan code.

Task-4144725

Forward-Port-Of: odoo/enterprise#107797

This update adds a visual icon for the AI app within the Odoo platform. This ensures consistent branding and improves the user experience across Odoo.com and other Odoo applications. It’s a small, cosmetic change that enhances visual clarity.

Adding svg icon to ai app in order to use it on odoo.com

task-5431654

Forward-Port-Of: odoo/enterprise#107302

This update adds high-resolution icons for various Odoo apps, enhancing the visual appearance of the /brand-assets page on the Odoo.com website. These new icons provide a more polished and professional look for each app, improving the overall user experience.

Adding new icons formats to apps for the /brand-assets page on odoo.com

Forward-Port-Of: odoo/enterprise#103024

This update adds five new, more generic deduction types to the Odoo Enterprise payroll system for China (l10n_ch_hr_payroll). This improves the system's flexibility and accuracy in calculating employee salaries, particularly for diverse deduction scenarios. A new test has been implemented to ensure these deductions are correctly calculated.

5 more generic AVS is added to l10n_ch_hr_payroll/hr_salary_rule_data and /hr_payroll_input_types.

task - 5902593

Forward-Port-Of: odoo/enterprise#106218

This update enhances the functionality of global filters by now explicitly including the operator within default values. It also prevents users from changing the operator without providing a value, ensuring data consistency and reducing potential errors. This improves the overall reliability of global filter configurations.

## Description of the issue/feature this PR addresses:

Current behavior before PR:
- Global filters could store default values, but the operator was not explicitly handled or preserved.

Desired behavior after PR is merged:
- Global filter default values now include an operator.
- Changing the operator without values is prevented with a validation message.

Task: [5850422](https://www.odoo.com/odoo/project/2328/tasks/5850422)

This update enhances the internal organization of Odoo's IoT driver code by clearly defining the types of key objects used. Making the `Interface` class abstract improves code clarity and maintainability. This change supports ongoing development and future enhancements to the IoT functionality.

To ease development, we typed `drivers`, `iot_devices`, and `interfaces` objects.

This commit also makes `Interface` inherit from ABC in order to make it clearer that it's abstract.

see odoo/odoo#236772

This update simplifies how holiday accrual plans are configured, making it clearer that users can reset accrued time without it carrying over. The changes remove confusing options and always display the date for resetting accruals, improving the user experience and reducing potential misinterpretations.

Description of the issue/feature this PR addresses:
. When configuring an accrual plan, users may want no carry-over of accrued days, while still ensuring that accrued balances expire or reset on a specific date (for example, at the allocation start or on a fixed annual date).
. This task aims to make the configuration explicit, intuitive, and self-explanatory, without changing the underlying behavior.

Current behavior before PR:
The UI implicitly ties the ability to set an expiry/reset date to enabling carry-over, which misleads users into believing that this is a functional limitation in v19.0. In reality, the system supports this behavior, but only through a non-intuitive configuration that forces users to enable carry-over and then mark it as lost at a milestone.

Desired behavior after PR is merged:
. Remove can_be_carryover boolean field with accrued_gain_action selection
. Always show the carryover_ date selection field
. Hide carry-over options in case of lost accrued time

task-5468596

This update ensures that unpublished badges across the Odoo website modules are now consistent, aligning with recent community changes. This improves the overall user experience and maintains a unified brand image for our website.

Following the changes in community, the goal is to make unpublished badges consistent across website modules.

task-5136516

Related: https://github.com/odoo/odoo/pull/239842

This update enhances the survey results displayed in spreadsheets by adding a 'status' column to indicate the response state. It also includes a style update to the survey results table for better readability. This improves the clarity and usability of survey data reporting.

Wiht this commit, the `ODOO.SURVEY` function also returns a new column with the state of each survey response in the spreadsheet results.

It also adds a table to improve the style of the survey results in the spreadsheet.

Task: [5908771](https://www.odoo.com/web#id=5908771&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)

This update fixes an issue where reports displaying multiple companies would stretch the layout and cause text wrapping. The company list is now positioned at the top of the report, preventing layout distortion and ensuring a cleaner, more readable display for users.

Before this commit:
- The list of selected companies was placed on the same row as the report column headers.
- When multiple companies are selected, this causes the report layout to stretch to the full screen width forcing the text to wrap and increasing the height of the header cells due to the table structure.

After this commit:
- The selected companies list is now positioned at the top of the report.
- The company list now only consumes the space computed for the report layout, preventing unnecessary stretching.
- Once the available width is reached, the list wraps naturally without affecting the report header row.

task-5249439

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

This update removes outdated and unused CSS styles related to displaying 'no content' messages across various Odoo modules. This cleanup improves code organization and reduces potential conflicts, ensuring a cleaner and more efficient user experience. The changes also address a conflict between generic and custom 'no content' classes.

In this PR we remove the overrides which extended `%o-nocontent-empty-document` which has been dropped in the PR of the same name in the community repo.

task-5136210

Community PR:

This update removes an unused parameter ('next_groupby') from Odoo's report engines, streamlining the configuration and improving efficiency. The change also eliminates redundant checks within the engines, resulting in a cleaner codebase. This improves maintainability and performance.

We removed count_rows which used the next_groupby by using a custom engine where they specify their next_groupby directly instead.

Since next_groupby isn't used anywhere else in the engines, we can remove this parameter (for the engines)!

Also removed redondant calls to _check_groupby_fields in custom engines where it would be called by _compute_formula_batch_with_engine_custom before calling the function.

task-5145246

Forward-Port-Of: odoo/enterprise#97085

This update simplifies the point-of-sale display by removing the 'With Cart' value. This value was redundant as the current cart amount was already shown on the main product page. This change improves clarity and reduces potential confusion for users.

In this commit:
----------------
- Removed the "With Cart" value as it was not updating when cart items changed.
The only difference between "With Cart" and "Total Due" was that it included the
current cart amount, which is already clearly visible on the main product page.
Therefore, it was considered redundant and has been removed.

Task: 5885428

This update removes unnecessary URL redirects from Odoo's tour scripts. These redirects were causing delays and were redundant, as the same functionality is handled elsewhere. This change improves the onboarding experience and streamlines tour navigation.

The URL key in a tour's JavaScript file implies a redirect to that URL once the browser opens. If this URL is the same as the one used in `start_tour()` (Python), then it serves no purpose. It's even detrimental because it implies a redirect (and therefore a waste of time). The URL key in the JS file is (for now) only used for onboarding tours. This key will be defined later in the .xml file for onboarding tours.

That's why we're removing the URL keys from the registries here.

This update adds a necessary change to Odoo's template structure in preparation for the upcoming OWL3 release. Specifically, it modifies template variables to correctly target component data using `.this`, ensuring compatibility with the new OWL3 framework. This ensures a smooth transition and avoids potential issues when OWL3 is fully integrated.

In preparation for OWL3, where template variables will need to use .this to target component variables, we add .this to template variables that are targetting the component.

Script PR: https://github.com/odoo/odoo/pull/247965
Community PR: https://github.com/odoo/odoo/pull/249732

task: OWL3 prep - add this. to template variables