This update fixes an issue where time off requests on flexible calendars incorrectly displayed leave durations. The change ensures that public holidays are accurately accounted for when calculating work intervals, resulting in the correct leave duration being shown. This improves the accuracy of time off tracking.

Steps to reproduce:
-------------------
1. Install hr_holidays
2. Create a public holiday on 9th jan
3. Set an employee's working schedule to a flexible 40h/week calendar
4. Create a time off request from Jan 4th → Jan 10th
5. Observe the displayed duration

Issue:
------
The leave duration is displayed as 5 days instead of 4. 
This happens because public holidays are not correctly accounted for
within the work intervals.

Cause:
------
Work intervals for flexible calendars are allocated on a weekly basis.
Currently, the required weekly hours (40h) are distributed across the
first five days of the week without verifying if any of those days are
public holidays. Consequently, if a holiday falls on the 6th or 7th day
of the week, it is ignored by the allocation logic, leading to an incorrect
duration calculation.


reference: [attendance_intervals_batch](https://github.com/odoo/odoo/blob/403866e4b426107d2e869c052cd1a7f16f9a3173/addons/resource/models/resource_calendar.py#L393-L447)


Solution:
---------
Modify the allocation logic to identify public holidays within the week before
distributing hours. Prioritize generating attendance intervals for these
holidays to ensure they are subtracted correctly from the leave duration,
regardless of their position in the week.


opw-5387651

This update fixes an issue where components added to manufacturing orders through the product catalog weren't correctly transferred to the pre-production warehouse. The fix adds a warehouse ID to the moves created by the catalog, ensuring proper procurement transfers within multi-step manufacturing processes. This resolves a discrepancy in component movement, improving the accuracy of production tracking.

Issue
-----
In multi step manufacturing, components added to MO through the catalog don't get transfered to the pre-prod location.

Steps to reproduce
-----
- 2 step manufacturing
- Create 2 products
- Create a MO for the first product
- Open the product catalog
    - Add some qty of the second product
- Go back to the MO & confirm it

> No procurement transfer for the second product from stock to pre-prod

Cause
-----
The move created by the catalog has no `warehouse_id` so in `adjust_procure_method` we don't find any rule which means it gets set to MTS

https://github.com/odoo/odoo/blob/6ecd271ff34313d900a0ad14b1c20679808ba9b8/addons/stock/models/stock_move.py#L2366-L2368

-----
Ticket:
opw-5221418

This update fixes a bug where multiple attempts to grant portal access to a previously archived user were blocked. The fix ensures that access is only blocked when the user is currently active, and a new toggle has been added to the user interface to reflect this change. This improves the portal user experience and prevents unnecessary restrictions.

**Steps to reproduce:**
- Go to the Contact app
- Go to the record of a partner
- Go to the actions dropdown menu of the record
- Grant portal access
- Remove the access
- Grant the access again
- Second grant is blocked

**Issue:**
Active check is needed when granting access to a previous portal user which was archived.

**Fix:**
Only block when the user is an active portal user.

Also need to add `is_active` field to toggle the buttons in the xml as we can't directly access
`user_id.active` in the view.

related: https://github.com/odoo/odoo/commit/d49d91ffd463a68cb6ccc881aa14ac58bd2cf65b

opw-4760550

This update corrects a problem with Odoo invoices generated by the l10n_dk module, specifically related to the schemeID value used for EndpointIDs. The issue prevented invoices from passing validation checks. By updating the codelist used, the invoices now correctly conform to OIOUBL standards and can be processed successfully.

**PROBLEM**
Generated OIOUBL files don't pass schematrons validations.

**STEP TO REPRODUCE**
1. Install the l10n_dk module.
2. Create a dk partner with an adress, and VAT number (DK12345674 for example, don't forget to add a street number for the DK Company address).
3. Create an invoice for the DK partner, and download the xml.
4. Use this validator https://oioubl.nemhandel.dk/validation (Odoo Peppol IAP validator tests oioubl version 3.0 which is not the version we want to test).

**CAUSE**
We used [wrong codelist](https://oioubl-demo.nemhandel.dk/oioubl/kodelister/ElectronicAddressSchemeCode-3.0.html) (oiubl3.0) for schemeID instead of the [one we should use](https://oioubl21.oioubl.dk/Codelists/en/urn_oioubl_scheme_endpointid-1.1.html) (oioubl2.1).

opw-5379474

This update automatically calculates and transmits the required 2050 retirement savings contributions for Swiss businesses using Odoo. The change ensures accurate compliance with Swiss tax regulations, streamlining the payroll process and reducing the risk of errors related to this specific calculation.

task-5166226

Forward-Port-Of: odoo/enterprise#103453

This update fixes an error in how Odoo calculates stock valuations when processing purchases in foreign currencies with auto-standard products. Previously, an incorrect currency exchange rate adjustment was being applied, leading to inaccurate inventory values. This change ensures the stock valuation accurately reflects the product cost.

Processing a buy-receive-bill process in a foreign currency and with
an auto-standard product will lead to an incorrect valuation

To reproduce the issue:
(Company in USD)
1. Enable EUR and define the rates as followed:
   - Yesterday: 2
   - Today: 2.5
2. Create a product category:
   - Method: Standard
   - Valuation: Automated
3. Create a product P in that category
   - Cost: 10 USD
4. [Yesterday] Confirm a PO in EUR with 1 x P
5. [Yesterday] Receive it
6. Bill

Error: the stock valuation has two entries: one with 10 USD debit, the
receipt. Another one with 2 USD credit, the currency exchange rate
difference. The second one is a mistake, in a standard configuration,
the stock valuation should be impacted by nothing but the cost defined
on the product form.

Since [1], in some conditions the method `_get_exchange_account`
returns the stock valuation account. This is what happens here, but
it's a mistake since in the above case, we should stick with the
classic account (i.e. the `super` call). The conditions must be more
strict.

[1] https://github.com/odoo/odoo/commit/bae7feefcb08db7329d52bc36517dfd73f3347a7

OPW-5380665

This update resolves an issue where the 'Pending' button in manufacturing orders incorrectly stopped productivity records for all employees involved, instead of just the current one. The fix ensures that only the employee currently working on the operation is impacted when the 'Pending' button is clicked, improving order management accuracy.

Steps to reproduce the bug:
- Create a storable product P1 with the following BoM:
    - Create a new operation OP1

- Create a manufacturing order to produce one unit of P1
- Confirm the manufacturing order
- Log in as Mitchel (admin) and start OP1
- Log in as Marc (demo) and also start OP1
- Click on Pending

Problem:
Both “mrp.workcenter.productivity” records are stopped, instead of stopping only the one linked to

The `button_pending` method was stopping productivity records for all employees linked to the work order.

opw-5453752

This update fixes an issue where the Helpdesk return wizard incorrectly defaulted to internal 'PICK' operations instead of the final 'OUT' operation for multi-step deliveries. The change ensures the wizard now correctly selects the customer-facing 'OUT' operation, streamlining the return process and improving order accuracy. This resolves a potential confusion point for users.

Steps to reproduce:
-
  1. Configure a warehouse for multi-step delivery (e.g., Pick + Ship).
  2. Create a Sales Order for a product and fully process the delivery, including all steps.
  3. Create a Helpdesk ticket for that customer.
  4. From the ticket, click the "Return" button to open the wizard and select the sales order.

Issue:
-
The return wizard incorrectly defaults to the first operation in the delivery chain (e.g., the internal 'PICK' operation) instead of the final, customer-facing 'OUT' operation.

Cause:
-
Since picking is ordered by 'priority, scheduled_date asc, id desc', records are sorted by scheduled_date, this often resulted in selecting an internal 'PICK' operation instead of the final 'OUT' operation, making a more specific filter necessary.

Fix:
-
The code now explicitly filters for pickings with the type code 'outgoing' and sets it as the default delivery order.

task-4948134

This update resolves an issue where payment reports were inconsistently using different export formats (NACHA or localization-specific). The fix ensures that payment reports now consistently use the correct format based on the company's localization, improving report accuracy and reliability for financial reporting. This impacts all Odoo Enterprise users.

\* = l10n_{ae, au, ch, in, sa, us}_hr_payroll + hr_payroll_account_iso20022 

Issue:
The current behavior looks deterministic: when clicking on "Create Payment Report" it -sometimes- shows the current company's export format by default, other times it shows the "NACHA" type. Or it could be the last installed module's export format value for the other companies.

Solution:
I fixed it in this PR: https://github.com/odoo/enterprise/pull/93683 and now backporting the changes to version 18.0

task-5189295

This update ensures that all attendees of a calendar event receive post-event feedback emails, not just the event owner. The fix corrects a previous issue where email recipients were limited to the event's creator. This enhancement improves communication and collaboration for calendar-based activities.

**Steps to reproduce:**
- Install Calendar and Marketing Automation apps
- Go to Calendar
- Add an event with multiple attendees
- Go to Marketing Automation
- Create the marketing automation campaign
- Select `Calendar Event` as target
- Filter to only get your event
- Add an activity with a template
- Launch a test or start the campaign
- Mail is only sent to the owner of the event, not all the participants

Fixed in 19.0 as the attendees also receive the mail

Could also be reproduced with a more useful flow using appointment:
- Add appointment type
- Create meeting on it with a name, attendees, and status set to checked-in
- Create a mail automation campaign for Calendar Event
- Filter on [("appointment_status", "=", "attended")]

**Issue:**
Goal was to set a feedback mail which triggers after a calendar meeting was done. But the recipients are set using the `partner_id` of the record in: 
`default_recipients = RecordsModel.browse(res_ids)._message_get_default_recipients()`

**Fix:**
Override `_message_get_default_recipients` to get the `partner_ids` of all the attendees.

opw-5266543

This update fixes a technical issue that caused confusing traceback error messages during the ZATCA onboarding process. Now, users receive clear, user-friendly alerts with the actual error returned by ZATCA, ensuring a better experience and compliance with onboarding requirements. This improves the overall user experience and prevents potential issues with ZATCA integration.

Whenever an error occurs during the ZATCA onboarding steps—such as
providing a company name that exceeds 127 bytes in binary representation
(for example, 64 Arabic characters without whitespace result in exactly
127 bytes; see refs [1] and [2])—the system returns a traceback to the
user instead of a clear and user-friendly error message.

Error:
`TypeError: argument should be a bytes-like object or ASCII string, not 'NoneType'

This is due to the check-in `_l10n_sa_request_production_csid` for an 'error'
key, not present in the response when an OTP is invalid because in these cases,
the `_l10n_sa_call_api` returns the response_data directly.

This fix improves the behaviour by displaying a user-friendly alert message
with the error returned by ZATCA, instead of a traceback.

This ensures a better experience and compliance with CCSID onboarding flows.

[1]: https://zatca1.discourse.group/t/organization-name-is-too-long-issue-csr/7571
[2]: https://zatca1.discourse.group/t/organisation-name-with-restriction-of-64-characters/960

sentry-7169834710

This update corrects a calculation error in the Belgian HR payroll module (l10n_be_hr_payroll) related to employment bonuses. The changes ensure that bonus calculations accurately reflect the latest tax regulations up to March 2026, improving payroll accuracy for Belgian employees. This update is a critical fix to maintain compliance and accurate financial reporting.

This update reverts a previous change that was causing issues when multiple companies used the same accounting entries. It ensures that account entries on move lines are correctly associated with the appropriate company, resolving a conflict that could lead to inaccurate financial reporting. This improves data integrity and reliability.

This reverts commit 7a2b03846f07dcf04743d745c7c942ea17721d0a.


This commit created issues with account shared by multiple companies

This update corrects a discrepancy in the calculation of the 3000 deduction within the Belgian HR payroll module. The change ensures that deduction amounts accurately reflect the latest regulations up to 2026, improving payroll accuracy and compliance. This update addresses a specific tax calculation issue.

This update resolves a problem preventing connections to IAP Codaclean, which is crucial for accurate data exchange with our Belgian tax reporting module. The issue was caused by a missing parameter, and this fix ensures seamless integration and reliable reporting.

Connections to IAP Codaclean are failing because of missing
`enterprise_number` param.

no-task-id

Forward-Port-Of: odoo/enterprise#103724