## **Steps to reproduce:**

1. Create a Service product with Create on Order set to Task and Project set to Field service project.
2. Create a Sales Order containing a storable product and a service product.
3. Confirm the Sales Order to generate the project, task, and delivery order.
4. Validate the delivery order.
5. Create and validate a return for the delivery.
6. Create a return of the return to deliver the products again, but do not validate this new delivery.
7. Open the related task and click on Mark as Done button.

## **Issue:**

In a delivery -> return -> return of return workflow, the stock move goes into this code
https://github.com/odoo/enterprise/blob/59b86f106862c3a364ba633a1580d9051f2fe7ca/industry_fsm_stock/models/project_task.py#L89-L90 the traversal repeatedly revisits the same stock moves through move_dest_ids, causing the loop to alternate between the same move recordsets indefinitely. As a result, the loop never terminates, eventually exhausting the memory and raising a `MemoryError`.

## **Solution:**

Track the stock moves that have already been visited and continue the traversal only with unseen destination moves.

Runbot Video : [Video](https://drive.google.com/file/d/1wiqggjx8T-Mtl4T1JgCsfwBbgQU18nYF/view?usp=drive_link)

OPW - 6420961

Forward-Port-Of: odoo/enterprise#125962

Bug :
	- create an unvalidated leave
	- on the payrun Time view, when validating the view -> click on continue -> error popup appears says you have unvalidated leave (BUG 1)
	- on the payrun Payslips view, when canceling a payslip , the KPIs values don't change unless you refresh (BUG 2)

Reason :
	- PayRunMixin now subscribes to its model's "update" bus event and forwards it to updatePayRun, so any pay run view whose model emits "update" keeps the summary in sync.

	- The natural trigger is the model's "update" bus event, but the mixin never listened to it. On top of that the relational payslip list never even emits "update" on a programmatic reload: model.load() (cog actions) and root.load() (form close, view-button reloads) rebuild the reactive root without calling notify(), which only fires on search/pager changes. The Time view gantt already worked around this because GanttModel.fetchData() calls notify() itself. 

Fix :
	- Subscribe payroll mixing to the "update" notif that will come from the underlaying models.
	- override the onRootLoad hook in payslipListCOntroller to call notify() which sends an "update" message when loading the data.(added a guarderail: only call the notify on the model if it's mounted)

task - 6387933

The original issue coudn't be reproduced. But based on what was reported on the ticket, this should improve the behavior of the order receipt.

Steps to reproduce:
-------------------
* Setup the l10n_ke module in 'production' mode
* Make an order in POS and validate it
> Observation: The receipt doesn't contain the SCU information and QR

Why the fix:
------------
Based on the receipt screenshot shared on the ticket (from Odoo 19.3) we can see that some informations are shown on the ticket. The information shown are the one received from the etims api, it means the call went through and the response was received.

As the qrCode URL only needs `l10n_ke_oscu_signature` to be generated, we can assume that if this field is set we can safely generate the URL and generate the QR code.

https://github.com/odoo/enterprise/blob/ee7e6894ed313db844aeff5ba5e19de3ad94898e/l10n_ke_edi_oscu_pos/models/pos_order.py#L252-L256

Based on this assumption we can change the condition to return the URL or not based on the presence of `l10n_ke_oscu_signature` instead of the state of the order being `sent`.

In 19.0, the receipt is showing no info at all (when 19.3 is showing some info like the signature). This is also happening because the URL was falsy. And when that is the case we do not show any SCU information

https://github.com/odoo/enterprise/blob/ee7e6894ed313db844aeff5ba5e19de3ad94898e/l10n_ke_edi_oscu_pos/static/src/overrides/components/order_receipt/order_receipt.xml#L56

opw-6352120

Forward-Port-Of: odoo/enterprise#127045

Steps to reproduce
---
1. Configure a `delivery_easypost` shipping method using the DHL Express carrier.
2. On an international delivery, use Put in Pack to create two or more packages.
3. Validate the delivery.

Issue
---
Validation is blocked with `DHLExpress: rate_error -- DHLExpress multi-shipment rate includes this shipment.`

For an EasyPost multi-shipment order, DHL Express returns the aggregate rate on the first (master) shipment only and adds an informational `rate_error` on the order stating that this rate already covers the whole order, so the remaining shipments carry no rate of their own. The message is not a real error, but `send_shipping` raises on any carrier message whose type is not exempt: https://github.com/odoo/enterprise/blob/534b42def8ae5dc884da4398377f828c49557d6e/delivery_easypost/models/easypost_request.py#L359-L364

`_post_process_ship_response` already detects and clears exactly this harmless message, but only for a hardcoded carrier allowlist introduced in a2de5bc5a14 (`Purolator`, `DPD UK`, `UPS`) that was never extended to DHL Express, so for DHL Express the message survives, reaches the raise, and aborts an otherwise valid shipment: https://github.com/odoo/enterprise/blob/a2de5bc5a14f99b8674c3ee234e4d221b406da0f/delivery_easypost/models/easypost_request.py#L416-L434

`DHL Express` is added to that allowlist so the harmless multi-shipment `rate_error` is posted on the picking and cleared instead of raised. The guard still requires a single `rate_error` carrying the "multi-shipment rate includes this shipment." text with the rate present only on the master shipment, so genuine DHL Express errors keep blocking validation.

opw-6450365

Forward-Port-Of: odoo/enterprise#127164

Bug:
	- Create a working sched were one day has less working hours than the rest.
	- when generating a payslip for an employee linked to that working sched , you'll have half-day attendances even though he worked all his days

Reason :
	- in _get_work_hours_split_half , when building work_data, we compare the duration worked by the employee that day not against the contractual amount of that that but instead we use self.resource_calendar_id.hours_per_day or the max hours per day on that working day , so the day with the least contractual hours on that working sched for exemple will fail this condition " float_compare(duration_sum, number_of_hours_full_day, 2) != -1" even if the employee worked that whole day. 

Fix:
	- for fixed scheds : we builed hours_per_dayofweek where we store the hours for each day of the week , later on , we check the weekday and retreive the corresponding official working hours on that day.
	- for variable scheds: because in this case each day can have its own officil working hours , we fetch the official hours of a certain date right before the logic that determines if it's a full or half a day.

task - 6377396