**Steps to produce:**
- Install the `Sales` module.
- Enable `Pricelists` in settings and set the `default quotation template`.
- Create a new Sales Order.

**Issue:**
- The `Update Prices` button is visible even when no pricelist is set on the sales order.

**Root cause:**
- In the onchange logic (see [1]), show_update_pricelist is set to True based solely on the presence of order lines, without checking whether a pricelist is defined.

**Solution**:
- Update the condition so that button is shown only
  when sale order line is present and the current pricelist value is not
  the previous one.

[1]: https://github.com/odoo/odoo/blob/849ec71acbaea0061fd4b13888a486e4aebb6463/addons/sale/models/sale_order.py#L801-L803

Before:
<img width="1215" height="466" alt="image" src="https://github.com/user-attachments/assets/f29b1ccf-eec8-4114-b4c9-a8083947ad28" />

After:
<img width="1207" height="428" alt="image" src="https://github.com/user-attachments/assets/e358b633-d11b-413d-94c4-3837c430eac4" />


opw-5414897

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

Forward-Port-Of: odoo/odoo#241812

**Steps to reproduce:**
* Install the **Repair** module with demo data.
* From Setting -> enable 'Discounts' and 'Pricelists'
* From the home screen, search for Pricelist and open it.
* Open the default USD pricelist and go to Configuration →
`Show public price & discount to the customer`
* Open the *Repair* app.
* Create a **Repair Order with parts**.
* Click **Create Quotation** button from the repair order.
* In the quotation,  order line and set a **discount**.
* Return to the repair order using the **Repairs** smart button.
* Confirm the repair order, then **Start repair** and **End repair**  order.

**Observed behavior:**
* The discount added on the quotation line disappears from the linked sale order line.

**Cause:**
* The `discount` field on `sale.order.line` is computed by `_compute_discount`,
  which `depends` on `product_id`, `product_uom`, and `product_uom_qty`.
  When `product_uom_qty` is written during `action_repair_done`, the
  compute method is triggered and the `discount` is recalculated.
https://github.com/odoo/odoo/blob/49169c4c4fec57d78cd82c4c9366de9d69540e6a/addons/repair/models/repair.py#L457

**Fix:**
* Remove the for loop that calls `write()` on the sale order lines, as it
  is functionally incorrect and causes the discount to be reset.

---
opw-5352567

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

Forward-Port-Of: odoo/odoo#243075
Forward-Port-Of: odoo/odoo#238410

Description of the issue/feature this PR addresses:

Imagine a situation where a vendor is defined on a parent company and its bank account already exists. When importing an electronic invoice for that vendor on a child company, the search for a bank account linked to the same company would not find that pre-existing bank account on the parent company. When later trying to create it, the unicity constraint on (sanitized_acc_number, partner_id) would trigger, failing the import.

Current behavior before PR:

The electronic invoice cannot be imported if the same IBAN account already exists on the partner but on another company than the invoice being created, even though we are going to create the invoice for a partner linked to that other company.

Desired behavior after PR is merged:

Banks account already linked to the partner are found irrespective of the company, provided the partner (account holder) is the same. This should be correct since the res.partner.bank company_id is a related on res.partner.



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

Forward-Port-Of: odoo/odoo#242365

### Issue:
In 18.0-18.2, for product with a Manufacturing BoM containing a Component, a WO and a Quality Point
If a Reordering Rule is triggered, odoo try to add the newly ordered quantity to an existing MO
But if the MO is "locked" because a quality check has been performed, a Error is raised:
```
Odoo Warning
You cannot update the quantity to do of an ongoing manufacturing order for which quality checks have been performed.
```

### Steps to reproduce:
- Create a product tracked by quantity
- Add a BoM (1 component tracked by Quantity, 1 Operation with 1 Quality Point)
- Create a Reordering Rule (Route: Manufacture, Trigger: Manual, Min/Max: 1)
- Click on Order
- Open the created MO and the Shop Floor (Remove the filters to see the WO)
- Complete the Quality Point
- Modify the Reordering Rule (Min/Max: 2)
- Click on Order - the error should be raised

### Cause:
The MO to update is retrieved here:
https://github.com/odoo/odoo/blob/45184da06cf7b92a48e3e4e90bf8b285bdd9ad6a/addons/mrp/models/stock_rule.py#L53-L57 Using a domain defined in this function:
https://github.com/odoo/odoo/blob/45184da06cf7b92a48e3e4e90bf8b285bdd9ad6a/addons/mrp/models/stock_rule.py#L130-L153

In 18.0-18.2, when validating a `quality check` from the Shop Floor while the WO is in `waiting` state, the MO remains in `confirmed` state This makes the domain match the current WO and MO, triggering `change_prod_qty` even though the MO is locked

In 18.3–18.4, a similar issue can occur with multiple WOs when the first blocks the second and a `quality check` is performed on the latter
The `blocked` state behaves like `waiting`, but the issue is avoided when using the Shop Floor because this commit ensures that clicking a card starts the timer and changes the state to `progress`: https://github.com/odoo/enterprise/pull/84425/commits/67c2127424ef3a1eb4794edd2c262b94ef186561
However, it could still theoretically be triggered under specific conditions

In 19.0, the new stock.reference system (https://github.com/odoo/odoo/pull/212679) ensures the MO is detected as different, so a new one is always created

opw-5012588

Forward-Port-Of: odoo/enterprise#101313

**Steps to reproduce:**
- in settings enable "automatic accounting" and 
"anglo-saxon accounting"
- make sure dollar is the main currency
- activate euro as another currency
- set a rate for today as 1$->10 euros
- set another rate for a week ago 1$->2euros
- create a storable product with standard price/automated 
category and a cost of 10
- create a new invoice for 1 unit of your product
- do not set a date on the invoice
- set the currency as euro 
- click on the calendar widget to choose the rate and select the
date of yesterday
(- the rate applied should now be 1$->2euros)
- confirm the invoice

**Current behavior:**
the cogs line (credit stock interim delivered and debit expenses)
have a value of 5

**Expected behavior:**
the cogs value should be 10. It shouldn't be impacted by the 
currency rate.

**Cause of the issue:**
when the invoice is confirmed, because there is no date, 
the date is set at today inside _post()
https://github.com/odoo/odoo/blob/626d06734991bcd3b94a6c9454317f311164e9dc/addons/account/models/account_move.py#L5090
This results in a call to write with invoice_date in the vals.

Inside the override of the write() method of AccountMove, 
the call to super is inside a 'with self._sync_dynamic_lines' bloc.
https://github.com/odoo/odoo/blob/626d06734991bcd3b94a6c9454317f311164e9dc/addons/account/models/account_move.py#L3413-L3419
So the first part (up until the yield) of _sync_dynamic_lines is 
executed before the call to super.
In _sync_dynamic_lines() the yield is inside a 'with _sync_invoice'
bloc. 
https://github.com/odoo/odoo/blob/626d06734991bcd3b94a6c9454317f311164e9dc/addons/account/models/account_move.py#L3239-L3241

As a result, the first part of sync_invoice() (until the yield) is 
executed before the call to super method write().
https://github.com/odoo/odoo/blob/626d06734991bcd3b94a6c9454317f311164e9dc/addons/account/models/account_move_line.py#L1513-L1515
And the second part is executed after the call to write() and 
after the update of line_container['records'] inside 
_sync_dynamic_lines().

Because the change of date, changes the currency_rate, 
changed('currency_rate') will return True, and the balance will 
be recomputed for each line. 
https://github.com/odoo/odoo/blob/0dabb221225fba96c0e55779afadd9f12b369777/addons/account/models/account_move_line.py#L1524-L1530

This causes 2 problems: 
1) for the non cogs line, the rate set manually by the user 
is replaced by the rate of today
2) for the cogs line, a rate is applied where no currency 
rate should be applied at all.

The problem 1) was fixed in this PR https://github.com/odoo/odoo/pull/239012
But this does not fix problem 2) as the fix consists in letting the 
recomputation happen for the balance of the account move lines
and then re-recompute their balance in the manually set currency_rate.
Whereas for our cogs line we need no currency_rate based 
recomputation at all.

**fix**
prevent balance recomputation based on currency_rate change
for cogs lines.

opw-5266804

Forward-Port-Of: odoo/odoo#240006

Currently, a traceback occurs when a user tries to create a payslip for a contract 
that has no working schedule in a Belgian company.

**Steps to reproduce this issue:**

1) Install l10n_be_hr_payroll and hr_attendance and switch to BE company 
2) Create an employee with no working hours.
3) Create a contract for that employee with:
   - Work entry source as Attendance
   - No Working Schedule
   - State should be open/running 
4) Click the Payslip smart button to create a new payslip for that contract. 
5) A traceback occurs

**Error:**
```
ValueError: Expected singleton: resource.calendar()
```
**Cause:**
When creating a payslip for a contract with no resource_calendar_id, 
the method `_get_work_hours_split_half` calls `_get_max_number_of_hours` 
through self.resource_calendar_id. Since the contract's calendar lacks a 
resource_calendar_id, this triggers a ValueError in `_get_max_number_of_hours`. https://github.com/odoo/enterprise/blob/193b51ded0dfa46ed75f6c0020f0f5609f4a0f99/l10n_be_hr_payroll/models/hr_contract.py#L472

**Solution:**
If the contract or employee does not have a resource_calendar_id, 
use the default resource_calendar_id from the company instead.

opw-5237559

Forward-Port-Of: odoo/enterprise#99217

**Steps to reproduce:**
- enable automatic accounting
- set dollars as the main currency
- activate euro and set a rate of 10 euro -> 1$
- create a storable product with category fifo/ automated
- create and confirm a PO for 1 unit for 10 euros (no tax)
- validate the receipt
- return the product and validate return
- return the return and validate
- open journal items and search your product

**Current behavior:**
- there is 6 correct lines (those with credit or debit of
1$)
- there is two incorrect extra lines one with credit 9$ and
one with debit 9$

**Expected behavior:**
those two extra lines should not be there

**Cause of the issue:**
those lines are compensation account move lines
for the case where the price of the product returned
is different than the price of the product initially received,
in the cases of:
- a return: compensate the difference.
- the return of a return (our case): de-compensate the difference.

(see PR https://github.com/odoo/odoo/pull/162697 and more specifically
test test_fifo_return_twice_and_bill).
But in this case, the compensation is wrongly triggered because
the difference comes from the fact that the currency is not
taken into account.
https://github.com/odoo/odoo/blob/c89d109c460d51fc90b6b13d5f6bc114c7316e42/addons/purchase_stock/models/stock_move.py#L208

**Fix:**
we use the original svl instead of the PO
because it avoids currency problem.
If we wanted to convert the currency of the PO,
we would need to find the date that was used to convert
the value at the creation of the first svl.
And that date came from _get_currency_convert-date()
https://github.com/odoo/odoo/blob/d3599e70973e27ed17e403cf498f76bd31e9c236/addons/purchase_stock/models/stock_move.py#L97
which can take the date of the last invoice
(if product was invoiced before the move was validated).
https://github.com/odoo/odoo/blob/57c1c510425dcd491c794a0262063db398348640/addons/purchase_stock/models/stock_move.py#L123-L125
We can not use this method because we're doing the
return of a return and if the first return
also has an invoice, the return value
of the method could be the date of this invoice
(which is not the date we're looking for).
Furthermore there is no way to know if the date returned
by _get_currency_convert_date() at the time of the creation
of the first svl is the date of the time of the creation of
the svl or the date of an invoice previously confirmed.


opw-5179239

Forward-Port-Of: odoo/odoo#238904