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 reproduce**
On a local DB, with demo data:
- Change your machine's time to a late part of the day (e.g. 6pm)
- Install `mrp_workorder`
- Set the "Standard 40 hours/week" (used by a workcenter) as flexible.
- From the Shop Floor, start the "WH/MO/00003 - Manual Assembly"
workorder.

"Validation Error: The start date of the time off must be earlier than
the end date."

**Cause**
`_calculate_date_finished` in mrp is calling `plan_hours` and under
certain conditions with a flexible resource, it is possible for
`plan_hours` to return a datetime before the `day_dt` parameter.
This happens because for flexible resources,
`_attendance_intervals_batch` can return attendance intervals with
start or end datetimes outside of the start_dt -> end_dt window.
For example, a flexible calendar with 8h/day will return the
8:00->16:00 interval, even if start_dt is later than 8:00.

**Change**
Don't return attendance intervals outside of the [start_dt, end_dt]
interval by shifting them if necessary.

opw-5123230

Forward-Port-Of: odoo/odoo#243101
Forward-Port-Of: odoo/odoo#233169

[FIX] website_sale, adding website_id in portal controller

Version: 17.0+e

Steps to reproduce
------------------
The database has two different websites.

A payment provider is enabled for just one of them (website1).

When a sale order is created on the sales app and the customer accesses it in its portal on the website2, he is able to pay with the payment provider which is only enabled on website1.

The problem also occurs when previewing the customer’s portal view.

Why it's happening
------------------
When accessing an order via “/my/orders/<int:order\_id>”, the portal_order_page method calls _get_compatible_providers without passing the website_id. The overriding logic in website_payment then defaults to considering all activated payment methods as compatible, regardless of website restrictions.

As no website_id is provided, the overriding method from the payment_provider extension in website_payment module considers every activated payment methods as compatible.

The Fix
-------
We now add the current website's id to the method if none has been added before.


opw-5172444, “Payment provider visible on sales order portal"


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

Forward-Port-Of: odoo/odoo#242955
Forward-Port-Of: odoo/odoo#235954

Steps to reproduce:
- With a PE Company setup
- Create an Invoice with "Document Type" set to "(01) Factura"
- Set a discount on the invoice line
- Confirm and send for validation
- Create the credit note
- Confirm the credit note and send for validation

Issue:

Credit note validation will fail with error
`3271|El valor de venta por ítem difiere de los importes consignados. -
Detalle: xxx.xxx.xxx value='ticket: 1767185167086 error: Error en la
linea: 1: 3271 (nodo: "cac:CreditNoteLine/cbc:LineExtensionAmount"
valor: "600.00")'`

This occurs because while UBL standard allows AllowanceCharge in credit
notes, SUNAT does not.
Credit notes are treated as pure amount adjustments, not price recalculations.
Discounts were already applied in the invoice, so SUNAT ignores
AllowanceCharge in CN, causing error 3271.

With this commit we introduce a check to ensure users won't post edi credit
or debit notes containing line discounts

opw-5414766

Forward-Port-Of: odoo/enterprise#103106

**Issue:**
Payslips show blank worked days for employees with contracts without a `resource_calendar_id` (fully flexible, despite having valid work entries

**Cause:**
`_get_worked_day_lines()`  skips worked day computation if the contract has no calendar

https://github.com/odoo/enterprise/blob/1a10e0444fdb71a072262a1f14f0bfc766d109c6/hr_payroll/models/hr_payslip.py#L665-L674

**Steps to Reproduce:**
- Assign an employee a fully flexible contract with attendance as work entry source.
- Create work entries based on the attendance records of the employee record
- Go to employees > contracts > new Payslip Worked Days section is empty, even though attendance shifts are showing up on top.

**Fix:**
removing the calendar requirement in the main method and adding a fallback calendar in the called utility method

**Note:** same issue happens if work entry source of the contract is Planning

opw-4931972

Forward-Port-Of: odoo/enterprise#98941
Forward-Port-Of: odoo/enterprise#93935

Before this commit:
-------------------------
- In the product form view, when creating new packaging, a pop-up form opens to
  Create a new Unit of Measure (UoM), and if the user tries to assign a barcode
  Within that form, a second pop-up opens instead of assigning the barcode
  directly.
- In the second pop-up, if the user creates the same UoM again, it causes data
  duplication; the same UoM gets created in 'Units and  Packagings' with a
  default quantity of 1 without reference unit. This incorrect behavior leads to
  confusion when selecting the UoM later.

Steps to reproduce:
-------------------------
1. Install the 'sale_stock' module.
2. Enable Units of Measure & Packagings in stock.
3. Create or open any product.
4. Go to the Sales tab.
5. Create new packaging (e.g., Pack of 5), set the quantity and reference unit,
   and try to create a barcode.
6. A second pop-up form opens to again create a new UoM and assign the barcode.
7. It causes data duplication; the same UoM gets created in 'Units and
   Packagings' with a default quantity of 1 without reference unit.

Cause of the issue
-------------------------
When assigning a new barcode to a UoM, the field could not fetch the
corresponding UoM(In uom.uom) record because it did not yet exist in the
database. As a result, the system opened another pop-up to create the same
UoM(In product.uom) again and assign a barcode to it.

After this commit:
-----------------------
- The barcode field is hidden until the UoM is created.
- Once the packaging is saved, users can edit it to assign a barcode to the
  specific UoM of the product.
- This improves the flow by preventing duplicate UoM creation and ensuring a
  clear, single-step process for assigning barcodes to product packaging.

Task ID:5023229

Forward-Port-Of: odoo/odoo#230474

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

Forward-Port-Of: odoo/enterprise#101677