### Issue:

Although Fedex's API shoud accept GBP's UK currency for rate requests, you will raise a `CURRENCY.TYPE.INVALID` error from Fedex if you try to get the shipping rate for an order whose currency is GBP.

### Steps to reproduce:

- Install UK accounting and select UK's company: the currency will be GBP
- Install and set up Fedex Integration
- Configure the Fedex in the delivery method, FEDEX_YOU_PACKAGE and Fedex priority for package type and service type
- Create a sale order, add shipping and get the shipping rate for your set up fedex UK.
#### > Fedex request error: `CURRENCY.TYPE.INVALID`

### Cause of the issue:

The currency used in the fedex request is the currency of the order: https://github.com/odoo/enterprise/blob/07845988daad911b10de3b7199b81cc4ed3cfba9/delivery_fedex_rest/models/delivery_fedex.py#L133-L141 that is GBP, however since 44e32359bb79eed08a41861e155c98f664c6d09a we do not automatically convert the GBP currency in UKL. Since Fedex API does not seem to support the GBP we raise the error.

### Fix:

We should use the currency conversion available between GBP and UKL.

opw-4712354

Forward-Port-Of: odoo/enterprise#83388

Before this commit, the function _generate_deferred_entries was basically a big for-loop in which a lot of account.moves and lines are created in each iteration. This was extremely inefficient because it wasn't leveraging any batch optimization of the ORM. This PR breaks down the for-loop into smaller ones that aggregate vals and performs a single call to create records, instead of individual creations. Same approach was taken for unlinked records and posting moves.

The assumption is that records are created in the same order of the values list. This allows for breaking the for-loop because consecutive for-loops can simply inherit the order from the lists created in the loop just before. Another leverage point is that simply adding move_id to account.move.line(s) before creation is equivalent to `move.write({'line_ids': \[...\]})`. Based on the 2 assumptions, we could decouple the creation of moves and their lines into separate loops to aggregate their values.

After this PR creations, unlinks and posting operations are all batched to leverage the power of ORM optimization.


Benchmarks:
|Num deferred expenses | Time before | Time After | Num queries before | Num queries After |
|--------------------- | ----------- | ---------- | ------------------ | ----------------- |
| 100 		| 23.9s 	| 13.1s 	| 3768 		| 2918 			   |
| 1,000 	|181.4s      	| 66.5s       	| 17885         | 9530              	   |
| 10,000	|TIMEOUT(>1200s)| 616,7s    	| 1379          | 1010              	   |

opw-4480919
opw-4403217

Forward-Port-Of: odoo/enterprise#81440
Forward-Port-Of: odoo/enterprise#79255

Currently, when validating multiple deliveries at once for which at least two are from the same sale order, the related shipping labels are getting printed multiple times.

Steps to reproduce:
-------------------
* Install fedex
* In operation types, select Delivery Orders then hardware
* In print on validation, enable Carrier Labels
* In the shipping methods, select fedex international
* Change Label format to ZPL11
* Connect the database to an iot box
* Set up the shipping labels to be send on zebra printer
* Create a sale order, using fedex international as shipping
* Confirm the SO
* Select the delivery
* Duplicate the delivery
* Validate both deliveries delivery
> Observation: I have 4 jobs send for printing instead of 2

Why the fix:
------------
Actually the issue has the same explanation as this commit https://github.com/odoo/enterprise/commit/34267c4fa8c9aaa7c0216de13111a81fb53a67f1

as the IoT overrides `message_post` to send printing jobs each time a message is posted in the chatter.

https://github.com/odoo/enterprise/blob/8075101192fb81a78f2a984cf2adf67fc77c0194/delivery_iot/models/stock_picking.py#L30-L46

opw-4526013

Forward-Port-Of: odoo/enterprise#82091

When the user tries to reply a whatsapp message,
a traceback will appear.

Steps to reproduce the Error:
- Install ``whatsapp`` and ``contacts`` module
- Go to WhatsApp > Configuration > WhatsApp Business Account >
  create a new account > Default Users: Mitchell Admin > Save
- Go to Contacts > Open Mitchell Admin > Set Phone > Click on Whatsapp >
  Send a message with any template
- Contact will receive the message > Reply to that whatsapp message

Traceback:
```
UniqueViolation
duplicate key value violates unique constraint "discuss_channel_member_partner_unique"
DETAIL:  Key (channel_id, partner_id)=(84, 175) already exists.
```

https://github.com/odoo/enterprise/blob/daac4da302e63f87fe3f244099e26b47d08d7cfb/whatsapp/models/discuss_channel.py#L250 At lines [1] and [2], the same partner(s) (e.g., Mitchell Admin) are added to
``partners_to_notify`` multiple times.
Channel members should be unique.
So, when it tries to create ``channel_member_ids`` with same partners,
It will lead to the above traceback.

1- https://github.com/odoo/enterprise/blob/daac4da302e63f87fe3f244099e26b47d08d7cfb/whatsapp/models/discuss_channel.py#L219

2- https://github.com/odoo/enterprise/blob/daac4da302e63f87fe3f244099e26b47d08d7cfb/whatsapp/models/discuss_channel.py#L249

sentry-6252537579

Forward-Port-Of: odoo/enterprise#83908

## Version:
18.0+

## Issue:
PDF quotes on multiple pages having only the total table on the last page encounter a display issue. The total table is cut and partially displayed at the bottom of the penultimate page.

## Steps to reproduce:
- Install Sales app;
- Navigate to the Settings app:
    - Under the `Companies` section, configure the document layout: - Ensure the `Bubble` (or `Boxed`) layout is selected;
- Navigate to the Sales app:
    - Create a new quote with 8x `Chair floor protection`;
    - Via the `Actions` gear button, print the `PDF Quote`.

## Cause:
Complete code refactoring for documents layouts styles introduced by https://github.com/odoo/odoo/pull/169512 has probably not been tested on that use case.

## Fix:
<img width="1105" alt="Capture d’écran 2025-04-03 à 10 25 58" src="https://github.com/user-attachments/assets/67bce15e-c5e9-40f8-9fbf-7721afc98ae5" />

opw-4624623
opw-4627809

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

Forward-Port-Of: odoo/odoo#204575

Currently, since we read most data from cache, if an employee right was changed, it is not reflected in the pos.

Steps to reproduce:
-------------------
* Enable "Log in with employees" and set some records for each field.
* Open session, make a sale, close register
* Edit employees configuration, delete one, change rights advanced -> minimal
* Reopen the session
> Observation: The employee deleted is still visible in the list of cashiers
and the employee that has now minimal rights is still having advanced rights.

Why the fix:
------------
When removing rights from an employee it is important to have it reflected as soon as possible.

A possible solution would have been to recompute `last_data_change` when making any modification on the employee rights but this would recompute everything and we lose the performance added by the caching feature.

Instead, by adding the model to `uniqueModels` we ensure that anytime we reload the pos, all `hr.employee` records will be dropped from the indexedDB, which ends up using the data loaded.

https://github.com/odoo/odoo/blob/5d52373b4c9d64968316c4e883d6b49c7cd1d048/addons/point_of_sale/static/src/app/services/data_service.js#L246-L251

Fix during forward:
-------------------
The data related to hr employees is not sent to the frontend.

After this commit https://github.com/odoo/odoo/commit/96ee0b6288e4cc16aaf45162c5341fd2b9c7e60f
there is a difference in the data loaded regarding hr_employees.

With this change:
https://github.com/odoo/odoo/commit/96ee0b6288e4cc16aaf45162c5341fd2b9c7e60f#diff-86db45bc09231ecbc49a64405de92e0a022a6833980f46a9111501f8c8832760L172-R175
We see that we first load data with `_load_pos_data` then that data is post processed with `_post_read_pos_data`

`_load_pos_data` does not return any product. Previous to the commit, `_post_read_pos_data` was called `_load_pos_data` and the domain to read hr employees was:

`self._load_pos_data_domain(data)`

but now the domain is computed withinh `pos_load_mixin.py` with

`self._server_date_to_domain(self._load_pos_data_domain(data))`

So now the only hr employees that are going to be loaded to the frontend are the employees which have been modified after `_last_data_change`.

Since hr employees are needed to know which rights they have we want to load those related to the config everytime.

opw-4699241

Forward-Port-Of: odoo/odoo#206099

Steps to reproduce:
Using POS configs in french company with l10n_fr_post_cert module installed.
- Checkout 1: Prepare an order with several lines held in stock, to ensure that Odoo takes sufficient time for payment.
- Cash desk 2: Prepare an order
- Cash-desk 1: Start order payment.
- Cash-desk 2: Start order payment while cash-desk 1 is still paying.

Issue:
When writing 'paid' in a pos_order the l10n_fr_post_cert sets the l10n_fr_pos_cert_sequence_id field. A competition error occurs on cash desk 2 during payment: could not obtain lock on row in relation “ir_sequence”. The odoo.service.model retries to create the order and since the ir_sequence of pos_config used in the pos_order name is not set to "no_gap", the pos_order names have a gap equal to the number of retries.

Task-4708543

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#207555
Forward-Port-Of: odoo/odoo#205935

XLS(X) allows to store in cells date/datetimes values as date/datetime objects. Meaning, instead of having a string with the date in some format, the cell value can hold an actual date/datetime object, which are automatically converted into the `datetime.date`/`datetime.datetime` when the xls(x) file is parsed in python.

When an xls(X) file contains at the same time date values under date/datetime objects and under strings with the user format `%d/%m/%Y` (rather than the server format `%Y-%m-%d`),
the import was failing with the error
`time data '06/30/2025' does not match format '%Y-%m-%d'`

This error normally happens when the user tries to do an import with different kind of date formats under strings in the same file e.g. `06/30/2025` and `2025-07-01`
and this is understandable that Odoo doesn't know what to do in such a case.
But, if you stick to the same format, either only `%d/%m/%Y` either only '%Y-%m-%d'`, Odoo supports it.

However the case here is trickier: it's when the file contains at the same time dates under a string format, e.g. `06/30/2025` and under date objects, e.g. `datetime.date(2025, 6, 30)`. Which can happen quite easily, as Google Spreadsheet for instance tends to automatically convert the cells holding a date value into date object. And it's then easy to have a file containing both date objects and strings for date, which looks visually the same in the Google Spreadsheet interface.

In addition Google Spreadsheet tends to convert automatically only dates below the 12 of the month because of the american format. e.g.
if you set `01/06/2025`, it gets converted into a datetime object if you set `13/06/2025`, it doesn't get converted into a datetime object, the value stays as a string.

The goal of this revision is to support to have the possibility of having date values under date objects and string in a user format

The problem lied in the fact, during the xls parsing, date objects were converted into strings using the server date format. And then you could finish with data containing both the user format and the server format.

The idea is to no longer automatically convert date objects and to support having date objects in the import parsing. And when trying to guess the date/datetime format of the file, date objects are simply ignored, as they do not need to be parsed.

Forward-Port-Of: odoo/odoo#206876

Versions
--------
- saas-17.4+

Steps
-----
1. Create a SO for non-user client;
2. add a product that isn't published on the website;
3. confirm SO;
4. create downpayment;
5. copy share SO link;
6. open link in private window.

Issue
-----
> 500: Internal Server Error
> Error while render the template
> ValueError: Expected singleton: product.product()

Cause
-----
Commit 9aa52dd6418e removed the creation of a "Down payment" product. Before it, order lines were either of type `display_section` or they had a `product_id` value. After the commit, a third option is for `is_downpayment` to be true.

This regressed the fix to this issue added by 34d4ffa01d57d, as instead of ensuring lines have a `product_id` value before checking if reorder is allowed, it decided to check whether they're not of `display_type`.

Solution
--------
Ensure there's a `product_id` in `sale.order.line` instead of only relying on the caller to filter those out beforehand.

opw-4711297

Forward-Port-Of: odoo/odoo#207772
Forward-Port-Of: odoo/odoo#206435

The default rounding method of '_compute_quantity' function is "UP" while the rounding method used for stock quantities is "HALF-UP". Hence, small discrepancies in the valuation would be introduced over time.

## How to reproduce
- Create product P, storable, tracked in Kg
- Create a receipt/delivery move for 14g of P -> Stock Quant is updated by 0.01Kg
-> Stock Valuation is updated by 0.02Kg

OPW-4734980

---

Test result without fix:
```
2025-04-22 13:40:45,088 38626 ERROR oes_test_16 odoo.addons.stock_account.tests.test_stockvaluation: FAIL: TestStockValuation.test_valuation_rounding_method
Traceback (most recent call last):
  File "/home/odoo/projects/odoo-src/multiverse/src/16.0/odoo/addons/stock_account/tests/test_stockvaluation.py", line 4397, in test_valuation_rounding_method
    self.assertEqual(receipt.move_ids.stock_valuation_layer_ids.quantity, 0.01)
AssertionError: 0.02 != 0.01
 ```

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

Forward-Port-Of: odoo/odoo#207401
Forward-Port-Of: odoo/odoo#206884

Currently an exception was generated when the user tries to save the new employee record after clicking on call icon.

Steps to reproduce:
1) Install HR module
2) Create a new employee record by giving employee name 
3) Click on the call icon of work phone
4) Now tries to save the new employee record

Error: `KeyError:  name`

This issue occurs because, while clicking the call widget, it creates the record but does not update it in the browser.

As a result, when the user tries to save manually, It again  creates the record with an empty vals_list.

So it will leads to the above traceback from the below lines

https://github.com/odoo/odoo/blob/2d64d94487d24278dc3c6615343a793e1ec94daf/addons/hr/models/hr_employee.py#L386

This fix resolves the issue by ensuring that clicking the call icon before saving retains the user input. Additionally, I have added a test to verify this behavior.

sentry-6234873849

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

Forward-Port-Of: odoo/odoo#206710
Forward-Port-Of: odoo/odoo#195278

**Steps to Reproduce:**
- Go to Sales
- Make a user-defined filter and make it the default filter
- Try to access the JSON link (/json/sales)
- You will see an error

**Issue:**
- When users apply default filters like 'My Quotations' or 'My Documents', Odoo saves 'uid' in the filter's domain to represent the logged-in user.
- However, when the system tries to process this filter, it fails because 'uid' is just a placeholder and not a valid value. This results in an **internal server error**, preventing users from applying these filters correctly.

**Cause:**
This issue is caused after this commit: https://github.com/odoo/odoo/pull/182196
- The domain string stored in 'ir.filters' includes 'uid' instead of the actual user ID.
- When Odoo('ast.literal_eval()') tries to evaluate the filter, it doesn’t know what 'uid' means, causing an error.

**Fix:**
- Replace 'uid' with `str(model.env.uid)` before evaluating the domain.
- This ensures 'ast.literal_eval()' processes a valid domain.

**Affected version:** 18.0~master
**opw**-4645608

Forward-Port-Of: odoo/odoo#202890