This update fixes an issue where QR code payment links for installment-based invoices were incorrectly showing the full outstanding amount. By using the default values for the payment link wizard, the links now accurately display the next payable installment, ensuring accurate payments.

The link from QR code in invoice pdf was explicitly passing `amount`, `res_model`, `res_id` to create `payment.link.wizard` using create method which overrides default_get() of wizard. As a result, installment-based invoices were generating payment links for the full residual amount.
Also the `active_id` and `active_model` is passed in context which writes to `res_model` and `res_id` so no need to add it in create again.

By letting default_get() populate the wizard values, the payment link now correctly reflects the next payable installment.

task-5401335

Forward-Port-Of: odoo/odoo#241825

This update resolves an issue where selection fields would display an error if a chosen value wasn't available in the current options. Now, the field will gracefully display the original, raw value instead, preventing disruptions to the user experience. This ensures smoother operation and avoids unexpected errors when working with selection fields.

When a selection field contains a value not found in the current options list, display the raw value instead of raising an error.

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

This update resolves a compatibility issue in Firefox 148 related to how initial blank pages are loaded. By using empty iframes, the website and snippet editors now load correctly and immediately, eliminating delays and ensuring a smoother user experience. This change improves performance and reliability for our users.

Firefox 148 fixed the behavior of `about:blank` documents, as explained
in their [release notes]:

> The initial about:blank document is now Web-compatible. If the first
> navigation of a browsing context goes to about:blank, it completes
> synchronously and is no longer replaced by a second parser-generated
> document.

Commit [e0796020] added the new page dialog in website, and used empty
iframes to load each page template.
Commit [edf81c13] added the add snippets dialog in website, and used an
empty iframe to load the snippets previews.
In both cases, before Firefox' fix, it meant we had to wait the
recreation of the 2nd document before proceeding. This is no longer the
case in Firefox >= 148.

[release notes]: https://www.firefox.com/en-US/firefox/148.0/releasenotes/
[e0796020]: https://github.com/odoo/odoo/commit/e0796020ee0c3188e1e9d9fa077de73a2211c6f7
[edf81c13]: https://github.com/odoo/odoo/commit/edf81c13d8f2f6d29a77d68cbfa0dc9216da3c2a

Forward-Port-Of: odoo/odoo#251172
Forward-Port-Of: odoo/odoo#250592

This update enables the copying of the main attachment from a vendor to the newly created invoice when using the 'Reverse and Create Invoice' button. This streamlines the process for users needing to attach relevant documents during invoice reversal, improving data accuracy and efficiency. It addresses a previous limitation in the system.

This commit copies the main attachment to the newly created vendor  through the "Reverse and Create Invoice" Button.

task-5905299

Forward-Port-Of: odoo/odoo#250183

This update fixes an issue where QR codes generated in Point of Sale were incorrectly pointing to 'localhost:8069' instead of the associated company's website. The change ensures that QR codes now accurately reflect the correct URL for generating invoices, improving the customer experience.

Steps to reproduce
------------------
1. Make a website, associated with company 'A'
2. Add a `domain` on that website, e.g. 'test.domain.com'
3. Select company 'A', and create a PoS shop for it
4. Enable 'Self-service invoicing' for that PoS shop, select 'QR code'
5. Open the shop, select a client and make an order

-> The generated QR code point to the domain 'localhost:8069' and not to the company's website domain 'test.domain.com'.

Why the issue
-------------
In 1ee02f8a47d42d3ba3fd11ffcf8d9768ea17678e, we moved the `_base_url` from the session to the config. So now we call `self.get_base_url` on the config and not on the session anymore.

However, `self` is an empty config created on the fly, and it's not the `session.config_id` config object used by that shop.

The fix
-------
In `_load_pos_data_read` of the config model, we call `get_base_url` on the `config` instance, which is garanteed to be the valid config of that shop.

opw-5942057

Forward-Port-Of: odoo/odoo#251177
Forward-Port-Of: odoo/odoo#249858

This update fixes an issue where the calculation of 'sandwich leave' (leave periods surrounding holidays) was incorrect. Specifically, when leave was approved and then re-approved, the system failed to properly account for neighboring leave days, leading to an inaccurate leave count. This change ensures that leave durations are calculated correctly, aligning with the intended business logic.

## Steps to reproduce:-
1. Apply Friday to Monday leave and Tuesday is Public holiday and again apply single leave on Wednesday.
- According to the sandwich leave rule, the leave should be counted as 6 days (Friday to Wednesday, including weekend and holiday).
2. Now refuse the Friday to Monday leave and re-approve again.
3. Now the leave count is updated to 5 days as it should be 6 days!

## Root cause:-
On approve and reset actions the neighbor leaves where not recomputed.

## Fix:-
- Override `_l10n_in_update_neighbors_duration_after_change` on approve and reset actions.
- Updated `_l10n_in_update_neighbors_duration_after_change` so that current and neighbors both leaves are recomputed.

task-[5446346](https://www.odoo.com/odoo/action-4043/5446346)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#251111
Forward-Port-Of: odoo/odoo#244235

This update resolves an issue where the legal name displayed in payroll reports was not accurately reflecting the employee's legal name in Switzerland. The fix ensures that the correct legal name is computed and presented, complying with Swiss legal requirements and improving reporting accuracy. This update primarily impacts the l10n_ch_hr_payroll module.

task-5979726

Forward-Port-Of: odoo/enterprise#109037

This update resolves an issue where work entries weren't being created when multiple resource calendar attendances were close together in time. The fix prevents attendances from being incorrectly combined, ensuring accurate work entry generation for employees. The change improves the reliability of the payroll and time tracking processes.

When you have two resource calendar attendances that are stuck together, and you generate work entries, the second one doesn't appear:

Bug is caused when having two attendances stuck together: In a resource.calendar, change the time of a resource.calendar.attendance to finish at 15.36 and create a new one that begins at 15.36 and finished at 16.36 with a work entry type of Credit time. Go and regenerate work entries and you can see that no work entries are generated for credit time.

Fixed by adding keep_distinct in an interval to not fuse them together. Also added extra checks to another test to not pass with incorrect values.

task-5894994

Forward-Port-Of: odoo/enterprise#108993
Forward-Port-Of: odoo/enterprise#105981

This update fixes an issue where the 'Billable' and 'Non-Billable' timesheet filters were inaccurate, preventing the KPI button from working correctly. The fix now uses a more reliable method based on analytic line associations, ensuring timesheets are correctly categorized for reporting. This improves the accuracy of time tracking data.

Due to a previous [commit](https://github.com/odoo/odoo/commit/8e8b273), the "Billable" and "Non-Billable" were incorrect for timesheets. This lead the billable timesheet KPI button not to filter the timesheets anymore.

This is fixed by filtering based on whether the analytic line has an SOL associated to it, which is more robust to
changes in the `billable_type` field, and improves clarity.

See odoo/enterprise#108347

task-5956027

This update corrects an issue where the 'Billable' and 'Non-Billable' timesheet filters were inaccurate, preventing the KPI button from working correctly. The fix now uses a more reliable method – checking for a linked Service Order Line (SOL) – ensuring accurate filtering and improved clarity. This enhances reporting on billable time.

Due to a previous [commit](https://github.com/odoo/odoo/commit/8e8b273), the "Billable" and "Non-Billable" were incorrect for timesheets. This lead the billable timesheet KPI button not to filter the timesheets anymore.

This is fixed by filtering based on whether the analytic line has an SOL associated to it, which is more robust to
changes in the `billable_type` field, and improves clarity.

Further, remove unnecessary service patch introduced in odoo/enterprise#108035.

See odoo/odoo#250149

task-5956027

This update fixes a potential issue where selection fields would display an error if a selected value wasn't available in the current options. Now, the field will gracefully display the original, raw value instead, preventing disruptions to the user experience. This ensures a smoother and more reliable selection process.

When a selection field contains a value not found in the current options list, display the raw value instead of raising an error.

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

This update fixes an issue where QR code payment links on invoices were incorrectly showing the full outstanding amount, especially for installment-based invoices. By using the default values for the payment link wizard, the links now accurately reflect the next payable installment, ensuring accurate payments.

The link from QR code in invoice pdf was explicitly passing `amount`, `res_model`, `res_id` to create `payment.link.wizard` using create method which overrides default_get() of wizard. As a result, installment-based invoices were generating payment links for the full residual amount.
Also the `active_id` and `active_model` is passed in context which writes to `res_model` and `res_id` so no need to add it in create again.

By letting default_get() populate the wizard values, the payment link now correctly reflects the next payable installment.

task-5401335

Forward-Port-Of: odoo/odoo#241825

This update resolves a minor issue where website page loading in Firefox 148 was delayed due to how the browser handled initial 'about:blank' documents. By using empty iframes to load page templates and snippet previews, the process is now faster and more reliable in Firefox, ensuring a smoother user experience. This change improves performance and stability for website features.

Firefox 148 fixed the behavior of `about:blank` documents, as explained
in their [release notes]:

> The initial about:blank document is now Web-compatible. If the first
> navigation of a browsing context goes to about:blank, it completes
> synchronously and is no longer replaced by a second parser-generated
> document.

Commit [e0796020] added the new page dialog in website, and used empty
iframes to load each page template.
Commit [edf81c13] added the add snippets dialog in website, and used an
empty iframe to load the snippets previews.
In both cases, before Firefox' fix, it meant we had to wait the
recreation of the 2nd document before proceeding. This is no longer the
case in Firefox >= 148.

[release notes]: https://www.firefox.com/en-US/firefox/148.0/releasenotes/
[e0796020]: https://github.com/odoo/odoo/commit/e0796020ee0c3188e1e9d9fa077de73a2211c6f7
[edf81c13]: https://github.com/odoo/odoo/commit/edf81c13d8f2f6d29a77d68cbfa0dc9216da3c2a

Forward-Port-Of: odoo/odoo#251172
Forward-Port-Of: odoo/odoo#250592

This update enables the copying of the main attachment from a vendor to the newly created invoice when using the 'Reverse and Create Invoice' button. This streamlines the process for users needing to reverse invoices while retaining important supporting documents, improving efficiency and data accuracy.

This commit copies the main attachment to the newly created vendor  through the "Reverse and Create Invoice" Button.

task-5905299

Forward-Port-Of: odoo/odoo#250183

This update fixes an issue where the calculation of 'sandwich leave' (leave periods surrounding holidays) was incorrect. Specifically, when leave was approved and then re-approved, the neighboring leave days weren't properly recomputed, leading to a 1-day discrepancy. This ensures accurate leave tracking for employees.

## Steps to reproduce:-
1. Apply Friday to Monday leave and Tuesday is Public holiday and again apply single leave on Wednesday.
- According to the sandwich leave rule, the leave should be counted as 6 days (Friday to Wednesday, including weekend and holiday).
2. Now refuse the Friday to Monday leave and re-approve again.
3. Now the leave count is updated to 5 days as it should be 6 days!

## Root cause:-
On approve and reset actions the neighbor leaves where not recomputed.

## Fix:-
- Override `_l10n_in_update_neighbors_duration_after_change` on approve and reset actions.
- Updated `_l10n_in_update_neighbors_duration_after_change` so that current and neighbors both leaves are recomputed.

task-[5446346](https://www.odoo.com/odoo/action-4043/5446346)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#251111
Forward-Port-Of: odoo/odoo#244235

This update fixes an issue where the legal name displayed in payroll reports was not accurately reflecting the employee's legal name in Switzerland. The change ensures that the correct legal name is computed and presented, complying with Swiss legal requirements and improving reporting accuracy. This update impacts the l10n_ch_hr_payroll module.

task-5979726

Forward-Port-Of: odoo/enterprise#109037

This update corrects a calculation error related to employee legal names within the Odoo Enterprise payroll module. The fix ensures that employee names are accurately reflected in reports and legal documents, complying with Swiss regulations. This improves data accuracy and reduces the risk of reporting discrepancies.

task-5979726

This update fixes an issue where invoices generated using the PEPPOL standard were incorrectly using company registry information. Previously, the system didn't verify that company registry data matched the required BCE number. This change ensures invoices comply with PEPPOL regulations, preventing potential errors and improving data accuracy.

We expect people to put BCE number in the company registry. 
But it is not enforced client-side, resulting in invoices in error.




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

Forward-Port-Of: odoo/odoo#251168

This update resolves an issue where Avatax taxes weren't being correctly calculated during Stripe Express Checkout, particularly when using Google Pay. The fix ensures that all applicable taxes, including those from Avatax, are accurately reflected in the order total, leading to consistent pricing and payment reconciliation. This improves the accuracy of sales transactions.

## Versions
17.0+

## Issue
Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes.

## Steps to reproduce
*Ensure the Stripe account has activated Google Pay* *This requires a complete Google profile on Google Chrome (with a valid payment method)*
- Setup Stripe payment method in test mode with Express Checkout;
- In the Settings, in the Accounting section:
  - Setup Avatax;
  - Set main Sales/Purchase taxes to 0.
- Create a new product with 0% selling taxes and any Avatax category;
- Activate fiscal position and enable automatic detection;
- Open a Chrome session with the Google profile:
  - Go to the shop;
  - Add the product you created to the cart;
  - Enter the cart;
  - Click the "Buy with GPay" button:
    - The amount is equal to the sales price excluding taxes.
- Go to the Sales app and open the newly created order:
  - The total amount differs from the amount paid (cf. transaction).

opw-5020793

Forward-Port-Of: odoo/enterprise#108957
Forward-Port-Of: odoo/enterprise#101579

This update corrects a problem with how leave periods are calculated, specifically related to time zone differences. By using `request_date_from` and `request_date_to` instead of `date_from` and `date_to`, the system now accurately reflects leave interruptions, ensuring correct payroll processing in Switzerland.

This commit fixes the leaves work interruption constraint by replacing `date_from` and `date_to` with `request_date_from` and `request_date_to`, thereby resolving any inconsistencies that may arise from time zone differences.

task-5966780

Forward-Port-Of: odoo/enterprise#108541

This update resolves a potential issue during database upgrades in the Odoo Enterprise payroll module. Previously, removing a payroll rule could cause upgrade scripts to fail. This fix ensures that upgrade scripts continue to function correctly even if a rule has been deleted, improving the reliability of database updates.

This method is used in various places, including when upgrading a database. When doing so, it is done in a post upgrade script.

If later one of the updated rules is removed, the pre-script removing it will run before the post script trying to update it, causing the migration to fail as the update method tries to browse a falsy value.

This updates the `update_properties_definition_domain` method so that it ignores falsy values when browsing, allowing previous upgrade scripts to run even if the referred rule has been since deleted.

Forward-Port-Of: odoo/enterprise#102964

This update removes the 'amount' column from the worked days tab in payroll reports for the United Arab Emirates (AE) and Saudi Arabia (SA) localizations. This change aligns with local reporting requirements and simplifies the reports for users in these regions, improving clarity and accuracy.

The amount column should be removed from worked days tab for AE and SA localizations.

task - 5111183

This update fixes a bug where deleting a partially signed offer would incorrectly delete the associated employee. The change ensures the employee is only deleted when the offer is archived and has no other active offers, preventing data inconsistencies. This improves data integrity and reduces the risk of lost employee records.

Version – saas-18.4

### Issue:
When an applicant has both a partially signed offer and a fully signed offer,
deleting the partially signed one also deletes the employee that was created
from the fully signed offer.

### Steps to Reproduce:

- Create two offers for an applicant.
- Fully sign the first offer and partially sign the second one.
- Delete the partially signed offer.
 The employee created from the fully signed offer is also deleted.

### Cause:
Due to this issue, the employee record is incorrectly deleted from the system,
which is not expected behavior.

### Fix:
Improved the employee deletion logic by deleting the employee only when:
- the employee is archived, and
- they do not have any other offers besides the one being deleted.

### Impact:
The employee will no longer be deleted when another partially signed offer for
the same applicant is removed.

---

Task – 5347109

Forward-Port-Of: odoo/enterprise#108634
Forward-Port-Of: odoo/enterprise#100991

This update resolves an issue where the system incorrectly identified the currency of multiple journals with the same IBAN. The fix ensures that CODA transactions are now accurately routed to the correct journal based on its currency, improving financial accuracy and reducing potential errors in multi-currency accounting. This was a critical fix impacting financial reporting.

When having multiple journals with the same IBAN, but different currencies, upon fetching and dispatching the CODA into the right journals, the currency of the journal was not correctly taken into account as the condition was incorrect.

This commit fixes this condition which was introduced in [^1] such that the right journal, with the right currency is correctly chosen.

[^1]: 4fda4fb5353ed9c14dbc023ab7d07fabd3c06e98

opw-5723017

Forward-Port-Of: odoo/enterprise#108952
Forward-Port-Of: odoo/enterprise#108677

This update resolves an issue preventing the correct display of supplier names in SAF-T reports. The fix ensures that the system accurately identifies suppliers by incorporating depreciation lines alongside journal entries, addressing a discrepancy caused by bills posted in previous months.

**Steps to reproduce:**
- Install l10n_ro_saft
- Switch to a Romanian company (e.g. RO Company)

- Create an asset model:
  * Method: Straight Line
  * Duration: 12 Months
- Configure a "Fixed Assets" account:
  * Automate Asset: Create and validate
  * Asset Model: [the asset model created above]
- Create a bill:
  * Vendor: [create a new vendor]
  * Bill Date: [last month]
  * Invoice Line: [A line with the fixed asset account]
- Confirm the bill

- Go to "Accounting / Reporting / Audit Reports / General Ledger"
- Select the current month (The fixed asset account should be present)
- In the cog menu, select "SAF-T (D406 Asset Declaration)"

**Issue:**
A traceback is raised while trying to display the name of a supplier.

**Cause:**
To display the supplier name of an asset, a dict having the id of the customer or supplier as key (i.e. partner_detail_map) is used. This dict is build by getting the list of all partners linked to a posted journal item on an asset (or liability) account in the period of the report.
In this case, it's the current month.
However, the created bill has been posted the month before.
So no journal item is found for the vendor that has been created just for the bill and therefore there is no key for him in the dict, which leads to the error when trying to get the id of the supplier of the asset in the dict.

**Solution:**
Instead of just fetching the posted entries linked to a receivable or payable account in order to get the list of the potential customers and suppliers, we also fetch the depreciation lines that are linked to an asset account and can still be in draft.


opw-5499918

Forward-Port-Of: odoo/enterprise#109051
Forward-Port-Of: odoo/enterprise#105987

This update resolves an issue where the legal name displayed in payroll reports was not accurately reflecting the employee's legal name as required by Swiss law. The fix ensures that the correct legal name is computed and presented, improving compliance and accuracy of payroll data. This change impacts the l10n_ch_hr_payroll module.

task-5979726

Forward-Port-Of: odoo/enterprise#109037

This update fixes a technical issue within the Odoo ‘pos_self_order’ module where commands were incorrectly used to update data instead of creating it. This change ensures that updates to self-order data are processed correctly, improving the reliability of the mobile ordering feature. It's a minor fix focused on internal module functionality.

Before this commit, all lines even updated one were using Command.CREATE instead of Command.UPDATE.

This commit fix the issued.