**TL;DR**
- in certain cases, Session is not updated on order shared on trusted pos

Steps to reproduce:

- Install pos_restaurant with demo data.
- Have two configs: Cloth Shop and Furniture Shop.
- Ensure both configs have their own individual payment method (e.g., CASH).
- In Cloth Shop, add Furniture Shop as a trusted PoS.
- In Cloth Shop, enable "Log in with Employee".
- Open Cloth Shop and Furniture Shop in separate browsers (different users).
- Refresh Cloth Shop once.
- In Cloth Shop, create and save an order.
- In Furniture Shop, open that order and try to pay with "CASH".

Observation:
* A validation error is raised: "The payment method selected is not allowed in the config of the POS session."
<img width="320" height="201" alt="image" src="https://github.com/user-attachments/assets/8ca80575-76bf-4ecf-a739-08b03d543ed6" />

- although we can pay the order by a shared payment method

Cause:
- Refreshing Cloth Shop triggers `notify_synchronisation` due to `setCashierUpdateSession` , which pushes Cloth Shop's `pos.session` record into Furniture Shop's IndexedDB (because Cloth Shop trusts Furniture Shop).
https://github.com/odoo/odoo/blob/6a3655c8efd2de68754ace38bd1ab5eb6499faca/addons/pos_hr/static/src/app/services/pos_store.js#L61-L63
- When Cloth Shop saves an order, sync also pushes a copy of that order into Furniture Shop, and passed through `processDynamicRecords`
- `processDynamicRecords` ensures that the Record created is in sync with server data,  as  Furniture Shop now has a local record of session of Cloth Shop, the record keeps `session_id` pointing to Cloth Shop's session, else it would have been left `undefined`
- from the `res` we get, we set the session_id on `pos.order `
https://github.com/odoo/odoo/blob/6a3655c8efd2de68754ace38bd1ab5eb6499faca/addons/point_of_sale/static/src/app/utils/devices_synchronisation.js#L127-L139
- However with  pos_restaurant installed we get its orveride which stores the result of super() and only returns result early when there are no` pos.order ` records in dynamicRecords. When pos.order records are present (our case), the method proceeds with its own logic but never returns result (or its own output) at the end 

https://github.com/odoo/odoo/blob/6a3655c8efd2de68754ace38bd1ab5eb6499faca/addons/pos_restaurant/static/src/app/utils/devices_synchronisation.js#L5-L9

- so the corrected data from the super call is silently dropped.
- we do not get a change to update the session id

- The order keeps Cloth Shop's session ID
- Furniture Shop's payment validation checks the order against its session's allowed payment methods, but since the session is still Cloth Shop's, the check fails for methods not shared between Cloth Shop and Furniture Shop (e.g., CASH).

Why this is hidden in other cases: 

- without pos_restaurant, or if Furniture Shop had no prior knowledge of Cloth Shop's session (we made is possible by `Log in with Employee` feature, session_id would stay `undefined` and later get correctly set toFurniture Shop's session in PosOrder.setup().
https://github.com/odoo/odoo/blob/6a3655c8efd2de68754ace38bd1ab5eb6499faca/addons/point_of_sale/static/src/app/models/pos_order.js#L27-L30

or from here

https://github.com/odoo/odoo/blob/6a3655c8efd2de68754ace38bd1ab5eb6499faca/addons/point_of_sale/static/src/app/utils/devices_synchronisation.js#L127-L139

-  Both safety nets happen to be bypassed here.

Fix:
* Tighten the early return condition so that data is only discarded when the current configuration is not a restaurant configuration.
* Also, A trusted PoS configuration cannot be a restaurant, so not returning later makes sense.

opw-6465228


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

### Issue:
In Germany, the intrastat report requires region code `99` for dispatch moves where the product origin country is not DE

Per the official specification (section 5.8 — Region of origin): "As for goods with foreign origin, code '99' should be entered"
https://erhebungsportal.estatistik.de/Erhebungsportal/api/assets/files?downloadId=0c5422f111104705b021b41616ad1ecc

But `99` was not being used in those cases

### Cause:
`99` was already the default fallback when no `region_code` is set but `_fill_missing_values` had no condition to override the region code for dispatch moves with a non-DE origin country

### Notes:
While fixing this, two additional issues were found when exporting with the German locale (`de_DE`):
- `weight` and `supplementary_units` are formatted with a comma as decimal separator by the German locale, causing `float()` to raise a `ValueError` — fixed by normalizing to dot before conversion, as done in other localizations
- The dispatch/arrival check was comparing against the translated label (e.g. `'Versand'`) instead of a stable identifier A new `intrastat_type_code` field with static values `arrival` and `dispatch` is added based on the existing `id` values from `default_type`, avoiding locale-dependent comparisons This improvement could be extended to other localizations
- Net mass is now rounded to full kilograms per item (see §5.14 of the specification linked above)
 A weight rounding down to 0 kg is reported as `0` instead of being silently dropped (QWeb `t-out` omits the element when the value is `None`)
Totals are computed as the sum of already-rounded per-item values to stay internally consistent

### Steps to reproduce:
- Install `sale_management`, `l10n_de_account` and `accountant`
- Switch to the DE company
- In Settings, configure the Intrastat values:
-- Default invoice transaction code: 11
-- Default refund transaction code: 21
-- Intrastat region: 07
- Create 3 products with a commodity code set and country of origin: one DE, one empty, one other country
- Create and confirm a Sale Order for all products with a European partner, deliver all, create and send the invoice
- Open the Intrastat report (Accounting > Reporting > Taxes & Fiscal > Intrastat)
- Set the month to the current month

Before the fix, all regions show 07
Expected: non-DE origin products should show 99

opw-6455585

Problem: When duplicating a section containing sale order lines, the system should preserve any manually modified unit prices on those lines.

However, the system would reset the unit price back to the product's default because the duplication process triggers a product onchange which resets the unit price on the order line.

Solution: This commit ensures the system recognizes when an order line is being copied as part of a section duplication. The system now uses a context flag to safely bypass the default price reset, allowing the original, manually modified price to correctly carry over to the duplicated lines.

Steps to reproduce(runbot v19):
1. Create a Quotation and add a product line under a section.
2. Manually modify the unit price on the product line to a custom value (e.g., set $10 to $99).
3. Click the section dropdown menu and click Duplicate.
4. Notice the duplicated product line incorrectly resets its unit price back to the default price ($10) instead of preserving the manually modified price ($99).

opw-6421922

**Steps to reproduce:**
* Install the **Manufacturing** module with **Work Orders** enabled.
* Create and confirm a Manufacturing Order with at least one Work Order.
* Open the **Shop Floor** view.
* On a work order card, click the **gear** icon to open the menu dialog.
* Click **Open Manufacturing Order** on a slow network connection.
* Before the MO form view finishes loading, quickly click the **gear** icon again and open another dialog (e.g. Log Note).
* The MO form view loads, destroying the shop floor component.
* Close the Log Note dialog.

**Observed behavior:**
* An `UncaughtPromiseError: Component is destroyed` error is thrown because the dialog tries to interact with the shop floor component that has already been destroyed by the navigation to the MO form view.

**Cause:**
* When the user clicks "Open Manufacturing Order", `doAction` is called to navigate to the MO form view, and `props.close()` immediately closes the menu dialog. However, the shop floor component is still visible while the new view is loading.
* During this gap, the gear button remains clickable. If the user opens another dialog (e.g. Log Note), that dialog holds a reference to the shop floor component. When the MO form view finishes mounting, the shop floor is destroyed, and closing the stale dialog triggers operations on the destroyed component.

**Fix:**
* Add an `actionPending` state flag to `MrpDisplayRecord`. When the user selects "Open Manufacturing Order" from the menu dialog, an `onSelect` callback sets `actionPending` to `true`, which disables the gear button and prevents any new dialog from being opened.
* The flag is only set for `openMO` (which navigates away and destroys the component), not for other menu actions like Scrap, Add Component, or Log Note which open wizard dialogs and return to the shop floor.

opw-6107579

Forward-Port-Of: odoo/enterprise#130831
Forward-Port-Of: odoo/enterprise#123490

Steps to reproduce:
------------------------------------
1. Install Time off module
2. Create New Fully Flexible Employee
3. Click on the Time off smart button
4. Create time off for multiple days (eg. Mon - Friday)

Observation:
------------------------------------
Number of days still shows 1 Days.

Issue:
------------------------------------
Issue occurs because `work_time_per_day_mapped` returns one interval per day for
standard and flexible schedules in multi-day time off requests, so the interval
count correctly matches the number of leave days.
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/hr_holidays/models/hr_leave.py#L460-L461

However, for fully flexible schedules, it returns a single interval
containing the total hours across all days, causing the leave duration to
always be computed as 1 day regardless of the actual number of days requested.

Solution:
------------------------------------
We extended the condition to also enter the flexible branch when `employee.is_fully_flexible` is True
(not just for single-day is_flexible leaves). Inside the branch, instead of hard-coding days = 1, we now compute the actual calendar-day span. Then we subtract any overlapping public holiday days (using a set to handle multi-day PHs and avoid double-counting). Subtract 0.5 for each half-day boundary. The hours computation (via Intervals subtraction) was already correct for multi-day ranges, so we kept that as-is.

opw-6060552

Forward-Port-Of: odoo/odoo#255826

### Issue:
An unexpected `<SchmeNm><Cd>CUST</Cd></SchmeNm>` node was added inside `<InitgPty><Id><OrgId><Othr>` for all countries
Some Italian banks reject SDD files containing this node

### Cause:
https://github.com/odoo/enterprise/commit/3c3c64b511d07fc1ba33c30363972f5b0f7283d6 added `<SchmeNm><Cd>CUST</Cd></SchmeNm>` unconditionally for all countries
The original fix was intended for Nordea (Sweden) only, which requires this node explicitly
The assumption that other countries would accept it was incorrect

### Steps to reproduce:
- Install `account_sepa_direct_debit` and `l10n_it`
- Switch to the IT company
- In Settings, set SEPA Direct Debit Creditor Identifier to `BE30ZZZ300D000000042`
- Create and confirm a Payment (Method: SEPA Direct Debit, any customer and amount)
- Create and validate a Batch Payment with that payment
- Open the generated PAIN008 XML

Before the fix, `<SchmeNm><Cd>CUST</Cd></SchmeNm>` is present

opw-6530996

Forward-Port-Of: odoo/enterprise#130304