This update introduces support for JoFotara's Point of Sale (POS) system within Odoo. It allows for the generation of electronic invoices (UBL format) directly from POS orders, streamlining the invoicing process for JoFotara businesses. This enhances integration and simplifies compliance with local regulations.

This commit adds support to JoFotara for pos.order model.

task-4213323


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

Forward-Port-Of: odoo/odoo#243844

This update adds a custom SVG icon for the AI app within Odoo. This improves the visual representation of the AI app on odoo.com, enhancing brand consistency and user experience. It's a small, cosmetic change that improves the overall presentation.

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 five new, more generic AVS (Additional Voluntary Savings) deduction options within the l10n_ch_hr_payroll module. This improves the flexibility and accuracy of payroll calculations for Swiss businesses by allowing for a wider range of savings plans. A new test has been implemented to ensure these deductions are correctly applied.

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 optimizes how Odoo retrieves related data, preventing performance slowdowns that can occur when fetching large amounts of information. By deduplicating data during the fetching process, the system now responds more quickly, especially when accessing multiple related records. This results in a smoother and faster user experience.

Various improvements to avoid non-linear growth of returned values when iterating over prefetches.  Traversing a relational field introduces a duplication factor in the returned values.

`records |= more` is syntactic sugar for `records = records | more`, which does not modify the recordset in place but makes one from scratch.  Therefore the time complexity is not `O(len(more))` but `O(len(records) + len(more))`, which is what makes it quadratic when used in a loop.

Since refactor in https://github.com/odoo/odoo/pull/229057, this quadratic complexity is introduced in the prefetching, too.

Changes:
- Keep same prefetch when accessing a single key as when iterating over a recordset. Small gain and more consistent results.
- When iterating over prefetches, deduplicate at source. Without this, the overhead of the generator can be huge for each returned value, since the same value might be returned many times.

In less trivial cases (like traversing two relational fields and making unions with it), the time speedup is several orders of magnitude.

This update resolves a problem where salary inputs needed to be manually triggered, preventing accurate calculations for advance salary recovery. The update clarifies the process by moving a key function to each salary structure file and removing a redundant file, ensuring correct salary data population.

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

This update corrects a problem preventing wage statements in Switzerland to be properly sent out. The fix addresses an error in the HR payroll module, ensuring accurate and timely delivery of these important financial documents. This improves compliance and reduces potential delays for employees.

Forward-Port-Of: odoo/enterprise#107827

This update significantly speeds up the salary simulation process within the HR system. By adding an index and avoiding unnecessary image calculations, the simulation now runs much quicker – nearly five times faster. This improves the user experience and reduces the time spent configuring employee salaries.

Description
-----------
Add missing index on `hr.expense.employee_id` as it's used in a few places as a transitive dependency.

Avoid computing images for new employee versions during simulation, as it's loading external dependencies, incurring a performance cost.

Benchmark
---------
On a staging database, opening the salary configurator and clicking on 'Simulation' when selecting a new car took:

| Timings for        | Before | After  | Speed up |
|--------------------|--------|--------|----------|
| `onchange_benefit` | ~750ms | ~160ms | 4.6x     |
| `update_salary`    | 2.3s   | 1.1s   | 1.9x     |

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

Forward-Port-Of: odoo/odoo#241901

This update streamlines the process of generating salary simulations by introducing a standardized context manager. This ensures consistent setup and teardown of necessary operations, reducing potential errors and improving the reliability of the simulation process. It also enforces correct usage of required context keys.

Description
-----------
Getting an `hr.version` from an `offer` during simulation is done in
a savepoint, preceded and followed with flushing of the environment
and some post-cleanup. This is verbose and error-prone, as it's done
at each call site of `hr.contract.salary.offer._get_version` and
`hr.version._generate_salary_simulation_payslip` (or any other
future method that may require such a savepoint). These methods have a
comment that mentions *requiring* a savepoint to be called, but
nothing is enforcing it, so a bug due to oversight is bound to
happen. Context keys are also injected a bit everywhere like
`salary_simulation` and `tracking_disable`, without much consistency,
and adding to the visual clutter.

This commit introduces a little context manager called
`hr_version_context` that manages the creation of the savepoint, the
setup and teardown necessary, and the setting of the keys in the
context.
It's accompanied by a decorator `@requires_hr_version_context` that
will fail if the caller didn't use `hr_version_context` before
invoking the marked method.

This ensures:

- Correct creation of the savepoint and its related pre-/post-operations
- Apply context keys consistently
- Ensure methods that require such setup *cannot* be called without it.

Forward-Port-Of: odoo/enterprise#103187

This update resolves an issue where closing a POS session would fail if the partner's address (street or postal code) was missing. Previously, an empty address caused an error, now the system gracefully handles this situation, ensuring POS sessions can be completed without interruption. This improves the reliability of the German POS certification process.

Before this commit, if a POS order was created with a partner that had an empty street or postal code, the system would raise an error when closing the POS session.

opw-5897334

Forward-Port-Of: odoo/enterprise#106300

This update fixes a discrepancy in accounting calculations within the Point of Sale (POS) for Mexican tax reporting (l10n_mx_edi_pos). Previously, the POS wasn't correctly processing assets, leading to inaccurate amounts. This change ensures that POS transactions align with the calculations performed in Python, guaranteeing accurate financial reporting.

Before this commit, the needed assets were not correctly loaded in the POS, which caused the amounts to be different from the ones computed in python.

opw-5935191

Forward-Port-Of: odoo/enterprise#107657

This update ensures that orders are accurately synchronized across our system after a payment (online or terminal) is added or removed. Previously, removing an online payment didn't properly update the server, leading to inconsistencies. This fix resolves that issue, guaranteeing accurate order data.

Before this commit, if an order had a terminal payment and an online payment was added accidentally, and then get removed, the terminal payment would get removed from server, while it won't be removed from the UI, resulting in a mismatch between the server and the UI, and the order would no be synced correctly.

opw-5911699

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

Forward-Port-Of: odoo/odoo#248430

This update resolves several issues impacting the Odoo Profiler's reliability, specifically related to thread management and data collection. The fixes ensure the profiler consistently collects accurate data without errors or delays, improving debugging and performance monitoring.

Multiple fixes for the Profiler.

Issues:
- Python throws cannot join current thread when using the entry count with memory and traces async profilers.
- The periodic profilers were waiting the full amount of the sleep before ending.
- When using the entry_count, the memory profiler was throwing a non serializable object error
- Sometimes the memory collector throws an error that the tracemalloc needs to be started so that it collects.


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

Forward-Port-Of: odoo/odoo#232551

This update resolves an issue where Odoo was incorrectly including an UETR tag in ISO 20022 payment files, causing rejection by strict banks. The change ensures compliance with SEPA regulations, preventing errors and guaranteeing successful payment processing for our European users. This improves compatibility with major banking systems.

In Odoo 18.0, when a user selects the pain.001.001.09 format (ISO 20022), Odoo systematically includes the <UETR> (Unique End-to-end Transaction Reference) tag for every transaction. While valid under the general ISO 20022 XML schema, the <UETR> tag is not authorized by the EPC (European Payments Council) within the standard SEPA Credit Transfer (SCT) Rulebook. Strict banks (e.g., UBS, German banks) reject the entire file with errors such as: "No child element is expected at this point" when an UETR is detected in a domestic or intra-SEPA flow.

Task: 5871528

Forward-Port-Of: odoo/enterprise#106537
Forward-Port-Of: odoo/enterprise#105518

This update ensures the checksum for the l10n_eu_iot_scale_cert module remains consistent with recent changes in the core Odoo system. This alignment is a routine maintenance task to guarantee data integrity and proper functionality of this specific certification process. It's a minor adjustment that doesn't impact users directly.

This PR merely adapts the l10n_eu_iot_scale_cert checksum to align with the changes in the PR https://github.com/odoo/odoo/pull/248855

This update prevents users from selecting multiple accounts simultaneously during the online synchronization process. Previously, users could inadvertently select multiple accounts, leading to potential data inconsistencies. This change ensures accurate and reliable account selection, streamlining the synchronization workflow.

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

This update resolves an error that occurred when opening 'Sales Order Items' from projects without a linked customer. The fix prevents the system from crashing by disabling the creation of sales orders in these scenarios, ensuring smoother project management workflows.

Currently, an assertion error is raised when opening "Sales Order Items" from a project without a customer.

**Steps to Reproduce:**
- Install `sale_project` module with demo data.
- Create a new project using "Sale Order" project template.
- Do not set a customer on project.
- Project > Task (Kanban) > Show _Top Menu_ > Show _Sales Order Items_.
- Click "**Sales Order Items**".

Video Ref: https://drive.google.com/file/d/1xgYHZBvIt5Ep9Gt-wALGIb9f7mj4NPh_/view?usp=drive_link

Error: AssertionError

**Cause:**
The sale order line depends on `default_partner_id` from the context to create a sale order when none exists. When the project has no customer set, this value is missing, causing an assertion failure.

**Fix:**
This commit returns the list view of SOLs and disables the creation when no partner is set for the project.

sentry-7220116560

This update resolves a bug where vertical videos would lose their orientation after a page was saved and reloaded. The fix ensures that the correct video layout (vertical) is maintained when a video is set to vertical and the page is saved. This improves the user experience for video content on our website.

Problem:
When setting a video to vertical and saving the page, the alignment is not preserved after reload.

Cause:
`generateVideoIframe` always sets the `media_iframe_video_size` class, even for vertical videos. As a result, the vertical configuration is lost after saving.

Solution:
Apply `media_iframe_video_size_for_vertical` when the video is marked as vertical, so the correct layout is preserved after saving.

Steps to reproduce:
- Drop a Video snippet on a page.
- In the selector, enable the vertical option.
- Add the video.
- Save the page.
- Observe that the video is no longer vertical.

opw-5941900

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

This update fixes a bug that occurred when attempting to cancel a Point of Sale order with no items. The fix ensures the system handles empty orders gracefully, preventing errors and improving the user experience. The button to cancel orders is now disabled when no items are present.

Steps:
---
- Open a Restaurant session.
- Open a table with no order.
- Click the control button and click Cancel Order.

Issue:
---
- A traceback occurs when cancelling an order.

Cause:
--
- The order is cancelled first, and then `isSelectedLineCombo` tries to access the current order, which is already null.

Fix:
---
- Safely check for the selected order before accessing combo data.
- Disable the Cancel Order button when there are no order lines.

task-5934004


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

This update addresses an error that occurred when creating invoices with negative tax factors. The issue stemmed from a filtering process within the accounting module that resulted in an empty list, causing a system error. To ensure smooth invoice creation, we've reverted the recent changes that introduced this problem.

Steps to reproduce:
- Install `account` module
- Taxes > open any existing tax > Set `factor_percent(%)` of repartition lines to negative(eg: [Image](https://www.awesomescreenshot.com/image/58851592?key=ce0017bb467a583ad020f33d21d4d8ba))
- Create a Invoice and add tax in move line and save

Traceback:
`IndexError: list index out of range`

We are getting `factors` as empty because `target_factors` from `_add_accounting_data_to_base_line_tax_details` is empty.

This happens because, in `tax_reps`, we are filtering repartition lines with a `factor` greater than `0`. However, when the `factor` is less than `0`, `tax_reps` becomes empty, which leads to the error.

We are reverting this PR: https://github.com/odoo/odoo/pull/234334 because it prevents the validation error from being raised when there is a negative value in the repartition lines.


[factors]: https://github.com/odoo/odoo/blob/de056cc784a3bbe2575fd3c9e81ca62e73c362d4/addons/account/models/account_tax.py#L1641

[tax_reps]: https://github.com/odoo/odoo/blob/de056cc784a3bbe2575fd3c9e81ca62e73c362d4/addons/account/models/account_tax.py#L2429-L2431

sentry-7102210210

Forward-Port-Of: odoo/odoo#249220

This update ensures Odoo's Mexican payroll (l10n_mx_hr_payroll) correctly complies with Mexican Social Security Law regarding minimum wage deductions for IMSS, ISR, and subsidies. The changes automatically adjust payroll XML output to accurately reflect these exemptions, improving payroll accuracy and reducing potential compliance risks.

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 minor error in the account return processing logic. The incorrect configuration of check codes was resolved, preventing unintended record processing. While previously shielded by a safeguard, this change ensures accurate return handling going forward.

the check codes to ignore was wrongly defined, leading to contain records instead of 'code', plus having the exact opposite of what it was supposed to contains, i.e. codes that aren't supposed to be run at the current state of the return. However, it didn't have any impact functionally because it was "protected" by the function _should_run_checks(), which might disapear in the future.

Forward-Port-Of: odoo/enterprise#107158

This update resolves an issue where formatting links in the HTML editor would create duplicate links and incorrectly apply styles. The fix ensures links are treated as single units, wrapping selected text in a `<font>` tag for formatting, and addresses related issues with color classes and block splitting to improve formatting consistency.

Before this commit: when formatting partially a link, the link is split
at the selection and formatted. This causes duplicated links.

After this commit: we consider links are unsplittable, thus formatting
on links will wrap the selected part in a <font> tag.


commit 2: 
[FIX] html_editor: solve infinite loop of links with color class
Before this commit: we have a fix https://github.com/odoo/odoo/commit/96bc421d30f34a8bfc10dde93c2f283809a8a3e3
which to be able to remove the style classes in the link element

After this commit: We don't consider the style class in the link element
as `hasColor`, because the style classes come from the template code,
which is hard-coded xml. Removing them, the user won't be able to add it
back. For example, on a product page, edit the `Terms and conditions`
link, do nothing and save, the muted color is forced removed.

Note that another fix https://github.com/odoo/odoo/commit/f5fc55f19f89041c8391ff81b127ffce0898f89f is also
removed cause it was a fix for https://github.com/odoo/odoo/commit/96bc421d30f34a8bfc10dde93c2f283809a8a3e3.
The tests belonging to https://github.com/odoo/odoo/commit/96bc421d30f34a8bfc10dde93c2f283809a8a3e3 are
adapted, and those of https://github.com/odoo/odoo/commit/f5fc55f19f89041c8391ff81b127ffce0898f89f are kept
as future safeguards of list coloring.


commit 3:
[FIX] html_editor: extra check on targetnode when splitting blocks
Before this commit: we only check if the current block to be split is
splittable, but not the target node.

After this commit: if the current block is splittable but the current
target node is not, we won't split the block but insert a <br>


commit 4:
[FIX] html_editor: properly fill inlineAncestors when formatting
Before this commit: when the parent node of the current node is
unsplittable, the `inlineAncestors` stays empty.

After this commit: we handle this case and push the parent node in the
list when the parent node is fully selected. We also add a fully
selected predicate in link_plugin for the case when the selection
includes all the content (except for zws) of a non-button link


task-5244810


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

Forward-Port-Of: odoo/odoo#249294
Forward-Port-Of: odoo/odoo#241871

This update introduces support for JoFotara's Point of Sale system within Odoo. It allows for the generation of UBL (Universal Business Language) invoices and credit notes directly from POS orders, streamlining the invoicing process for JoFotara users. This enhancement ensures compliance with local regulations and improves data exchange with accounting systems.

This commit adds support to JoFotara for pos.order model.

task-4213323


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

Forward-Port-Of: odoo/odoo#243844

This update adds more flexible options for calculating AVS (Additional Voluntary Savings) deductions within Odoo's payroll system for Swiss businesses. The changes improve the system's ability to handle various AVS deduction scenarios, ensuring accurate payroll calculations. A new test has been implemented to verify these updated rules.

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 resolves an issue where clicking 'View' on certain activity types (like 'Eat cookies') in the calendar view would cause an error. The fix ensures that activities without a linked model can now be opened correctly, improving the user experience and preventing unexpected errors.

Steps to reproduce
=================
1. Go to “View all activities”.
2. Switch to calendar view.
3. Click on an activity not linked to any model
(e.g. “Eat cookies”, “Send Email to Alfred”).
4. Click “View” in the popover.
=> Traceback

Reason
======
The commit [1] allow activities without a linked model and from commit [2]
such activities can be opened in the activity form view.

In the calendar view, the action is retrieved from the model and executed
using `doAction`. Since the action does not define `views`, and the `doAction`
depends on `action['views']`, an error occurs when the action service attempts
to copy it.

After this commit
==================
This commit fixes the issue by modifying the action returned from `action_open_document`
for non-linked models to include `views`, similar structure used when a model is present.

[1] https://github.com/odoo/odoo/commit/165b060473be8a5d33d62d311f0dc55ed6332d69
[2] https://github.com/odoo/odoo/commit/abeac135b9bb7aec4bcddd84fb0705743297f80d

Task-5857887

This update resolves a technical issue where test runs were repeatedly generating assets, consuming unnecessary resources. By adding a specific asset bundle to the test generation process, we've eliminated this redundancy and improved the efficiency of our automated testing.

During tests runs, lazy loaded assets are generated on the fly, and eventually multiple hundred of times (i.e. +/- 150 times on runbot).

This commit adds the `web_studio.studio_assets` bundle to the pregeneration list to avoid regenerating during tests runs.

Forward-Port-Of: odoo/enterprise#107147

This update resolves an issue preventing the correct automated sending of wage statements for Swiss payroll customers. The fix ensures that these important documents are reliably transmitted, meeting regulatory requirements and improving the accuracy of payroll reporting. This impacts users relying on automated wage statement generation and delivery.

Forward-Port-Of: odoo/enterprise#107827

This update adds a warning message to the invoice batch wizard when the automated invoice sending cron job is disabled. This ensures users are alerted if their invoices won't be sent automatically, preventing potential delays or missed payments. It's a simple improvement to enhance user awareness and operational efficiency.

When the Cron responsible of sending the invoices asynchronously is disabled, the user has no clear indication that his invoices won't be sent as they should. Let's add a warning in the batch wizard that notify the user something is wrong.

task-none (feedback from SBR)

Message when no rights to update cron:
<img width="990" height="328" alt="image" src="https://github.com/user-attachments/assets/1100ef6f-d047-49f2-bd8f-c8ef9fd543d8" />

Message when admin:
<img width="999" height="308" alt="image" src="https://github.com/user-attachments/assets/28e90295-d225-4785-82a9-65be3ce79621" />

Forward-Port-Of: odoo/odoo#249191
Forward-Port-Of: odoo/odoo#248994

This update fixes a problem where orders would become misaligned between the system's backend and the user interface after a terminal payment and online payment were added and removed from an order. The change ensures that online payments are properly deleted from the server, resolving synchronization issues and preventing incorrect order data. This improves data consistency and order accuracy.

Before this commit, if an order had a terminal payment and an online payment was added accidentally, and then get removed, the terminal payment would get removed from server, while it won't be removed from the UI, resulting in a mismatch between the server and the UI, and the order would no be synced correctly.

opw-5911699

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

Forward-Port-Of: odoo/odoo#248430

This update grants the Invoicing & Banks group within the enterprise version of Odoo access to essential reports, specifically 'Statement Reports'. This enhancement provides these users with improved visibility into their financial data, streamlining reporting processes and supporting better decision-making.

In enterprise, we are allowing the Invoicing & Banks group to have access to basic reports, including 'Statement Reports'

task-5925567


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

Forward-Port-Of: odoo/odoo#249006

This update resolves an issue where Invoicing and Banks users were unable to access certain basic reports. The change adds necessary security permissions, allowing these users to view key reports like partner ledger and aged receivable/payable, improving their reporting capabilities.

* Revert commit https://github.com/odoo/enterprise/commit/86c3c212bb79fbc2becac46f4d83b6f2fc381854 that introduced having Accounting features, menu items, and Account on invoice lines available for Invoicing users.
* Allow Invoicing & Banks group to access basic reports
* Backport missing access rights to properly open the reports without an access error.

task-5925567

Forward-Port-Of: odoo/enterprise#107654

The Time Off Balance report was incorrectly calculating remaining days due to how it aggregated allocations across different periods. This fix ensures accurate reporting by prioritizing allocations based on their start date, resolving discrepancies when employees have multiple allocations.

The balance report aggregates allocations regardless of the period in which they occur resulting in wrong information when an employee has two allocations in different periods and a filter is used in the report

Steps to reproduce:
1. Install Time Off app
2. Open Time Off app and go to Management > Allocations
3. Create a new allocation of 100 days for employee "Mitchell Admin" of time off type "Paid Time Off" with a validity period from 01/01/2027 to 31/12/2027 and approve it
4. Activate debug mode
5. Go to Time Off > Reporting > Balance
6. The number of days left for "Mitchell Admin" for "Paid Time Off" is 120 days even though the default filter is on the period of 2026

Solution:
Refactor the entire query: we order the allocations by date_from so we can subtract taken leaves from the allocations in that order

opw-5156142

Forward-Port-Of: odoo/odoo#245860

This update optimizes the HTML editor's performance by reducing unnecessary layout recalculations. Specifically, the code now prioritizes reading layout information before making changes to the DOM, leading to a smoother and faster editing experience. Additionally, frequent updates have been throttled to prevent UI overload.

Description of the issue this PR addresses:

I. The power buttons positioning logic was interleaving DOM writes and layout reads during selectionchange, causing repeated style/layout recalculations. This PR reorders the logic so geometry is read first and DOM mutations are
applied afterwards, reducing the number of forced reflows and significantly improving performance.

II. Debounce `updateHints` and `updatePowerButtons` to avoid excessive UI updates on frequent selection changes. Introduce `debounceHints` and `debouncePowerButtons` editor config options so debouncing can be disabled in tests for deterministic behavior.

III. Introduce READ helper for withSequence to explicitly order resource handlers so DOM reads run before DOM mutations.

Before:
<img width="1705" height="399" alt="image" src="https://github.com/user-attachments/assets/2fca797a-0311-4c4a-9063-2051934baa7c" />

After:
<img width="1490" height="343" alt="image" src="https://github.com/user-attachments/assets/0f295969-b962-4190-a7f9-fe5366d7fafd" />


task-5499625

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

This update resolves an issue where attendee registration answers were not being saved correctly during the Point of Sale (POS) process. The fix removes a redundant field from the data loaded during POS transactions, ensuring that all registration answers are accurately recorded. This prevents lost information and improves the reliability of the POS system.

In [1], a refactoring of the POS framework was done, but in the process some overlooked behaviors induced a complete loss of the answers given in the registration process, as long as they do not include an answer to a 'selection' question.

STEPS
=====

0. Create a new event with a few questions (no 'selection' one)
1. Add tickets so that you can buy one in the POS
2. Go in the POS (reload data if needed)
3. Buy a ticket and fill the attendee form (answer to all questions)
4. Continue the POS flow and pay for your ticket.
5. Go back to the back-end and event > attendees
6. Check your new attendee: no answers are linked to the record.

ISSUE
=====

TLDR - Two fields have the same comodel on event.registration. This breaks the use of inverseMap as both are loaded in the pos. As they are treated sequentially when connecting related records, hidden side effects occur when both are not set.

Details:

This effect is due to two main issues. First, after [1], we compute the whole model reference relations using processModelDefs method, that accounts for inverse relations of o2m, m2o fields and provides an inverseMap to be used in several places, notably on creation or deletion of relational records from the POS.

However, pos_event presents a peculiar situation, as registrations have two o2m fields, both loaded in _load_pos_data_fields, that are linked to the model event.registration.answer: registration_answer_ids and registration_answer_choice_ids, a subset of the first, just with a domain to only include answers of 'selection' questions.

Meaning that the inverseMap will only use one of the two, in this case registration_answer_choice_ids. In turn, this means that any update of registration_id on the answer model will update that field, even if the original update was done on registration_answer_ids...

Secondly, one could notice that this should still work, as the inverseMap is used in all places, we should just update the records through the field registration_answer_choice_ids.

So why does it not work and why are all answers removed? Because both fields are loaded in _load_pos_data_fields, and in _sanitazeRawData we use getFields to know which fields to update and to connect (for relations on the model), both being returned.

This means that independantly of the create values for the registration in addProductToOrder in pos_event, the 'framework' will still have two fields to connect and will do so sequentially, one field at the time.

But in the _connect logic, if a field has no value given at creation, then the 'CLEAR' command is used, as this would mean we remove the content of the relational field. But in this case, this means that as both answer fields try to update registration_id through registration_answer_choice_ids, if no value is given at creation in that field, then we clear existing ones, for instance those we just linked through the creation values in the first field registration_answer_ids, as we basically empty registration_id on those records. The answers will also be deleted of the indexedDB because of the condition in databaseTable (no linked registration -> can be removed)

FIX
===

Remove registration_answer_choice_ids from the loaded data, as it is not used anywhere except in the registration creation values. As it is a subset of the other field registration_answer_ids, only keep that one instead. Update the creation values to only use that field.

Note that this seems to highlight a limitation when it comes to having more than one o2m field on a model loaded at the same time in POS.

[1] odoo/odoo@a80a39f2ad16baf474553574c79d55948f86c453

Task-4919080

This update corrects a bug where high-priority applicants weren't appearing at the top of the applicant list in the Recruitment module. The fix reordered the sorting logic to ensure that applications with the highest priority are displayed first, improving the efficiency of the recruitment process. This change was made to enhance the user experience and streamline applicant review.

Steps to reproduce:
----------------------------------------
1. Install the Recruitment module
2. Navigate to Recruitment > Applications > All Applications
3. Go to Kanban view
4. Make any application Very High Priority (3 star)
5. Refresh the page

Observation:
----------------------------------------
Applications marked as Very High Priority are not displayed on top, Applicants with higher priority should be displayed first within the same stage.

Issue:
----------------------------------------
The `_order` attribute on the applicant model is declared twice, causing the intended priority-based ordering to be overridden by `sequence`. https://github.com/odoo/odoo/blob/6fed805389d878558e4139b270ee7a70269af767/addons/hr_recruitment/models/hr_applicant.py#L28-L41

Solution:
----------------------------------------
Reorder the fields in the `_order` attribute so that priority is applied before sequence, ensuring higher-priority applicants are shown first

opw-5893371

This update resolves an error that occurred when creating invoices with negative tax factors. The issue stemmed from a filtering process within the accounting module that caused an empty list, leading to a technical error. We've reverted the recent change to prevent this validation error and ensure invoices can be created correctly.

Steps to reproduce:
- Install `account` module
- Taxes > open any existing tax > Set `factor_percent(%)` of repartition lines to negative(eg: [Image](https://www.awesomescreenshot.com/image/58851592?key=ce0017bb467a583ad020f33d21d4d8ba))
- Create a Invoice and add tax in move line and save

Traceback:
`IndexError: list index out of range`

We are getting `factors` as empty because `target_factors` from `_add_accounting_data_to_base_line_tax_details` is empty.

This happens because, in `tax_reps`, we are filtering repartition lines with a `factor` greater than `0`. However, when the `factor` is less than `0`, `tax_reps` becomes empty, which leads to the error.

We are reverting this PR: https://github.com/odoo/odoo/pull/234334 because it prevents the validation error from being raised when there is a negative value in the repartition lines.


[factors]: https://github.com/odoo/odoo/blob/de056cc784a3bbe2575fd3c9e81ca62e73c362d4/addons/account/models/account_tax.py#L1641

[tax_reps]: https://github.com/odoo/odoo/blob/de056cc784a3bbe2575fd3c9e81ca62e73c362d4/addons/account/models/account_tax.py#L2429-L2431

sentry-7102210210

Forward-Port-Of: odoo/odoo#249220

This update resolves an issue where Peppol invoices were incorrectly using the wrong company context, leading to data inconsistencies and errors. The fix ensures that invoices are processed with the correct company information, preventing problems with cross-company data and improving data accuracy.

Currently, the created move does not always use the company context of the related move/proxy user. As a result, default values may be taken from another company, which can lead to cross-company inconsistencies and access errors.

Steps to reproduce:
- Set up two companies, A and B
- In company A, configure a default value for the partner.company_id field, applicable only to company A
- When a Peppol invoice arrives for company B but is processed using the context of company A, and a new partner must be created, the partner is created with company A as the default value
- This results in an incompatible companies on record error

This fix ensures that the company context of the move or EDI user is used when creating the move, preventing cross-company issues.

opw-5473233

Forward-Port-Of: odoo/odoo#249145
Forward-Port-Of: odoo/odoo#249059

This update fixes an issue where category images in the Point of Sale selector were too large and would overflow, obscuring the category names. The change adjusts the layout to allocate 1/3 of the space to the image and 2/3 to the name, ensuring a cleaner and more readable display. This improves the user experience for selecting product categories.

Before this commit, when a category image was too large, it would overflow and take all the space dedicated to the category name. Now we set the width of the image to 1/3 of the button and the name to 2/3, so that the image never takes too much space.

task-id: 5462315

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

Forward-Port-Of: odoo/odoo#242515
Forward-Port-Of: odoo/odoo#242054

This update resolves an issue where users could inadvertently assign partners from different companies when managing multiple companies within Odoo. This change ensures that partners are correctly associated with the intended company, improving data accuracy and streamlining accounting processes. It's a crucial fix for reliable multi-company reporting.

Before this commit, it was possible to add a partner that was from another company when multiple companies were selected.

task-5941113

This update resolves a connection issue that occurred when Odoo was configured to use a replica database. The change ensures Odoo automatically uses the primary database port when a replica port isn't specified, preventing connection errors and improving stability. This update is a critical fix for ensuring a reliable Odoo experience.

Start postgres on an alternative port (e.g. 5434), start odoo with `--db_port 5434 --db_replica_host=''`, access /web/database/manager, there's a warning in the logs that says it is not possible to connect to the replica database.

The empty string for the replica host is Odoo 18 way to tell Odoo to simulate a replica database by connecting to the same db as the primary one. It should use `--db_replica_port` and when not set fallback on the same port as `--db_port`. The problem is that in case no `--db_replica_port` is set, the option is set `None` in the config, i.e. `get('db_replica_port', cfg)` was retuning `None` as was not using the fallback.

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

This update resolves an issue where the delivery amount was being calculated twice during Stripe express checkout, leading to incorrect order totals. The fix adjusts how taxes are computed to ensure accurate delivery pricing, particularly when using Apple Pay or Google Pay. This improves the customer checkout experience and prevents financial discrepancies.

Versions:
---
- 17.0+

Issue:
---
Delivery amount is doubled in stripe express payment checkout.

Steps to reproduce:
---
1- Setup a stripe payment express checkout. (In my client case it is apple pay express checkout but we also reproduced it in google pay)
2- Set fixed price on standard delivery: 10
3- Navigate to website: add a product to cart. Use express checkout.

Outcome: The delivery price is calculated twice which is wrong.

Cause:
---
This regression is due to #238574. Once `/compute_taxes` is called, there is delivery lines included in SO. As a result returning `amount_total` will cause `this.paymentContext['minorAmount']` to include delivery amount.
Then we add delivery carrier `minorAmount`:
https://github.com/odoo/odoo/blob/469220cde82ecebf4a59451cc1325add6bfc3e69/addons/payment_stripe/static/src/js/express_checkout_form.js#L188-L196 Which cause delivery amount be added twice.

Fix:
---
We could exclude delivery amount from total amount in `express_checkout_shipping_address_compute_taxes`, which is going to calculate the tax for lines excluding delivery lines.

opw-5424398

Forward-Port-Of: odoo/odoo#249340
Forward-Port-Of: odoo/odoo#248415

This update resolves an issue where the 13th month salary wasn't correctly included in the Swiss payroll data transmitted to tax authorities. The change adds the 13th month to the base calculation, ensuring accurate reporting and compliance with Swiss tax regulations. This update is a critical fix for businesses operating in Switzerland.

Forward-Port-Of: odoo/enterprise#107908

This update adds more flexible options for calculating AVS (Additional Voluntary Savings) deductions within the Odoo Enterprise payroll system. Specifically, five new generic AVS deduction types have been implemented to provide greater flexibility for businesses. A new test has been added to ensure these deductions are calculated correctly.

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 streamlines testing within the Odoo Enterprise platform by resolving an issue where test patches were causing errors. The team has converted specific patches to use a standard method, improving the reliability and stability of the testing process. This change ensures more consistent and accurate test results.

Otherwise they trip the on-test-side-effect-detector (at least in its current incarnation).

Forward-Port-Of: odoo/enterprise#106948

This update resolves a potential issue where global invoices from the POS system in Mexico could fail to send correctly to the SAT portal. Increasing the timeout for communication with the SAT portal helps prevent errors and duplicated documents, ensuring accurate invoice processing. This improves the reliability of the system for Mexican businesses.

**Fix:**
Increase the read timeout for POST requests to SW sapien PAC. It may prevent timeout issue when sending a global invoice from the POS with a lot of POS orders that could lead to duplicated documents on the SAT portal when retrying to send the global invoice again.

opw-5347962

Forward-Port-Of: odoo/enterprise#107735

This update resolves an issue where test runs were repeatedly generating unnecessary assets, slowing down the testing process. By adding a key asset bundle to the test preparation list, we've eliminated redundant generation and significantly improved test performance. This ensures faster and more reliable testing of the Odoo Enterprise platform.

During tests runs, lazy loaded assets are generated on the fly, and eventually multiple hundred of times (i.e. +/- 150 times on runbot).

This commit adds the `web_studio.studio_assets` bundle to the pregeneration list to avoid regenerating during tests runs.

Forward-Port-Of: odoo/enterprise#107147

This update corrects a problem preventing wage statement files from being properly sent to the Swiss tax authorities (ELStax). The fix ensures accurate and timely submission of these crucial documents, complying with Swiss tax regulations. This resolves a potential delay in tax reporting for businesses using the Odoo Enterprise module.

Forward-Port-Of: odoo/enterprise#107827

This update fixes an error in how holiday pay is calculated for employees in Belgium with non-standard working schedules. Previously, the system incorrectly deducted holiday pay based on a default 38-hour week. Now, the calculation accurately reflects the employee's actual working hours, ensuring correct pay adjustments.

**Steps to Reproduce:**
1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee
3 - Set 2000 euros in recovery amount holiday n-1
4 - Set 10 days in recovery day holiday n-1
5 - Employee takes 5 paid time off in February and 5 in December 6 - Do one payslip for this employee for February  and validate it 7 - Do one payslip for this employee for December

Current behaviour :
- the holiday n-1 amount for February = 824.80
- the holiday n-1 amount for December = 742.32

Expected behaviour :
- the holiday n-1 amount for December should be 20.62 (hourly_rate) * 5 (days) * 8 (hours) = 824.80

**Reason**
- The daily recovery amount was calculated using hardcoded standard working hours (38h/week) instead of the employee's actual schedule (40h/week), causing an incorrect deduction rate for non-standard schedules.

**Solution**
- Replace the hardcoded reference with the actual hours per week from the employee's resource calendar to ensure the correct hourly rate is applied.

Forward-Port-Of: odoo/enterprise#107740
Forward-Port-Of: odoo/enterprise#106205

This update fixes an issue where OCR-extracted expense amounts were incorrectly converting to USD, forcing a 1:1 exchange rate. The change ensures that expense amounts are accurately converted to the company's default currency based on the system's exchange rates, improving the reliability of financial reporting.

Steps to reproduce:
1. Initialize an expense with a foreign currency (e.g., EUR).
2. Trigger OCR extraction on a receipt with a specific total.
3. Observe that both 'Total In Currency' and 'Total' (USD) are set to the same value.
4. The exchange rate is forced to 1.0, ignoring the system's exchange rate.

Cause:
The _fill_document_with_results method assigned the OCR total to both 'total_amount_currency' and 'total_amount' as a placeholder. This triggered the field's inverse logic during the write() call, causing Odoo to treat the input as a manual exchange rate override of 1:1.

Solution:
Remove the 1:1 placeholder assignment. The method now explicitly calculates 'total_amount' using the _convert() helper once the currency is identified, ensuring the company currency total reflects the actual system exchange rate.

opw-5437611

Forward-Port-Of: odoo/enterprise#107534

This update streamlines the process of creating salary offers by introducing a temporary popup wizard. This wizard guides users through essential data entry, provides real-time salary simulations, and offers convenient actions like email sending. The changes enhance the user experience and reduce the initial information overload.

Before this commit, clicking "Generate Offer" on an Employee or Applicant redirected the user to the full form view of `hr.contract.salary.offer`. This disrupted the user flow and presented too many fields initially.

This commit improves the UX by introducing a transient wizard (`hr.contract.salary.offer.wizard`) that opens in a popup.

Key changes:
- **Wizard Implementation**: A new popup allows quick data entry for essential fields (Contract Template, Job Title, Dates, Wage).
- **Wage Logic**: Users can toggle between defining "Monthly Gross" or "Yearly Employer Cost", with automatic bidirectional conversion based on the selected contract template.
- **Simulation Preview**: The wizard displays a real-time salary simulation (Gross, Net, Benefits, Company Cost) computed dynamically using the payroll engine without creating persistent records.
- **Action Buttons**: Added "Send by Email", "Copy Link", and "Salary Configurator" actions directly to the wizard footer.
- **Sign Template Logic**: The PDF Sign Template is no longer mandatory. If missing, the signatory logic is skipped to allow pure simulations.
- **Expandability**: Added an "Expand" button to the wizard header to allow users to transition to the full offer form view if needed.
- **Applicant Integration**: The wizard pre-fills data (Salary Expected, Availability) from the Applicant record.

task-5088948

This update streamlines the way AI Documents sends notifications within Odoo. The team replaced a specific function call with a new, more efficient method, improving the underlying system. This change enhances the stability and performance of the AI Documents module.

This commit replaces the uses of `self.env["bus.bus"]._sendone()` by `_bus_send()` in the `ai_documents` module. Following https://github.com/odoo/enterprise/pull/90124#discussion_r2822278385

This update corrects a bug that prevented users from successfully testing new printer configurations within the Point of Sale module. The fix ensures that the printer's IP address is correctly updated when using the 'test printer' button, resolving a previous error. This improves the reliability of the Point of Sale system.

When creating a new printer and test it with the test printer button, it will cause an error because the field of the ip address in pos.printer has changed and it was not changed into the test button.

Bug : allocate a number of holidays that is not an integer (ex : 20.5), then check the holiday attest (shows 20 allocation). The same problem happens if the number of leaves taken is not an integer Steps : - in the belgian company, create a new employee with a valid contract give an employee 19.5 days of Time Off type leaves. - on the form view of the employee , click on the action button -> Departure: Notice period and payslip -> and fire the employee. - now click on action button

Bug : allocate a number of holidays that is not an integer (ex : 20.5), then check the holiday attest (shows 20 allocation).
      The same problem happens if the number of leaves taken is not an integer

Steps : - in the belgian company, create a new employee with a valid contract give an employee 19.5 days of Time Off type leaves.
	- on the form view of the employee , click on the action button -> Departure: Notice period and payslip -> and fire the employee.
	- now click on action button -> Departure: Holiday Attests, you'll see that the employee has 19 allocated instead of 19.5

Reason :  The number of leave_allocation_count and leave_count are defined as integers in HrPayslipEmployeeDepatureHolidayAttestsTimeOffLine, when they are populated, they end up casting the assigned value to an int.

Fix : Create two new float fields leave_count_float and leave_allocation_count_float to replace their corresponding integer fields.

task - https://github.com/odoo/enterprise/commit/5461268c9411d36feac90cd45dcff42aab59599b

Forward-Port-Of: odoo/enterprise#103258

This pull request updates the event management system by running a binding script. The changes involve minor adjustments to XML files within the event and timesheet modules, streamlining the process for event registration summaries and animation transitions. This update ensures consistent event data handling.

This update includes essential tests for the HR Expense Stripe module, addressing a previous oversight in the project's development. The tests ensure the module functions correctly and reliably, contributing to data integrity and accuracy within expense reporting. This addition improves overall module stability.

Add tests for the module, as it wasn't included in the original task

This update allows users to manage multiple bank statements and reconciliation lines simultaneously, streamlining the accounting process. Previously, users could only handle one statement at a time. This enhancement increases efficiency and reduces manual effort for large-scale reconciliation tasks.

This commit will allow to do the set account, set partner and apply reco models on multiple lines. To select multiple line you need to use alt + click and then you will have button on top to trigger the actions.

- The set partner function was modified to work with multiple statement lines and keep all existing functionality (modify line with same partner_name)
- The trigger reconcile model function was also modified to work with multiple statement lines
- The set account function was not touched because we use the aml_id of the suspense as a parameter but here we will have multiple suspense line to modify. Since we are doing this change in stable, we created a new function set_account_multiple_bank_statement_line. This function will have the same behavior for reco models as the basic set account.

task-5253778

This update ensures Odoo's Mexican payroll system accurately reflects the latest Social Security Law regarding minimum wage exemptions. Specifically, it adjusts calculations for IMSS, ISR, and subsidy contributions when employee earnings are at or below the minimum wage, streamlining XML generation and improving compliance. Existing tests have been updated to align with these changes.

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

A recent issue prevented the appointment module from being correctly reinstalled, resulting in installation errors. This update resolves the problem by temporarily skipping the generation of email invitation URLs during the installation process, preventing a key lookup error. This ensures a smoother and more reliable module reinstallation experience.

Reinstalling the appointment module fails during mail template validation.

### Reproduction Steps

1. Install the `appointment_hr_recruitment` module.
2. Uninstall `appointment`.
3. Reinstall `appointment`.

→ A template parsing error appears.

### Cause

The global `request.env` is bound to the registry active at the start of the request. When reinstalling a module, this registry becomes stale and does not include the models being re-added.

During installation, the `mail.template` model performs a test render to validate its XML data. One of the templates calls `_get_interview_invite_url`, which invokes a controller that looks up the `appointment.type` model using `request.env`.

Because the registry is stale and does not contain this model, the lookup raises a KeyError and the installation fails.

### Fix Rationale

Skip invite URL generation when `install_mode` is set to avoid using the stale `request.env`.

opw-5898780

Forward-Port-Of: odoo/enterprise#107650

This update enhances the accuracy of payment reference checks by tailoring the validation process to the bank account's country. Previously, a single check applied to all countries could lead to incorrect validation. Now, the system verifies the reference format against the specific country of the bank account, with a fallback for unsupported countries.

Currently, when initiating a payment, we check if the reference is a
structured one by using `is_valid_structured_reference` which checks
the validity of the structure accross all supported countries.

This can lead to issues when it matches formats accepted by other
countries but not the one of the bank account.

With this commit, we replace this check by a call to a new function that
checks the structure validity according to the country of the bank account,
with a fallback to the generic check (ISO 11649) if the country is not supported.

opw-5387269

Forward-Port-Of: odoo/enterprise#107721
Forward-Port-Of: odoo/enterprise#107116

This update resolves an issue where DHL shipping rate calculations failed when requested for dates outside of DHL's business hours. Adding a 'next business day' flag ensures rates are accurately calculated, preventing errors and ensuring reliable shipping options for customers. This addresses a previous technical problem impacting shipping functionality.

Before this commit, there was an issue when trying to get the rates for DHL shipping late in the day. The issue happened because `plannedShippingDate` fell outside of the working hours.

This commit adds the nextBusinessDay flag for the rating request to avoid the error.

Error:
```
Product not found 996: The requested product(s) not available
for the requested pickup date. Process ID associated for this
transaction')
```
opw-5393684

Forward-Port-Of: odoo/enterprise#107153

This update resolves a potential issue where global invoices sent from the POS could fail due to timeouts when interacting with the SAT portal. Increasing the timeout duration for these requests helps ensure invoices are successfully transmitted, preventing duplicate documents and improving the overall reliability of the Mexico tax filing process. This addresses a reported problem impacting users in Mexico.

**Fix:**
Increase the read timeout for POST requests to SW sapien PAC. It may prevent timeout issue when sending a global invoice from the POS with a lot of POS orders that could lead to duplicated documents on the SAT portal when retrying to send the global invoice again.

opw-5347962

Forward-Port-Of: odoo/enterprise#107735

This update ensures payslips accurately reflect an employee's start date with the company, regardless of internal job changes. Previously, payslips used the contract start date, which was inaccurate for long-term employees. This change, primarily impacting payroll in Switzerland and the UAE, provides a more precise and reliable view of employee tenure.

In the payslip definition, the current contract's start date is used. But if a person changes job or contract internally we don't want this value to change and we want it fixed to when the person joined the company. Notably, if a person worked at the same company in two well distinct periods, we want to consider the beginning of this period and not of the previous one(s).
Since Switzerland uses a custom report for the payslip, the same change is applied there.

Task: 5909637
Community PR: https://github.com/odoo/odoo/pull/248598

Forward-Port-Of: odoo/enterprise#106692

This update resolves an issue where email generation for equity transactions would fail due to a mismatch in record identification. The fix corrects a configuration error in the email template, ensuring accurate email delivery when multiple equity transactions are processed. This prevents disruptions to communication regarding shareholder updates.

## Issue Before This Commit

A missing record error occurred during email generation when the number of
`equity.transaction` records exceeded the `res.partner` records.

## Cause of the Issue

The issue was caused by an incorrect `model_id` configuration in the
`equity_shareholder_email_template`. This created a mismatch between the
template model and the record context passed to the mail compose wizard,
leading to a missing record error during template rendering.

## With This Commit

The template `model_id` has been corrected `equity.transaction`. This ensures that the 
mail compose wizard receives
the correct model context and prevents missing record errors during
email generation.

Steps to reproduce : [Video](https://drive.google.com/file/d/19WXbjmYPKh0IjQHcEGU4FdUbGSF4GGlx/view?usp=drive_link)

opw-5899070

This update ensures the 'first_contract_in_company' field always reflects the employee's earliest contract start date, regardless of how contracts are created or modified. Previously, this date was only calculated during a manual archive process, leading to inaccuracies. This fix automatically updates the date whenever a new contract or version is created or changed, improving reporting and payroll accuracy.

Version-19.0

**Issue**: Field `first_contract_in_company` was only set by the archive wizard, which is too late.
                We need that information at other places too.
                
### What This PR Does
This PR restores the reliable computation of the employee's first contract date by:
- Computing the earliest contract start date across all versions of the employee.
- Automatically updating the `first_contract_in_company` field whenever:
        1. A new contract is created
        2. an existing version changes it start date, or 
        3. an existing version is deleted for the employee.

### Technical Summary
**Update the first contract date on create/write**
- when an hr.version is created or updated, it will recompute the employee's earliest
  `contract_date_start` across all versions.
- The update is performed in `_compute_first_contract_in_company()`, which:
       1. fetches all the active versions of employee
       2. filter those having `contract_date_start`
       3. Computes the earliest start date.
       4. Updates `employee.first_contract_in_company` accordingly.

**Result**
The field `first_contract_in_company` is now always accurate and reflects real employee history.

This update resolves a technical issue where test runs were repeatedly generating assets, slowing down the testing process. By adding a specific asset bundle to the test preparation list, we've eliminated this redundant generation, improving test efficiency and stability. This change ensures tests run more smoothly and reliably.

During tests runs, lazy loaded assets are generated on the fly, and eventually multiple hundred of times (i.e. +/- 150 times on runbot).

This commit adds the `web_studio.studio_assets` bundle to the pregeneration list to avoid regenerating during tests runs.

Forward-Port-Of: odoo/enterprise#107147

This update corrects a display issue where archived employees were still visible in the attendance Gantt chart. The change ensures that only currently active employees appear in this view, improving data accuracy and clarity for HR reporting. This resolves a previous bug reported by our team.

Steps to reproduce:
1. install `hr_attendance_gantt`
2. create an employee
3. make attendance records for the employee in the previous months
4. archive the employee

When opening the gantt view of the attendance, a row appears for the archived employee, with no attendance showing up.

This commit adds a constraint to only show the active employees.

opw-5490119

Forward-Port-Of: odoo/enterprise#106486

This update corrects a problem that prevented wage statements in Switzerland from being properly sent out. The fix ensures accurate and timely delivery of these important financial documents, complying with Swiss regulations. This resolves a previous error impacting payroll reporting.

Forward-Port-Of: odoo/enterprise#107827

This update resolves a crash that occurred when using the pivot table autofill feature with invalid data. The fix ensures that the autofill process itself functions correctly, while preventing subsequent tooltips from causing a system error. This improves the reliability of pivot table data manipulation.

If you try to autofill a pivot cell that has an invalid relational id in its domain (eg. `=PIVOT.HEADER(1, "stage_id", 99999999)`), the autofill actually works but the tooltip make everything crash.

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

Forward-Port-Of: odoo/enterprise#107715
Forward-Port-Of: odoo/enterprise#106601

This update fixes a bug where discounts on subscription orders were unintentionally reset when an upsell was added. Previously, confirming an upsell would erase the original subscription discount. This change ensures discounts are correctly applied across both the subscription and any subsequent upsells, improving order accuracy and customer satisfaction.

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

This update resolves a problem where kiosk transactions would unexpectedly disconnect, leading to lost sales. It also improves the user experience by providing clearer error messages when issues occur during these transactions. This ensures smoother operation for self-order kiosks.

This PR fixes the scneario when the terminal transaction times out during kiosk request.

It also adapts the error messages shown to the user whenever an error occurs
community: https://github.com/odoo/odoo/pull/249101
task-5946033

This update automatically calculates and transmits the 2050 pension contribution amount for employees in Switzerland. This ensures accurate compliance with Swiss tax regulations and avoids potential errors in payroll processing. The change corrects a previous issue related to the calculation of this specific contribution.

task-5166226

Forward-Port-Of: odoo/enterprise#103856
Forward-Port-Of: odoo/enterprise#103453

This update fixes an issue where cash rounding wasn't applied consistently when customers deposited money via card. The change now respects configured cash rounding settings, ensuring accurate calculations for deposits regardless of the payment method used. This improves the reliability of financial reporting.

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. Open PoS, select a customer, and select "Deposit Money". Choose
   "Card"
3. Enter an amount non divisible by 0.05, say 2.26

-> Notice that the change is rounded, and is -2.25 instead of -2.26.

Why it's happening
------------------
It's a correct bahvior to always round the `change` when paying a normal
order, since change is what we return to the customer, and it's usually
in cash.

However, when depositing money, `change` represents what the customer is
paying us (depositing in his account). That amount could be deposited in
any payment method not only cash.

The fix
-------
When depositing money, we check if we should round the change or not
using the `orderIsRounded` getter. It takes into account the current
chosen payment method, and if we should round for this payment method or
not (could be cash, card, etc).

opw-5222985

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

This update adds support for JoFotara's Point of Sale system within Odoo. It enables the generation of UBL (Universal Business Language) invoices and credit notes directly from PoS orders, streamlining the invoicing process for JoFotara users. This enhancement improves integration and reporting capabilities.

This commit adds support to JoFotara for pos.order model.

task-4213323


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

This update fixes an issue in the barcode picking interface where adding multiple extra products triggered a confusing, repeated confirmation dialog. Now, the dialog opens only once and allows users to easily select and deselect products before confirming the addition, streamlining the picking process.

When adding extra products in the barcode picking interface, the confirmation dialog did not handle correctly the scan of multiple extra items.

Before:
Scanning multiple extra products successively opened (mutex + promise) the dialog multiple times. The user had to confirm/cancel each extra product addition one by one.

After:
The dialog is now only opened once and updated when scanning multiple extra products before confirming. The user can select/deselect the extra products to add before validating.

[opw-5193269](https://www.odoo.com/odoo/project/49/tasks/5193269)

This update resolves an issue preventing custom address fields from being added to event registration forms. By adding a type check, the system now allows for greater flexibility in custom module overrides, ensuring event registration forms can accommodate a wider range of data inputs. This improves the extensibility of the website event module.

Before the addition of identification questions like "name", "email", and "phone" in the commit [1] as event questions instead of having them static, we could add custom data, such as fields for the address, with static inputs in the form. After that addition, it's no longer possible because the registration gives us the following error when trying to convert data that isn't a M2o ID or an Integer value:
  
    invalid literal for int() with base 10

By adding the check for the field's type, we can still add custom fields with static fields in the template, as an alternative, given that there's no question type for other fields.

[1]: https://github.com/odoo/odoo/commit/6b8daa880c

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

A recent update caused a crash when users attempted to undo a duplicated list within the spreadsheet feature. This fix ensures that the undo function correctly handles list duplication, preventing unexpected errors and improving the user experience. This resolves a bug that impacted list management within the spreadsheet.

How to reproduce:
- insert an odoo list in a spreadsheet
- duplicate the list from the sidepanel
- undo with Ctrl+z

-> crash

The command "DUPLICATE_ODOO_LIST" was not supported in the inverseCommand registry.

Task-5943688

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

This update resolves an issue where creating multiple email templates using favorites could lead to errors due to excessive nested HTML elements. The fix prevents unnecessary wrapping of templates, ensuring a smoother and more reliable email creation experience. This improvement enhances the stability of the Email Marketing app.

**Steps to reproduce:**
- Go to Email Marketing app
- Create a new mailing
- Click on empty mail body and add only a Heading block
- Set a subject, save it and click `Add to Templates` (favorites)
- Create another mailing which use the first one as its template
- Repeat the operation multiple times
- Error will be raised at some point due to the depth of the template html

**Issue:**
Unnecessarily nested `div` are created when using favorites to create new `mailing.mailing` records, if those favorites are themselves based on other favorites etc., it later can lead to a recursion error when rendering the template.

**Fix:**
Check if the template comes from the favorites to avoid reapplying the wrappers on it.

This seems to be solved in 19.0 with the refactoring (https://github.com/odoo/odoo/commit/354b8f60dbabcfac690d90bf657592e1347e4f86)

opw-5275187

This update resolves a bug that caused forum posts to fail to create when Odoo was in debug mode. The issue stemmed from incorrect property settings being passed to a key component. By changing 'disabled' to 'isReadOnly', the system now correctly handles forum post creation, ensuring a stable user experience.

Following rewrite in odoo/odoo@33206fd1941ae, this commit update passed props (`disabled` -> `isReadOnly`) to avoid a crash when creating a new forum post while being in debug mode:

`OwlError: Invalid props for component 'WebsiteForumTagsWrapper': unknown key 'disabled'`

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

This update corrects a rounding issue in the stock barcode scanning process, specifically when handling delivery orders. Previously, quantities were being rounded to a less precise value, leading to discrepancies in stock levels. This fix ensures accurate stock updates during barcode scanning, improving inventory management.

To reproduce the issue:
- Create a stock quantity of product1 for example of 275.84 kg in PACK1
- Create a delivery order of 3.6 kg
- Go to the delivery order on stock barcode
- Scan PACK1
- The new line is created as 272.2399999999

This update addresses a technical issue preventing Virtual IoT boxes from downloading handlers correctly. The change restores a secure process by explicitly verifying SSL certificates, ensuring that IoT handler downloads function reliably. This resolves a previous security oversight related to Python's urllib3 library on Windows.

In PR #233423, we rightfully removed `cert_reqs='CERT_NONE'` to enforce secure certificate validation during IoT handler downloads. However, this exposed a blind spot in Python's `urllib3` library on Windows.

Because `urllib3` defaults to the host's underlying certificate list (which is limited on Windows) instead of the installed `certifi` package, Virtual IoT boxes get the following error during handler downloads: `certificate verify failed: unable to get local issuer certificate`

This commit restores the broken flow while maintaining security by explicitly passing `certifi.where()` to the `urllib3.PoolManager` via the `ca_certs` parameter.

opw-5902549

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

Forward-Port-Of: odoo/odoo#249213

This update corrects a discrepancy in payslip calculations for the private car daily allowance. The daily amount is now rounded to two decimal places, ensuring it precisely matches the 'Quantity × Amount' displayed on payslips. This improves the accuracy and clarity of employee compensation information.

Round the computed daily private-car salary rule amount to 2 decimals so the displayed per-day value matches Quantity × Amount on payslips.

References
task-5917569

Forward-Port-Of: odoo/enterprise#106753

This update resolves an issue where tasks remained linked to sales orders even after sales order items were removed. Now, users can properly detach tasks from sales orders, preventing billing issues and allowing for easier task management. This ensures tasks can be accurately billed or re-assigned when needed.

Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one.

**Steps to produce:**
* Install Sales, Project
* Products > Virtual Home Staging > Create On Order > Project and Task
* Create and confirm quotation with that product.
* Tasks > Empty the Sale Order Item Field

**Observed Behavior:**
* Sale Order is still linked to the task despite sale order line has been unlinked from that task.

**Root cause:**
* Compute method [1] only detaches the sale order if the customer has been changed.

**Solution:**
* Only detach the sale order when there are no sale order items and the record
  is not a field service task.
* Field service tasks should always keep the sale order linked so materials can
  still be added to the existing sale order, even when the task is non-billable
  (i.e., no sale order line is linked). This logic is handled by the compute
  override at [2], which reassigns the sale order when needed.

[1]:
https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935
[2]:
https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194

Related Enterprise PR: https://github.com/odoo/enterprise/pull/103487

opw-5215989

Forward-Port-Of: odoo/odoo#241446

This update resolves an issue where tasks remained linked to sales orders even without a related sales order item. Now, users can unlink tasks from sales orders without impacting the ability to bill tasks, particularly for field service tasks where materials can still be added to the existing order. This improves workflow efficiency.

Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one.

**Steps to produce:**
* Install Sales, Project
* Products > Virtual Home Staging > Create On Order > Project and Task
* Create and confirm quotation with that product.
* Tasks > Empty Sale Order Item Field

**Observed Behavior:**
* Sale Order is still linked to the task despite sale order line has been unlinked from that task.

**Root cause:**
* Compute method [1] only detaches the sale order if the customer has been changed.

**Solution:**
* Only detach the sale order when there are no sale order items and the record is not a field service task.
* Field service tasks should always keep the sale order linked so materials can still be added to the existing sale order, even when the task is non-billable (i.e., no sale order line is linked). This logic is handled by the compute override at [2], which reassigns the sale order when needed.

[1]:
https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935 
[2]
https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194

Related community PR: https://github.com/odoo/odoo/pull/241446

opw-5215989

Forward-Port-Of: odoo/enterprise#103487

This update resolves an issue where test runs were repeatedly generating unnecessary assets, slowing down the testing process. By adding the 'web_studio.studio_assets' bundle to the pregeneration list, tests now run more efficiently and reliably. This improves overall development speed.

During tests runs, lazy loaded assets are generated on the fly, and eventually multiple hundred of times (i.e. +/- 150 times on runbot).

This commit adds the `web_studio.studio_assets` bundle to the pregeneration list to avoid regenerating during tests runs.

Forward-Port-Of: odoo/enterprise#107147

This update resolves an incorrect reliance on Peppol BIS3 constraints within the RO and HR EDI modules. Previously, an unnecessary dependency caused issues with sending invoices, particularly to physical persons. This fix ensures proper functionality and alignment with standard EDI formats.

The CIUS RO and CIUS HR depends on the BIS3 which is fundamentally incorrect. This was probably made out of lazyness to redefine things that are almost the same in both these CIUS and the BIS3.
Now, in previous PR [1], we added contraints for the Peppol BIS 3 that are impacting those formats. Indeed, the EndpointID can be empty in the context of CIUS RO and CIUS HR. In particular, it's breaking the sending to physical person at the moment.

[1]: https://github.com/odoo/odoo/pull/246961

opw-5943698

This update resolves an issue where tests interfering with model registration caused lookup failures and incorrect data retrieval. The change ensures more reliable model identification by using string lookups instead of class names, preventing potential mismatches and improving system stability. This enhances the overall robustness of the Odoo platform.

Followup to #247151 after community report that if a test swizzles the model in the registry, looking models up by class leads to a lookup failure and a fallback to the default attributes set, and an almost certain mismatch as a result.

This update enhances the speed and accuracy of searching within the Web Studio module. The change refines how search indexes are created, now prioritizing indexing by model name instead of class. This results in faster and more relevant search results for users.

This update corrects a validation issue with invoices generated using the facturae module in Spain. Previously, the system was generating XML invoices with excessive decimal places (up to 8), causing validation errors with e-Fact systems. This change ensures that currency amounts are rounded to two decimal places for Euro invoices, complying with Spanish tax regulations.

Steps to reproduce:
- Have facturae modules installed
- Generate invoice with any amount
- Send to Facturae

Issue:
Resulting XML has 8 digits after the decimal point on several fields, such as unit price, gross amount, and total cost.

When trying to validate such an XML, this results in validation error: "RCF06001: En facturas emitidas en euros, alguno de los importes de las líneas tiene más de dos decimales (regla 6a del anexo II de la Orden HAP/1650/2015)."

According to regulation HAP/1650/2015 [1]: For invoices issued in euros, it will be validated that the total line amounts related to the total cost are numeric and rounded, according to the common rounding method, to two decimal places.
This commit introduces dynamic decimal precision: 2 places for EUR and 8 places (the previous default) for other currencies.

[1] https://www.boe.es/diario_boe/txt.php?id=BOE-A-2015-8844
Machine translated [BOE-A-2015-8844 (1).pdf](https://github.com/user-attachments/files/25345382/BOE-A-2015-8844.1.pdf)


opw-5927356

This update resolves an issue preventing the correct transmission of wage statements for Swiss payroll in Odoo Enterprise. The fix ensures that wage statement data is properly sent, addressing a potential disruption to payroll reporting and compliance. This improves the accuracy and reliability of Swiss payroll processes.

Forward-Port-Of: odoo/enterprise#107827

This update fixes a bug preventing Click & Collect widgets from accurately displaying rental product availability. Previously, the system didn't account for rental periods when calculating stock levels on the website. This change ensures customers see correct quantities and rental periods when browsing rental products through the Click & Collect feature.

Click and collect widget is not supported for rental products

Steps to reproduce:
-------------------
* Enable "Click and collect" in setting and set up warehouses
* Create a rental product
* Add a unit of the product in one of the warehouses
* Rent that product for a period
* Go on the website>shop>the product
* The available quantity for the warehouse does not account for the in start/end dates in the eCommerce product page

Observation:
-------------
The issue is that click and collect and openLocationSelector has no information about he rental periode https://github.com/odoo/odoo/blob/20e54e37670ffa569f47663a7e4b8d7de3a4c33c/addons/website_sale_collect/views/templates.xml#L28-L36 https://github.com/odoo/odoo/blob/20e54e37670ffa569f47663a7e4b8d7de3a4c33c/addons/website_sale_collect/static/src/js/click_and_collect_availability/click_and_collect_availability.js#L54 the rental period is set in the xml file:
https://github.com/odoo/enterprise/blob/1bf7dbcfef2186ee5a08382367fe195efca033dc/website_sale_renting/views/templates.xml#L90

opw-5365564

This update fixes a bug where Click & Collect product availability didn't account for rental periods. Now, the website accurately displays the available quantity of rental products based on their start and end dates, ensuring customers see correct stock levels when browsing and ordering through Click & Collect.

Steps to reproduce:
-------------------
* Enable "Click and collect" in setting and set up warehouses
* Create a rental product
* Add a unit of the product in one of the warehouses
* Rent that product for a period
* Go on the website>shop>the product
* The available quantity for the warehouse does not account for the in start/end dates in the eCommerce product page

Observation:
-------------
The issue is that click and collect and openLocationSelector has no information about he rental periode https://github.com/odoo/odoo/blob/20e54e37670ffa569f47663a7e4b8d7de3a4c33c/addons/website_sale_collect/views/templates.xml#L28-L36 https://github.com/odoo/odoo/blob/20e54e37670ffa569f47663a7e4b8d7de3a4c33c/addons/website_sale_collect/static/src/js/click_and_collect_availability/click_and_collect_availability.js#L54 the rental period is set in the xml file:
https://github.com/odoo/enterprise/blob/1bf7dbcfef2186ee5a08382367fe195efca033dc/website_sale_renting/views/templates.xml#L90

opw-5365564

This update corrects an issue where pick-up point names and addresses were incorrectly capitalized, particularly in Dutch. The fix ensures all pick-up point names and weekday labels are consistently capitalized regardless of the selected language, improving the user experience and data presentation.

Issue:
---
In pick-up point list, the case formatting should be:
1- Pick-up point's `name`, `street` and `city` should not be auto-capitalized.
2- Weekdays should must be always capitalized regardless of language.

Steps to reproduce:
---
1- Create a second Company named `store`.
2- Create a wh for the created company and add the wh to click-and-collect pick-up points. (There should be more than 1 pick-up points)
3- In the website, add Dutch lang.
4- In website, open a product and, open the `Click and Collect`.

Outcome:
---
Name is capitalized to `Store` and the days are not capitalized if you switch to dutch lang.

Cause:
---
Due to CLDR, luxon doesn't capitalize weekdays in some languages.

opw-5941830

This update fixes a bug in the Colombian Daily Journal report that prevented users from searching for transactions. The issue was caused by missing data in the report's search field, which is now corrected to include move names, partners, accounts, and labels. This ensures accurate and efficient searching within the Daily Journal.

Steps to reproduce:
1. Open the Colombian Daily Journal (Libro Diario).
2. Type a move name or partner in the search bar.
3. Observe that no results are returned.

Cause:
Report lines were generated with an empty 'name' attribute. The accounting 
report framework uses this field for client-side filtering. Empty names 
make the search bar non-functional.

Solution:
Populate the 'name' field with move, partner, account, and label data. 
This enables the frontend search bar to match against these strings.

opw-5495558

This update resolves a technical issue that caused tracebacks when opening barcode rule forms within the Stock module. The fix removes a dependency on a parent record, ensuring the form loads correctly and preventing errors. This improves stability and user experience.

Issue before this commit:
=========================
When opening a Barcode Rule form view, a traceback was raised due to the following
python expression: bool(parent.is_gs1_nomenclature or type == 'alias')

Steps to Reproduce:
=========================
- Install the stock module.
- Go to Configuration → Barcode Nomenclatures in the Stock app.
- Open any Barcode Nomenclature form.
- Go to the Rules tab and open a rule (pop-up form view).
- Click on the Expand button.
- A traceback is raised.

Cause of the issue:
=========================
The form view tries to evaluate `parent.is_gs1_nomenclature`, but the `parent` record
is not defined when the rule form view is opened directly (via expand), leading to a traceback.

This happens because the form view is not defined as a child of any parent view,
so no parent context is available, which leads to a traceback.

With This Commit:
=========================
Removed the usage of `parent.is_gs1_nomenclature` and use `is_gs1_nomenclature`
directly instead. The `is_gs1_nomenclature` field on `barcode.rule` is already a
related field to `barcode.nomenclature`, so it can be safely used without relying on the parent.

opw-5949083

This update prevents unnecessary OCR processing on split expenses, which was causing unexpected charges for users with automatic digitization enabled. The fix addresses a bug previously resolved in later versions of Odoo, and ensures efficient use of IAP credits. This change minimizes potential user costs.

OCR should only be performed on the original document. Enabling it on splits leads to redundant OCR requests and unnecessary IAP credit consumption.

This is particularly important when automatic digitization is enabled, as it triggers a paid request for every split generated, leading to unexpected costs for the user.

The same bug was fixed in version 19.0 and up (commit 0688575), but it couldn't be backported as the `split_expense_origin_id` field doesn't exist in version 18.0.

opw-[5930791](https://www.odoo.com/odoo/project/2068/tasks/5930791)

This update simplifies the Spanish accounting module by removing a complex distinction between domestic, intra-EU, and extra-EU sales. The original setup was based on outdated regulations and isn't reflected in current reporting. This change streamlines the accounting process and aligns with current Spanish tax requirements.

I can’t find any explanation for why the sales acounts were originally split into domestic sales (Spain), intra-EU sales, and extra-EU sales.  
It doesn’t look like there is any report that considers this separation anyway.
Reference link: https://www.boe.es/diario_boe/txt.php?id=BOE-A-2013-3781

CLA signed in https://github.com/odoo/odoo/pull/239246
TT59545

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

This update adds more flexible deduction options within Odoo's payroll system for Swiss businesses. Specifically, five new generic AVS (Additional Voluntary Savings) deductions have been implemented to provide greater flexibility in calculating employee contributions. This change improves the system's adaptability to various Swiss payroll requirements.

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

task - 5902593

This update resolves an issue where the default grouping by provider wasn't consistently applied in the Shipping Methods section of Odoo. The fix ensures that when a provider is set to 'default,' the system correctly groups shipments by that provider, improving the user experience and data organization.

**Steps to Reproduce:**
- Got to the Shipping Methods.
- No default group by is applied even when the provider is set to default.

**Issue:**
The default group by was not applied in Shipping Methods despite the provider being set as default, due to a mismatch between the filter name and the default group by name.

**Fix:**
Aligned the filter name with the default group by name so the grouping is applied correctly by default.

**Affected Version:** 17.0~master

This update fixes an issue where payment beneficiary accounts were incorrectly assigned after merging inbound and outbound payments. Specifically, when a refund is merged, the system now correctly identifies the payment type (outbound) and assigns the appropriate bank account. This ensures accurate payment processing and reporting.

When we create new payments for bills and refunds, we offer the possibility to merge inbound and outbound payments together if they are from the same provider and the bills all reference the same recipient account.

Depending on the balance of the resulting payment, we assign an adequate inbound or outbound bank account as the recipient.

The `partner_bank_id` can be assigned through different processes:

- If the wizard has only one batch:

The wizard is editable and the user can select a bank account from the computed `available_partner_bank_ids`.

- If there are multiple batches:

Odoo assigns a `partner_bank_id` in `_create_payment_vals_from_batch()`. For an outbound payment, it uses the batch['payment_values']['partner_bank_id'].

The problem is that this value is not updated after a merge of payments. If the base line being merged on is a refund, but the result is an outbound payment, then the `partner_bank_id` should be changed accordingly.

I decided to include the changes of my previous PR targeting v18 and fixing the grouping of payments, even though it was deemed unnecessary for v17, because it felt weird not to considering how close these fixes are.

-Previous PR : [242863](https://github.com/odoo/odoo/pull/242863)

However, I can remove these changes or re-target this PR to v18. I am not sure what would be best here.

Ticket: opw-5401372

This update resolves an issue where Point of Sale (PoS) was failing to display products with single-attribute-value options (e.g., 'Small' size). The fix ensures that products with unique attribute values are correctly listed in the PoS interface, improving the user experience and preventing lost sales.

Steps to reproduce
------------------
1. Create a product "P", with an attribute e.g. "Size", having only one signe possible attribute value, e.g. "Small".
2. Add it to PoS.
3. In PoS, click the "i" button to show this product's info popup, and click on the "Small" button.

We are supposed to filter out the variants having "Small" attribute value, so we expect to see one product, however, we see NO PRODUCTS.

Reason
------
When clicking the attribute value button, "Small" in this case, we filter for proucts belonging to the product template "Product", which also have "Small" in their names. This assumes that a new product have been created for that "Small" attribute value, however that's not the case, since for single-attribute-value attributes, we don't create a separate product variant. I.e. since we can only have one option for "Size" which is "Small", we don't create a separate prodduct for it.

Fix
----
In the case of single-attribute-value attributes, don't add the attribute name to the search word since no products will be found. Just list all the products from that prodcuct template, they will naturally all match that single attribute value.

opw-5497593