Currently, an error occurs when a user creates an attendance for an employee.

**Steps to Reproduce ([Video](https://drive.google.com/file/d/1vm89hHBOVcliYwZjP7fwNOzwC68V3B1l/view)):**
 - Install the `hr_attendance` module.
 - Go to `Overtime Rulesets` and create a `new overtime ruleset` by adding an `overtime rule`. 
    Set Based on to `Timing`. 
    Set the `Start time greater than the Stop time` (ex, Start = 10 and Stop = 5).
 - Go to `Employees`, open `any employee record`, and assign this `Overtime Ruleset` to the employee.
 - Now go to `Attendances` and `create an attendance` for that employee.

`TypeError: '>' not supported between instances of 'datetime.datetime' and 'int'`

**Cause:**
This error occurs when a user sets the overtime rule on an employee and then creates an attendance. At that point, the system tries to calculate the overtime intervals based on the timing rule. Because the rule’s start time is greater than the stop time, it attempts to calculate the interval for the remaining working period of the day. However, the start date and end date are calculated in datetime format [1], while integer and float values are passed as arguments [2] for day in interval calulation. Since the interval expects values of the same data type, than it raise the error [3].

**Fix:**
This commit ensures that the day start and day end values are passed in datetime format.

[1]: https://github.com/odoo/odoo/blob/67191cf0915081df352331a698be47b7e3ecd505/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L524

[2]- https://github.com/odoo/odoo/blob/67191cf0915081df352331a698be47b7e3ecd505/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L530

[3]: https://github.com/odoo/odoo/blob/67191cf0915081df352331a698be47b7e3ecd505/odoo/tools/intervals.py#L138-L154

sentry-7166788786

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

Forward-Port-Of: odoo/odoo#242491

**Steps to reproduce:**
* Install the **stock** and **sale_management** modules.
* Go to *Inventory > Configuration > Attributes* and create a new
  attribute.
  * Set *Variant Creation Mode* to *Never*.
  * Add a single attribute value and enable *Free text* on it.
* Create a product using this attribute and select the value for which
  *free text* is enabled.
* Create a Sale Order for this product.
  * Open the sale order line pop-up and enter custom text in the *Text* field.
* Confirm the sale order.
* Open the generated Delivery Order.

**Observed behavior:**
The product name appears **twice** in the stock move description.
The same duplication appears in the **Delivery Slip** PDF report.

**Cause:**
https://github.com/odoo/odoo/blob/452800a9fd56539c04bed5dcf4525afb9b8ad28e/addons/sale_stock/models/stock.py#L31-L32
In `_compute_description_picking`, the description is built as description + variant description.
Since Odoo already uses the product name as the base description and avoids rendering
it twice only when the name equals the description, concatenating the variant description
breaks this logic and results in the product name being repeated.

---

<details>
    <summary>Click here to see the results:</summary>
    Before:
    <img src="https://github.com/user-attachments/assets/2f76fcc9-c71d-4c3d-a80a-06391e5d863c" />
    After:
   <img src="https://github.com/user-attachments/assets/78eb7905-8ce6-42b9-aed3-ac1452b74dc1"/>

</details>

---

opw-5382353

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

Forward-Port-Of: odoo/odoo#239843

**Steps to produce:**
- Install `sale_subscription,website_sale` module.
- `Subscription > Configuration > Recurring Plans`.
- `Archive` the `Monthly` plan.
- Go to website > Shop > Open product `Car Leasing (SUB)`.

**Issue:**
- Even after archiving the Monthly recurring plan, its pricing still appears on the website product page.

**Root cause:**
- At [1], when searching for a suitable recurring price, the system does not filter out pricing records belonging to archived recurring plans.
- As a result, inactive plans are still considered during pricing selection.

**Solution:**
- In this fix, we ensure that recurring plan pricing is included only if the related plan is active.
- Archived plans are now ignored, preventing them from appearing on the website.

[1]: https://github.com/odoo/enterprise/blob/25edaac85f8fd1699bb78163b01efb966e7fb680/sale_subscription/models/sale_subscription_pricing.py#L78-L79

before
<img width="340" height="184" alt="recurring_plan_before" src="https://github.com/user-attachments/assets/abac39fb-5765-4bc4-aec3-87eef7135a18" />

after
<img width="337" height="168" alt="recurring_plan_after" src="https://github.com/user-attachments/assets/35ee92e8-e66b-4612-add3-58b277560ea5" />

**opw-5266333**

Forward-Port-Of: odoo/enterprise#103473
Forward-Port-Of: odoo/enterprise#100587

**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

### Issue:
When running the scheduled action "Payroll: Generate pdfs" for several payslips, nothing is generated and a traceback can be seen in the logs.

### Steps to reproduce:
- Disable scheduled action: "Payroll: Generate pdfs" (to avoid side effect in next step)
- Refuse all time off for "Anita Oliver" (to avoid side effect in next step)
- Create a user for the employee "Anita Oliver"
- Link the employee and the user
- Create 2 payslips
	- 1 for "Mitchell Admin"
	- 1 for "Anita Oliver"
- Compute sheet and confirm both payslips
- Run scheduled action: "Payroll: Generate pdfs"
- Nothing happens

### Cause:
The traceback is raised on the line `self._get_document_partner().id`
 because `_get_document_partner()` can return a recordset.

### Solution:
Call `ids` instead of `id`.

### Note:
Calling `_get_document_partner()` on a recordset [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/hr_payroll/models/hr_payslip.py#L444) seems unexpected as, if only one payslip in the recordset has `self.employee_id.user_id.partner_id` evaluating to `True`, then it will return only this partner, completely ignoring the other part checking `self.employee_id.work_contact_id`.

The final code works fine as `_check_create_documents()` is called again individually [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/documents/models/ir_attachment.py#L86).

opw-5213979

Forward-Port-Of: odoo/enterprise#103749
Forward-Port-Of: odoo/enterprise#101911

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

**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

### 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

# Related

odoo/enterprise#103257

# Commit Messages

### [IMP] l10n_ph_reports: Add Book of Accounts to fulfill PH's CBA

This commit adds the "Computerized Book of Accounts" (CBA) reports to
fulfill the Computerized Accounting System (CAS) requirements mandated
by the Philippines Bureau of Internal Revenue (BIR).

This includes 4* reports:
1. General Ledger
2. General Journal
3. Sales Journal
4. Purchase Journal

*The 5th report, Inventory Report, is located in `l10n_ph_reports_stock`

The BoA report primarily supports `.pdf` and `.csv` exports to fulfill
BIR requirements. BIR requires a `.dat` format for e-submission. As
there is no prescribed format, we use the subset `.csv`. We added this
as the primary export button on the reports

All Reports:
- Supports `filter_analytic_groupby`

General Ledger (GL):
- A copy of standard GL, without "Partner" and "Currency" column

General Journal:
- Akin to GL, except it shows `account.move.line` details
- Groups `account.move.line` by `account.move` by a root line. The root
line exists to make use of the "load more" function.

Sales and Purchase Journal:
- Grouped by month, Ordered by displayed name
- Custom handling of the taxes (price_include/exclude) and manual tax
override splitting

PDF:
- forces landscape printing for simplicity
- displays custom headers in `company_information` column as BIR requires:
    - non-vat / vat
    - company phone / mobile
    - reporting period

CSV:
- Flattens any groupings into a more compact form, similar to raw data.

Technical:
- Added `res.company.l10n_ph_is_vat_registered` field for users to
control the PDF exports non-vat/vat display.

Testing:
- Every report has snapshot testing of the web view and csv export data.
- Input test data has been formulated to test key features.

task-[https://github.com/odoo-dev/enterprise/commit/45092825263b67321a135c160a70aaf6405391f5](https://odoo.com/odoo/all-tasks/4509282)
Community-odoo/odoo#232035
Co-authored-by: Nicolas Viseur <vin@odoo.com>

---

### [ADD] l10n_ph_reports_stock: Add Inventory Report to Book of Accounts to fulfill PH's CBA

CBA: Computerized Book of Accounts. Part of the requirements to fulfill
CAS (Computerized Accounting System).

This commit adds the 5th and final Book of Accounts (BoA) report:
Inventory. The report supports the custom `.csv` and `.pdf` exports like
all other BoA reports do.

Technical:
- The data is similar to /stock-report, except with only key details.
- Custom "Hide Out Of Stock" filter

Testing:
- Snapshot testing of the web view and csv export data.
- Input test data has been formulated to test key features.

task-[https://github.com/odoo-dev/enterprise/commit/45092825263b67321a135c160a70aaf6405391f5](https://odoo.com/odoo/all-tasks/4509282)
Community-odoo/odoo#232035

---

### [IMP] account_reports: support landscape printing and custom footer layout in pdf report options
- The current methods for determining when the PDF report should be
printed in landscape is insufficient and this allows custom reports to
easily force it by adding `force_landscape_printing` option in
`_custom_options_initializer()`

- It is difficult to modify the default `internal_layout` used in PDF
export. We modify `_get_layout_footer()` method to accept an optional
`options` parameter where a custom layout can be passed in via
`options['custom_display_config']['pdf_export']['internal_layout']`

- We make the `odoo.release.version` available in PDF export's
`rcontext` as it's a fairly common requirement for exported PDFs. In
particular, l10n_ph.

related task-4509282

## Reproducing steps
1. Create a DB with demo data (hr,hr_payroll,accountant modules)
2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying the account number (here is a random account IT22M8576110068R4A56E760901) and setting it as "trusted")
3. Set the bank account of the Internal Revenue Service (IRS) partner (also set it as trusted, and here is another random account: IT77H400725028682A0R202P050)
4. Create a new Off-Cycle Payslip : 
a. Payroll -> Payslips -> Payslips -> New Off-Cycle button
b. Set Mitchell Admin as the employee of the payslip
c. Change the Structure to "United States: Regular Pay"
d. Compute Sheets
5. Create payments :
a. Go to the Journal Entries linked to the payslip, and Post them
b. Go back to the payslip and 'Pay'
c. In the new wizard: Click on 'Create Payments'
6. Go back to the journal entries, a new button should've appeared on top of the page for the payments (click it now!)
7. Click on the PAY00001 (it the Federal Income Tax which is made to the Internal Revenue Service (ISR) and notice that the bank account used in payment is the bank account of the employee (should be the ISR account obviously)

## Purpose
Modifying `account.payment.register` for fixing `hr.payslip` payments generation so that each payment is assigned the correct `partner_bank_id`.

Also, fixing a SEPA payslip payment bug which says that the employee bank account is untrusted even if it isn't. 

## Tests
Adding `test_bank_account_partner_payment_payslip` test to check that the payment generated for Professional Tax is made to the correct bank account (before this fix, the selected account was always the employee bank account, whatever the vendor specified in the payment).

Adding `test_sepa_payslip_partner_bank_id` test to check that the `partner_bank_id` is set after account_register_payment wizard has been initialized and that the action_create_payments (action launched when the user clicks on "Create Payments" button of the `account_register_payment` wizard) doesn't raise any error.

This second test is not really specified in the specs, I just stumbled upon some stacktrace when coding this PR and decided to add a test to check the flow of sepa payment.

[community#235475](https://github.com/odoo/odoo/pull/235475)
[task-4979220](https://www.odoo.com/odoo/action-4043/4979220)

Forward-Port-Of: odoo/enterprise#103485
Forward-Port-Of: odoo/enterprise#99373

Currently, an error occurs when user creates an attendance with Planning as the Work Entry Source.

**Steps to Reproduce([Video](https://drive.google.com/file/d/1vGIZswZ-0D_ISAKn8LltYlGgQ7gzI6oA/view)):**
 - Install the `hr_work_entry_planning_attendance` module.
 - Go to `Employees` and create a `new employee` or open an `existing one`.
 - In the `Payroll` section, set `Work Entry Source` to `Planning`.
 - Go to `Planning` and create a planning slot for this employee `(if it does not exist)` with `Allocated Time` set to less than 100%.
 - Go to `Attendance` and create `an attendance for this employee` within the planning slot start and end dates.

**Error 1:**
`AttributeError: 'method_descriptor' object has no attribute 'min'`

**Error 2:**
`TypeError: Intervals.__init__() takes from 1 to 2 positional arguments but 4 were given`

**Cause:**
When the Work Entry Source is set to Planning and an attendance is created for that employee, the system updates overtime (if any) and retrieves the scheduled working time from the planning slot.
If the planning slot has less than 100% allocated time, it is split day by day, keeping only a portion of each day’s working hours based on the allocation percentage. While creating a datetime at the very start or end of a day, an error occurs due to incorrect access of the min or max attribute from datetime. 
Another issue occurs when creating intervals using the start and end dates: an error is raised because separate start and stop arguments are passed instead of a list of interval tuples.

**Fix:**
This commit ensures that the correct datetime.min.time() / datetime.max.time() values are used and that intervals are provided in a list-of-tuples format.

[1]- https://github.com/odoo/enterprise/blob/ee8919530ef5835d539b3ade47fa450f736b22a3/hr_work_entry_planning_attendance/models/hr_employee.py#L56-L57

[2]- https://github.com/odoo/enterprise/blob/ee8919530ef5835d539b3ade47fa450f736b22a3/hr_work_entry_planning_attendance/models/hr_employee.py#L60

**No Task ID**

Forward-Port-Of: odoo/enterprise#103662

Steps to reproduce:
-
  1. Configure a warehouse for multi-step delivery (e.g., Pick + Ship).
  2. Create a Sales Order for a product and fully process the delivery, including all steps.
  3. Create a Helpdesk ticket for that customer.
  4. From the ticket, click the "Return" button to open the wizard and select the sales order.

Issue:
-
The return wizard incorrectly defaults to the first operation in the delivery chain (e.g., the internal 'PICK' operation) instead of the final, customer-facing 'OUT' operation.

Cause:
-
Since picking is ordered by 'priority, scheduled_date asc, id desc', records are sorted by scheduled_date, this often resulted in selecting an internal 'PICK' operation instead of the final 'OUT' operation, making a more specific filter necessary.

Fix:
-
The code now explicitly filters for pickings with the type code 'outgoing' and sets it as the default delivery order.

task-4948134

Forward-Port-Of: odoo/enterprise#103883
Forward-Port-Of: odoo/enterprise#93154

**Steps to produce:**
- Install `sale_subscription,website_sale` module.
- `Subscription > Configuration > Recurring Plans`.
- `Archive` the `Monthly` plan.
- Go to website > Shop > Open product `Car Leasing (SUB)`.

**Issue:**
- Even after archiving the Monthly recurring plan, its pricing still appears on the website product page.

**Root cause:**
- At [1], when searching for a suitable recurring price, the system does not filter out pricing records belonging to archived recurring plans.
- As a result, inactive plans are still considered during pricing selection.

**Solution:**
- In this fix, we ensure that recurring plan pricing is included only if the related plan is active.
- Archived plans are now ignored, preventing them from appearing on the website.

[1]: https://github.com/odoo/enterprise/blob/25edaac85f8fd1699bb78163b01efb966e7fb680/sale_subscription/models/sale_subscription_pricing.py#L78-L79

before
<img width="340" height="184" alt="recurring_plan_before" src="https://github.com/user-attachments/assets/abac39fb-5765-4bc4-aec3-87eef7135a18" />

after
<img width="337" height="168" alt="recurring_plan_after" src="https://github.com/user-attachments/assets/35ee92e8-e66b-4612-add3-58b277560ea5" />

**opw-5266333**

Forward-Port-Of: odoo/enterprise#103473
Forward-Port-Of: odoo/enterprise#100587

**Description:**

- The [Invoices To Be Issued and Invoiced Not Delivered](https://github.com/odoo/enterprise/blob/19.0/sale_account_accountant/views/sale_order_line_views.xml#L73-L91)
ir.actions.act_window menus from the sale_account_accountant module were triggering MemoryError on databases with millions of sale.order.line records. These actions call [_search_invoice_to_be_issued and _search_deferred_revenue](https://github.com/odoo/enterprise/blob/master/sale_account_accountant/models/sale_order_line.py#L17-L29)
which iterate over all lines and access the non-stored computed fields [qty_delivered_at_date](https://github.com/odoo/odoo/blob/master/addons/sale/models/sale_order_line.py#L905) and [qty_invoiced_at_date](https://github.com/odoo/odoo/blob/master/addons/sale/models/sale_order_line.py#L985).

- On similar lines, two additional menus—[Bill To Receive and Billed Not Received](https://github.com/odoo/enterprise/blob/19.0/purchase_accountant/views/purchase_order_line_views.xml#L61-L78)
were introduced from the purchase_accountant module. These menus were also triggering MemoryError on databases with a large number of purchase.order.line records. These actions call [_search_prepaid_expense and _search_bill_to_receive](https://github.com/odoo/enterprise/blob/19.0/purchase_accountant/models/purchase_order_line.py#L17-L29) which iterate over all lines and access the non-stored computed fields [qty_invoiced_at_date](https://github.com/odoo/odoo/blob/19.0/addons/purchase/models/purchase_order_line.py#L180) and [qty_received_at_date](https://github.com/odoo/odoo/blob/19.0/addons/purchase/models/purchase_order_line.py#L234).

- To resolve this, we refined _get_accrual_domain to include only lines within a one-year range, from the given accrual date (or today) back to one year earlier, and used split_every in the accrual searches to process the recordset in chunks.

```
matu_3625797_19.0=> select count(*) from sale_order_line;
  count
---------
 2228032
(1 row)

matu_3625797_19.0=> select count(*) from purchase_order_line;
 count
--------
 581637
(1 row)
```

**Traceback1:**
```
2025-12-03 07:02:25,973 9344 ␛[1;31m␛[1;49mERROR␛[0m matu_3306966_19.0 odoo.addons.base.maintenance.migrations.base.testsodoo.upgrade.base.tests.test_mock_crawl: Adding menu ('sale_account_accountant.menu_sale_order_line_accrual_to_bill_action', 1295, 'Accounting > Review > Sales > Invoices To Be Issued', 2690) to the failing menus
Traceback (most recent call last):
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
    self.mock_action(action_vals)
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
    return self.mock_act_window(action)
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 644, in mock_view_list
    return self.mock_view_tree(model, view, fields_list, domain, group_by)
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 655, in mock_view_tree
    self.mock_web_read_group(model, view, domain, group_by, fields_list, limit_group=5)
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 713, in mock_web_read_group
    data = model.web_read_group(domain, [groupby], aggregates, limit=limit)["groups"]
  File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 397, in web_read_group
    groups, length = self._formatted_read_group_with_length(
  File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 465, in _formatted_read_group_with_length
    groups = self.formatted_read_group(
  File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 830, in formatted_read_group
    groups = self._read_group(
  File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 33, in _read_group
    return self._read_group_for_accrual(domain, groupby, aggregates, having, offset, limit, order)
  File "/home/odoo/src/enterprise/19.0/account_accountant/models/analytic_mixin.py", line 21, in _read_group_for_accrual
    return super()._read_group(domain, groupby, aggregates, having, offset, limit, order)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 1904, in _read_group
    query = self._search(domain)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5361, in _search
    domain = domain.optimize_full(self)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 445, in optimize_full
    return self._optimize(model, OptimizationLevel.FULL)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 459, in _optimize
    previous, domain = domain, domain._optimize_step(model, next_level)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 653, in _optimize_step
    children = self._flatten(child._optimize(model, level) for child in self.children)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 608, in _flatten
    for child in children:
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 653, in <genexpr>
    children = self._flatten(child._optimize(model, level) for child in self.children)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 459, in _optimize
    previous, domain = domain, domain._optimize_step(model, next_level)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 957, in _optimize_step
    domain = self._optimize_field_search_method(model)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 1016, in _optimize_field_search_method
    return Domain.OR(Domain(field.determine_domain(model, '=', v), internal=True) for v in value)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 309, in OR
    return DomainOr.apply(Domain(item) for item in items)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 595, in apply
    children = cls._flatten(items)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 608, in _flatten
    for child in children:
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 309, in <genexpr>
    return DomainOr.apply(Domain(item) for item in items)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 1016, in <genexpr>
    return Domain.OR(Domain(field.determine_domain(model, '=', v), internal=True) for v in value)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1921, in determine_domain
    return determine(self.search, records, operator, value)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
    return needle(*args)
  File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 28, in _search_invoice_to_be_issued
    ids = [line.id for line in so_lines if line.qty_invoiced_at_date < line.qty_delivered_at_date]
  File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 28, in <listcomp>
    ids = [line.id for line in so_lines if line.qty_invoiced_at_date < line.qty_delivered_at_date]
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1737, in __get__
    self.compute_value(recs)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1908, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/19.0/addons/base_automation/models/base_automation.py", line 907, in _compute_field_value
    return _compute_field_value.origin(self, field)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4949, in _compute_field_value
    determine(field.compute, self)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
    return needle(*args)
  File "/home/odoo/src/odoo/19.0/addons/sale/models/sale_order_line.py", line 989, in _compute_qty_invoiced_at_date
    line.qty_invoiced_at_date = line.qty_invoiced
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1693, in __get__
    recs._fetch_field(self)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3769, in _fetch_field
    self.fetch(fnames)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3809, in fetch
    fetched = self._fetch_query(query, fields_to_fetch)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3930, in _fetch_query
    field._insert_cache(fetched, values)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1600, in _insert_cache
    collections.deque(map(field_cache.setdefault, records._ids, values), maxlen=0)
MemoryError
```

**Traceback2:**
```
2025-12-03 07:02:30,098 9344 ␛[1;31m␛[1;49mERROR␛[0m matu_3306966_19.0 odoo.addons.base.maintenance.migrations.base.testsodoo.upgrade.base.tests.test_mock_crawl: Adding menu ('sale_account_accountant.menu_sale_order_line_accrual_deferred_revenues_action', 1296, 'Accounting > Review > Sales > Invoiced Not Delivered', 2691) to the failing menus
Traceback (most recent call last):
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
    self.mock_action(action_vals)
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
    return self.mock_act_window(action)
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 644, in mock_view_list
    return self.mock_view_tree(model, view, fields_list, domain, group_by)
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 655, in mock_view_tree
    self.mock_web_read_group(model, view, domain, group_by, fields_list, limit_group=5)
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 713, in mock_web_read_group
    data = model.web_read_group(domain, [groupby], aggregates, limit=limit)["groups"]
  File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 397, in web_read_group
    groups, length = self._formatted_read_group_with_length(
  File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 465, in _formatted_read_group_with_length
    groups = self.formatted_read_group(
  File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 830, in formatted_read_group
    groups = self._read_group(
  File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 33, in _read_group
    return self._read_group_for_accrual(domain, groupby, aggregates, having, offset, limit, order)
  File "/home/odoo/src/enterprise/19.0/account_accountant/models/analytic_mixin.py", line 21, in _read_group_for_accrual
    return super()._read_group(domain, groupby, aggregates, having, offset, limit, order)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 1904, in _read_group
    query = self._search(domain)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5361, in _search
    domain = domain.optimize_full(self)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 445, in optimize_full
    return self._optimize(model, OptimizationLevel.FULL)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 459, in _optimize
    previous, domain = domain, domain._optimize_step(model, next_level)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 653, in _optimize_step
    children = self._flatten(child._optimize(model, level) for child in self.children)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 608, in _flatten
    for child in children:
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 653, in <genexpr>
    children = self._flatten(child._optimize(model, level) for child in self.children)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 459, in _optimize
    previous, domain = domain, domain._optimize_step(model, next_level)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 957, in _optimize_step
    domain = self._optimize_field_search_method(model)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 1016, in _optimize_field_search_method
    return Domain.OR(Domain(field.determine_domain(model, '=', v), internal=True) for v in value)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 309, in OR
    return DomainOr.apply(Domain(item) for item in items)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 595, in apply
    children = cls._flatten(items)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 608, in _flatten
    for child in children:
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 309, in <genexpr>
    return DomainOr.apply(Domain(item) for item in items)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 1016, in <genexpr>
    return Domain.OR(Domain(field.determine_domain(model, '=', v), internal=True) for v in value)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1921, in determine_domain
    return determine(self.search, records, operator, value)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
    return needle(*args)
  File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 21, in _search_deferred_revenue
    ids = [line.id for line in so_lines if line.qty_invoiced_at_date > line.qty_delivered_at_date]
  File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 21, in <listcomp>
    ids = [line.id for line in so_lines if line.qty_invoiced_at_date > line.qty_delivered_at_date]
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1737, in __get__
    self.compute_value(recs)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1908, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/19.0/addons/base_automation/models/base_automation.py", line 907, in _compute_field_value
    return _compute_field_value.origin(self, field)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4949, in _compute_field_value
    determine(field.compute, self)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
    return needle(*args)
  File "/home/odoo/src/odoo/19.0/addons/sale/models/sale_order_line.py", line 989, in _compute_qty_invoiced_at_date
    line.qty_invoiced_at_date = line.qty_invoiced
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1693, in __get__
    recs._fetch_field(self)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3769, in _fetch_field
    self.fetch(fnames)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3809, in fetch
    fetched = self._fetch_query(query, fields_to_fetch)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3930, in _fetch_query
    field._insert_cache(fetched, values)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields_textual.py", line 243, in _insert_cache
    super()._insert_cache(records, values)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1600, in _insert_cache
    collections.deque(map(field_cache.setdefault, records._ids, values), maxlen=0)
MemoryError
```

- opw-5238152, opw-5269996
- upg-3306966, 3444833

### Issue:
When running the scheduled action "Payroll: Generate pdfs" for several payslips, nothing is generated and a traceback can be seen in the logs.

### Steps to reproduce:
- Disable scheduled action: "Payroll: Generate pdfs" (to avoid side effect in next step)
- Refuse all time off for "Anita Oliver" (to avoid side effect in next step)
- Create a user for the employee "Anita Oliver"
- Link the employee and the user
- Create 2 payslips
	- 1 for "Mitchell Admin"
	- 1 for "Anita Oliver"
- Compute sheet and confirm both payslips
- Run scheduled action: "Payroll: Generate pdfs"
- Nothing happens

### Cause:
The traceback is raised on the line `self._get_document_partner().id`
 because `_get_document_partner()` can return a recordset.

### Solution:
Call `ids` instead of `id`.

### Note:
Calling `_get_document_partner()` on a recordset [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/hr_payroll/models/hr_payslip.py#L444) seems unexpected as, if only one payslip in the recordset has `self.employee_id.user_id.partner_id` evaluating to `True`, then it will return only this partner, completely ignoring the other part checking `self.employee_id.work_contact_id`.

The final code works fine as `_check_create_documents()` is called again individually [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/documents/models/ir_attachment.py#L86).

opw-5213979

Forward-Port-Of: odoo/enterprise#103749
Forward-Port-Of: odoo/enterprise#101911

**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

**Current behavior:**
The `report.stock.quantity` view display incorrect quantities for products with stock moves which had their `quantity` field updated.

**Expected behavior:**
The report shouldn't add the delta quantity to data points prior to the updated stock move line date. 

**Steps to reproduce:**
Receive a different amount of product than expected after a purchase order:
- Create a purchase order for a product
- Receive higher quantity than expected by PO
- Look at the forecast view for that product
- Observe overestimated quantity in report_stock_quantity view prior to the delivery date

OR

Update quantity in a stock move line marked as 'done':
- Find a product with existing stock move lines
- Update quantity  of a stock move line with a bigger value
- Look at the forecast view for that product
- Observe overestimated quantity in report_stock_quantity view prior to stock move line date

**Cause of the issue:**
The `report_stock_quantity` view is dependent on `stock_move.product_qty` and `stock_quant.quantity`.
When quantities of stock move line related to a stock move are updated, the `stock_quant.quantity` field is also updated, while `stock_move.product_qty` is not from version 17 and up.
This difference cause erratic behaviour in the view.

**Fix:**
We could refactor the report_quantity_view and use the `stock_move.quantity` field instead of `stock_move.product_qty`, as the first one is computed as the sum of the stock move line quantities.

Task: [5003444](https://www.odoo.com/odoo/project/49/tasks/5003444)