Currently, an error occurs when the user immediately removes a catalog product after adding it.

Steps to Reproduce ([Video](https://drive.google.com/file/d/12hOavt1zCa6hbG0EWHsIDGxfgVkxJmLW/view)):
 - Install the `sale_management` module.
 - Go to `Sales Orders` and create a new `sale order`.
 - In the order line, click on the `Catalog` button.
 - `Add` a product and then immediately `remove` it.

`ValueError: Expected singleton: sale.order.line()`

After [this commit], when the user clicks the Remove button immediately after clicking the Add button (within 500 ms). In this case, the system proceeds with the last request due to the useDebounced delay [1], which removes the product. However, since there is no order line yet for that product [2] and the quantity is 0, the order line [3] is not created. When it attempts to retrieve the discounted price, it raises the error [4].

This commit ensures that if no order line exists, the product's price is returned according to the sale order's pricelist.

[this commit]: https://github.com/odoo/odoo/pull/233098/commits/697c559791fdf00b5602b9459bbdf21f392757d8

[1]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/product/static/src/product_catalog/kanban_record.js#L17-L19

[2]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/sale/models/sale_order.py#L2202

[3]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/sale/models/sale_order.py#L2218-L2219

[4]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/sale/models/sale_order_line.py#L1602-L1603

sentry-7019831319

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

Forward-Port-Of: odoo/odoo#235470

## Issue:
When you have an allocation and set a leave for that period, if you add a new allocation for that period and you validate it, it will be impossible to Refuse this allocation later
A UserError was raised asking to remove the leave even if it should be linked to the first allocation created

## Cause:
The `action_refuse()` method for `hr.leave.allocation` uses the `virtual_leaves_taken` value inside the `_get_consumed_leaves()` function's result
That parameter is calculated for the allocation as far as it state is `validate`, for all the leaves in that time interval, including previously created leaves
The leaves will be allocated to the last allocation created, so the last one can't be removed later
As a result, the allocation is considered as already used by these pre-existing leaves, even if the leave can still be modified to return to the state prior to the allocation's validation

## Steps to reproduce:
- Create an initial Allocation (that should end after the next created Allocation)
- Create a Leave from 22/12/2025 to 31/12/2025
- Create an Allocation including the leave period (01/12/2025 to 31/12/2025)
- Validate, then Refuse

opw-4900686

Forward-Port-Of: odoo/odoo#235711
Forward-Port-Of: odoo/odoo#222171

### Issue:
When importing a CSV file with bank statements, if an error is raised during the reconciliation, the creation of the bank statement lines is roll backed.

### Steps to reproduce:
- Install "account_bank_statement_import_csv"
- In the bank journal configuration:
	- Set the "Outstantding Receipts accounts" of "Manual payments" to a "Bank" account
	- Set the "Outstantding Payments accounts" of "Manual payments" to the same "Bank" account
- Create a new transaction for $333.0 for example
- Find its Journal Entry and change its reference to 'testref'
- have a CSV file like this:
```
label, amount
testref,333
```
- Import this file
- Make sure label is linked to label and amount to amount
- Import
- An error shows, no lines are imported

### Cause:
On import, we try to auto reconcile the lines using `_cron_try_auto_reconcile_statement_lines` ([here](https://github.com/odoo/enterprise/blob/843a17367525c80653d37ecdd9d87434d3e92454/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L146)). If an error occurs during the reconciliation, we call `self.env.cr.rollback()` [here](https://github.com/odoo/enterprise/blob/843a17367525c80653d37ecdd9d87434d3e92454/account_accountant/models/account_bank_statement.py#L190-L192).

This rollback cancels the transaction, including the creation of the statement lines.

### Solution:
If the error raised is a `UserError` then we don't roll back and just ignore it. This causes no issues as we caught all exceptions to always continue the reconciliation with the next batch. For UserErrors we should let the user reconcile manually afterward.

Also, as the rollback can undo the creation of `st_lines`, we add `if st_lines.exists():` before writing on the variable.

Test is not possible as we don't roll back during tests. 

opw-5138855

# How to reproduce the issue:
- Create two currency rates: one for today and one for the day before.
- Create two invoices with different `amount_total`, both using the rate from yesterday.
- Create a group payment dated today.

Check the generated payment, its journal entry, and the reconciled items. Two exchange moves are created — one for each invoice. However, on the invoices themselves, only one of those exchange moves is associated with both invoices.

Since commit 5420e40ff337080912edf7414257e03853be026a, the logic that associates exchange moves to `account.partial.reconcile` records was changed.

It links an exchange move to a partial if any of its reconciled lines match either the partial's `debit_move_id` or `credit_move_id`.

In a group payment scenario:
- Two partials are created (one per invoice).
- Each has a different `debit_move_id` (the invoice lines) but shares the same `credit_move_id` (the single payment line).
- As a result, both partials match the same exchange move via the shared credit line — leading to incorrect assignment.

opw-5147281

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

**Issue**
In replenishment, filtering with `to_order = 0` does not correctly exclude records where `to_order != 0`.

**Steps to reproduce**
1. Go to Inventory > Operations > Procurement > Replenishment
2. Create a replenishment with a forecast quantity smaller than the min and max quantity (without editing the To Order)
3. Apply a custom filter `to_order = 0` → Records with non-zero `to_order` are incorrectly included

**Cause**
`qty_to_order` was split into `qty_to_order_computed` and `qty_to_order_manual` in [this commit](https://github.com/odoo/odoo/commit/156bed3f430d706e13822bbd95d91c8dfd3ea42d#diff-0eb18a8d7773b5f99b402392188594178c3ba2004e4bcab26dbc84b1c8d7256a).

In the [`_search_qty_to_order` method](https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_orderpoint.py#L338), all records with `qty_to_order_manual = 0` are included. Since `qty_to_order_manual` defaults to 0 when untouched by the user, this causes incorrect results.

Additionally, [`to_order`](https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_orderpoint.py#L323) displays `qty_to_order_computed` if `qty_to_order_manual = 0`, creating inconsistency.

**Solution**
Fix the inconsistency by ignoring `qty_to_order_manual` when searching for zero `to_order` values.

opw-5150643

Forward-Port-Of: odoo/odoo#234908

Steps to reproduce
-----
- Create a Sendcloud delivery method
- Select a delivery service with "Locker or service point" as "Last mile" (eg  "bpost @ bpack")

> "Use Sendcloud locations" is set to false

Cause
-----
There is a problem with the values retrieved from the Sendcloud API call, more specifically the `available_functionalities` > `last_mile` value.

The Sendcloud API (of both previous and current beta version) specifies the possible values to only be the following
- `home_delivery`
- `mailbox`
- `pobox`
- `service_point`
- null
https://api.sendcloud.dev/docs/sendcloud-public-api/shipping-options/operations/create-a-shipping-option
https://api.sendcloud.dev/docs/sendcloud-public-api/branches/v2/shipping-products/operations/list-shipping-products

However, it seems like they have added some new undocumented values `locker` and `locker_or_service_point`.

To detect whether to use drop-off locations, we do
https://github.com/odoo/enterprise/blob/5b64c63301bc814c7c9d99146af6a86d37563762/website_delivery_sendcloud/models/delivery_sendcloud.py#L51-L53

Where we compare the retrieved value with the string 'Service point'
https://github.com/odoo/enterprise/blob/5b64c63301bc814c7c9d99146af6a86d37563762/website_delivery_sendcloud/models/delivery_sendcloud.py#L13

In our "Locker or service point" case, this does not work because the `in` operator makes a case sensitive comparison.

Solution
-----
Functionally, both lockers and service points work the same. The user should be prompted a map on which they choose where the delivery should be dropped off.

So we can add `Locker` and `Locker or service point` as accepted values and enable the use of sendcloud locations for both.

-----
Ticket:
opw-5217796

Forward-Port-Of: odoo/enterprise#98875

before this commit, when trying to reprint a past order it would not work. Instead it would print the last order no matter what order is selected.

Steps to reproduce:
1. setup an DB with an italian POS
2. make 2 sales with a different product (easier tracking)
3. open the "orders" view
4. try to reprint the ticket of the firt order result: the receipt of the second order is printed

the reason for this is that we were using the printer's built in command "printDuplicateReceipt" which is inteded for printing the very last receipt.

With this commit, we changed the behavior and invoke another printer command. That command is meant to reprint any receipt, based on the provided reference. After this commit, trying to print any past receipt will print that exact receipt.

IMPORTANT NOTE:
In theory, the printer command can reprint any number of receipts. We decide that we will only use it to reprint the one receipt selected by the user. This moves the complexity of parsing date strings and ranges to the command component and therefore will keep the rest of the code cleaner.

opw-5008702
opw-4882480

Forward-Port-Of: odoo/enterprise#96122

### Steps to reproduce the issue:

(Easier to reproduce client side with CRM installed)

0. Install crm
1. Create Second Company
2. Create New User with Current Company as Default Company and Second Company in Allowed Companies
3. Create CRM Team belonging to Second Company
4. Add New User to Members of CRM Team
5. Receive error:

>     [New User] belongs to company [Current Company] and "Sales Team" (crm_team_id: [CRM Team]) belongs to another company.

### Explanation:

`crm.team.member` is created when adding `res.users` to `crm.team.member_ids`. Contrary to `res.users`, a company_check is done when linking `crm.team` and `crm.team.member` together. `crm.team.member.company_id` is related to `user_id.company_id` and, in the case above, does not match `crm.team.company_id`, raising an error because of it.

### Fix reasoning:

Removing restriction, as we want to avoid other multi-company issues by changing the behaviour.

opw-4214192

---

@nd-dew note:
Situation recap
![image](https://github.com/user-attachments/assets/9377ec70-0a57-4a48-b071-de588cde06a6)

So it was proposed to modify the field definition, seems to me that removing `check_company` from the field definition is a legal move, since it is an ORM level constraint (doesn't change db schema). 

However looking at the tests it seems like this is desired limitation.

Note that https://github.com/odoo/odoo/pull/171079 introduced checking for allowed companies, but the **default company** still takes priority.

Forward-Port-Of: odoo/odoo#189441

Versions
--------
- 18.0+

Steps
-----
1. Have a minimal database with `event_product` installed;
2. run `:TestEventProduct.test_ensure_event_service_tracking`.

Issue
-----
> FAIL: TestEventProduct.test_ensure_event_service_tracking
> AssertionError: ValidationError not raised

Cause
-----
The test works as expected with `sale_project` installed due to a `write` override of `product.product`, setting the `service_tracking` to 'no' if `type` is no longer 'service': https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/sale_project/models/product_product.py#L25-L30

This change still occurs without `sale_project` installed, but via the `_compute_service_tracking` method defined in `product`: https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/product/models/product_template.py#L181-L183

As this value is set via a compute method instead of `write`, the `_check_event_ticket_service_tracking` method isn't triggered, and no error is raised.

Solution
--------
Simulate a front-end flow by changing the `type` to 'consu' on a product form. This way, the constraint method does get triggered as expected.

runbot-234024

Forward-Port-Of: odoo/odoo#236045