### Description of the issue/feature this PR addresses:

The workcenter planning logic in _get_first_available_slot can become inefficient when searching for very short available slots. The method repeatedly builds small candidate time windows and checks them against existing workorder and leave intervals, potentially iterating many times before finding a free slot.

This leads to unnecessary computational overhead in scenarios where a large number of busy intervals exist and the remaining duration to schedule is small.

### Current behavior before PR:

The planner checks for conflicts by computing the intersection between the candidate window and the busy intervals. When a conflict is detected, the candidate window is shifted forward (or backward) to the end (or start) of the intersection, and the process is repeated until a free slot is found.

This approach requires repeatedly performing full interval merge operations, which becomes disproportionately expensive when the candidate windows are very small and the loop iterates many times.

### Desired behavior after PR is merged:

The planner uses a new Intervals.conflicting() helper to retrieve the entire busy interval that overlaps with the candidate window. Instead of advancing only to the end of the intersection slice, the planner can jump directly to the end (or start) of the full busy interval.

This avoids repeated full-merge work, reduces the number of iterations needed to find a valid slot, and prevents pathological performance slowdowns in short-duration planning scenarios.

### Benchmarks

Profiling _get_first_available_slot with different workorder durations. Database has multiple months that are fully booked. Speedup is more dramatic with shorter durations but there is at minimum minor improvements across the board.

| Work Order Duration | Before | After |
| --- |---|---|
| 1sec | ~2.5min | <1sec |  
| 1min | ~2sec | <1sec |

### References

opw-5437256


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

Forward-Port-Of: odoo/odoo#284278
Forward-Port-Of: odoo/odoo#246015

**Steps to Reproduce:**
- Install the Time Off app and Belgian Payroll (l10n_be_hr_payroll).
- Create and validate an accrual allocation for currently logged-in user with: No end date Any start date An accrual plan configured with a carry-over milestone Any Time Off Type
- Create another allocation for the same employee, using the same accrual plan and same Time Off Type, but with a different start date that is not in the future.
- Select the accrual plan. The error is raised immediately during the onchange.

**Issue:**
- When the accrual allocation onchange computes the accrued balance, a temporary allocation is used internally to simulate the accrual computation.
- This temporary record is discarded after the computation.
- The discarded temporary record can remain pending for computed field recomputation.
- When the onchange later triggers recomputation, the stale temporary NewId can cause: `KeyError: <NewId origin=18>`

**Root Cause:**
- Temporary allocations created with 'new(origin=allocation)' can add computed fields to `env.transaction.tocompute`.
- `invalidate_recordset()` clears the temporary record's cache but does not remove the `NewId` from the pending recomputation queue.
- Since the temporary record has no database row to recompute from, the NewId can later be picked up during recomputation.
- This can lead to a KeyError when the framework tries to access cached data for the discarded temporary record.

**Solution:**
- Properly discard temporary allocations after the accrual simulation.
- In addition to invalidating the cache, remove the temporary NewId from `env.transaction.tocompute` using `remove_to_compute()`.
- Use this cleanup for temporary allocations created with `new(origin=...)`.

**Result**
- Prevents the KeyError during accrual allocation onchange.
- Allows users to create another allocation with the same accrual plan without triggering the RPC error.

**opw-6390559**

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

### Issue before this commit:
When a CFDI invoice was sent through a mass action (Send & Print executed by OdooBot), the unit of measure in the generated CFDI appeared in English instead of the configured language (e.g. Spanish.

### Steps to reproduce the issue:
1.Download Accounting, Contacts and l10n_mx
2. Switch to Spanish (MX) language
3. Set the language of "Inmoviliaria CVA" and "XENON INDUSTRIAL ARTICLES" to Spanish (MX)
4. In contacts select Archived in filters and switch OdooBot language to Spanish (MX)
5. Create and confirm two invoices in the database, one for each customer but don't send these invoices
6. Go to the list view and select these two invoices, and click on "Send and print" and select CFDI
7. Check any of the XML files generated in any of the invoices (in the CFDI tab of the invoice)
8. See that the UoM in the XML file, will be set in english rather than Spanish (MX)

### Cause of the issue:
The context under which the batch action runs does not contain the lang key. As a result, translated fields (such as product_uom_id.name) were read in the source language (English) instead of the executing user's language, because nothing in the CFDI generation chain explicitly forced the correct lang into the context.

### Reason to introduce the fix:
A CFDI must always report translated fields in the correct language. The fix ensures the invoice is read with the executing user's language when the context doesn't already specify one, so translated fields are consistently correct across both flows.

opw-6399860

Forward-Port-Of: odoo/enterprise#129769
Forward-Port-Of: odoo/enterprise#125698

Steps to reproduce:
- Argentinean company, Responsable Inscripto (l10n_ar_pos installed)
- A posted customer invoice with VAT, partially paid
- In the PoS, pick the customer, "Settle invoices", select that invoice, pay the balance by bank transfer and validate

Issue:
Validation fails with "There should be a single tax from the "VAT" tax group per line, but this is not the case for line ..." and the settlement cannot be recorded at all. The invoice being settled is correct; the rejected line belongs to a second invoice the PoS creates for the settlement itself.

Cause:
`setToInvoice` already refuses to invoice a settlement, but its condition, `is_settling_account and no line`, only describes a deposit: the deposit line is added at validation. When settling a due or an invoice, `is_settling_account` stays false and the order does carry lines - the settle lines - so the guard never fires. l10n_ar_pos then sets `to_invoice` on mount, as a sale must generate an electronic document in AR, and the settle line, untaxed on purpose since it pays an existing document rather than selling anything, reaches `_check_argentinean_invoice_taxes`.

Fix:
Refuse the flag as well when every line is a settle line. Such an order generates an empty document - all its lines, the receivable one included, have a zero balance - so it records nothing and only consumes a document number, which in AR means an AFIP number for a zero-amount invoice. An order that also sells something keeps its invoice, since the sale still has to be reported. Reconciliation is unaffected: it happens in `_reconcile_account_move_lines` at session close, and is already covered for both invoiced and non-invoiced settlement orders.

opw-6464675

Forward-Port-Of: odoo/enterprise#128975

**Description of the issue/feature this PR addresses:**

When importing a SODA XML file, users without the Analytic Accounting
group encounter an access rights error even if Analytic Accounting is not
enabled.

This occurs because the import wizard reads the `analytic_account_id` field
on the `soda.analytic.mapping` model to build an internal dictionary of
departments. Because this field is restricted to the Analytic Accounting
group, the evaluation of this field crashes the import for users even when
the Analytic Accounting feature is disabled.

This commit resolves the issue by using `.sudo()` on the analytic mapping
recordset to bypass the field-level group restriction.

**Steps to reproduce:**

- Log in as Mitchell Admin, change company to “My Belgian Company”
- Settings > Users & Companies > Users > Mitchell Admin > Access Rights > Extra Rights > ensure “Analytic Accounting” is unchecked
   - Also ensure Mitchell Admin is not part of the “Analytic Accounting” group
- Accounting Dashboard > remove “Favorites” from filter > drag & drop a SODA XML file to “Miscellaneous Operations” > save > observe Access Error


**Current behavior before PR:**

- Users who don't belong to the Analytic Accounting group encounter an access error when attempting to import SODA XML files, even when the Analytic Accounting feature isn't enabled

**Desired behavior after PR is merged:**

- Those users no longer receive an access error

opw-6376039

Forward-Port-Of: odoo/enterprise#127867

Steps to reproduce:
- Create a pricelist with a rule applied on a product category and make it available in the PoS
- Open a PoS session
- From the backend, create a product in a new category covered by such a rule
- Back in the PoS, find that product through Search > Search more and add it to the order

Issue:
The product is priced at its sale price, the pricelist rule set on its category is ignored.

Cause:
A product that is not part of the initial payload is loaded on the fly by load_product_from_pos, which sends back the rules returned by get_pos_ui_product_pricelist_item_by_product. That domain only matches the rules set on the template or on the variant, never the ones set on a product category, and the payload carries no product.category record either. The client therefore has neither the rule nor the category: parentCategories walks categ_id, which resolves to nothing, so getCategoryRulesIds returns no rule and getPrice falls back to the sale price.

This stayed unnoticed because product.category is fully loaded when the session starts, along with every category rule, so only the categories created after the session was opened are missing.

Fix:
Send the categories of the loaded products, since a rule set on a parent category applies to its children - along with the products, and match the rules set on those categories in get_pos_ui_product_pricelist_item_by_product.

The initial loading domain of product.pricelist.item no longer filters the category rules on the loaded categories: such a rule has to be loaded whatever the products sent to the client are, since a product of that category may be loaded later on.

opw-6477745

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

Forward-Port-Of: odoo/odoo#285411
Forward-Port-Of: odoo/odoo#284660

**Problem:**
Deleting one task of a recurrence suite ends the recurrence, but the tasks that stay behind keep the "Recurrent" option ticked. They look recurrent while no recurrence exists any more, so closing one of them never produces the next occurrence.

**Steps to reproduce:**
1. Create a project with "Recurring Tasks" enabled
2. Create a task, tick "Recurrent" and mark it as done
3. Repeat on each generated occurrence until 3 or 4 tasks exist
4. Delete the last generated task
5. Open one of the tasks left in the suite

**Current behavior:**
The remaining tasks still show "Recurrent" ticked, but marking one as done creates no new occurrence and the recurring tasks smart button is empty.

**Expected behavior:**
Ending the recurrence should turn the "Recurrent" option off on every task that was part of it.

**Cause of the issue:**
`unlink` deletes the `project.task.recurrence` when the last task of the suite is removed, and `recurrence_id` is set to NULL on the other tasks by the database. Nothing resets their `recurring_task` boolean, so it stays `True` with no recurrence behind it. The two other places that end a recurrence, `write` and `action_unlink_recurrence`, already clear the flag on the whole suite.

**Fix:**
Aligning `unlink` with those two paths keeps a single meaning for `recurring_task`: it is only ticked while a recurrence actually exists. The suite has to be read before the recurrence is deleted, since the one2many is empty afterwards, and the tasks of the batch being deleted are left out so that no write lands on records that are about to disappear.

opw-6425292

Forward-Port-Of: odoo/odoo#282535

Issue
-----
When adding all of the catalog's suggestions at once, the uom specified on the product's vendor lines is not respected.

Steps to reproduce
-----
- Create a product
	- Add a vendor line in a different uom
- Create a past outgoing shipment of 100 of the product
- Create a PO (same vendor as vendor line)
	- Open the Catalog
	- Click "Add All" in the suggestion section on the left
- Go back to the PO

> The product is in units instead of the different uom

Cause
-----
Clicking the button calls `action_purchase_order_suggest` in Python directly

https://github.com/odoo/odoo/blob/3aec1c317aad547b1ad0c85a21cc53f735c5cbfd/addons/purchase_stock/models/purchase_order.py#L131-L134

whereas clicking on a product will go through `addProduct` in JS

https://github.com/odoo/odoo/blob/3aec1c317aad547b1ad0c85a21cc53f735c5cbfd/addons/purchase_stock/static/src/product_catalog/record/kanban_record.js#L20-L28

Which leads to `_update_order_line_info` where the purchase line is created

https://github.com/odoo/odoo/blob/f59783d43f891fea14d03f67d7c017d7ffbbe5a7/addons/purchase/models/purchase_order.py#L1322-L1328

The uom is then retrieved in the create call through `_suggest_quantity`

https://github.com/odoo/odoo/blob/f59783d43f891fea14d03f67d7c017d7ffbbe5a7/addons/purchase/models/purchase_order_line.py#L547-L549

Other issue
-----
The quantity of the product also doesn't match the suggestion since the product `suggested_qty` is in the product's uom and not the vendor ones.

-----
Ticket:
opw-6417665

Forward-Port-Of: odoo/odoo#280934

### Steps to reproduce:
- Create two employees: Employee A (Manager) and Employee B (Employee subordinate to A)
- Create a user for Employee A and grant Time Off approval rights, but no Payroll access
- Create a payslip for Employee B for the current month
- Validate and mark the payslip as Paid
- Log in as Employee B and submit a Time Off request for the current month
- Log in as Employee A and open Employee B's Time Off request to approve it
> AccessError: You do not have enough rights to access the field "payslip_state" on Time Off
(hr.leave). Please contact your system administrator.

### Cause of Issue:
When a leave overlaps with a validated payslip and no waiting payslip is found, the `hr_payroll` override of `_action_validate()` attempts to set the leave's `payslip_state` to `blocked`. However, the `payslip_state` field is restricted to users with Payroll access (`hr_payroll.group_hr_payroll_user`). Because the manager approving the leave only has Time Off approval rights, the write operation fails with an access rights error.

### Fix:
Use `sudo()` to bypass the AccessError, since it's the common approach in this module

opw-6501386

**Steps to reproduce:**
1. Install Payroll and Time Off modules on v19.2.
2. Create a public holiday via the form view (Time Off -> Configuration -> Public Holidays). Do not enter a work entry type and save.
3. Open Payroll and try to create a payslip for any employee in the same month as the public holiday you will face below traceback.

**Issue:**
The `work_entry_type_id` is required for payroll calculations. If it is null the `_round_days` calculation evaluates an empty recordset, producing a [ValueError](https://github.com/odoo/enterprise/blob/39095789c2b6a7e558d11f479a249871b3b800b6/hr_payroll/models/hr_payslip.py#L1021
). 
While in this [PR](https://github.com/odoo/odoo/pull/254666/changes) made this field was made required in the
list view, it was missed in the form view. This allows users to save a holiday without a work entry type, crashing payslip generation later.

**Solution:**
Make the `work_entry_type_id` field required in the form view as well to prevent the creation of inconsistent public holiday records.

**Traceback:**
```.py

  File "/home/odoo/src/enterprise/saas-19.2/hr_payroll/models/hr_payslip.py",
line 1021, in _round_days
    day_rounded = float_round(days, precision_rounding=precision_rounding,
rounding_method=work_entry_type.round_days_type)
  File "/home/odoo/src/odoo/saas-19.2/odoo/tools/float_utils.py", line 152, in
float_round
    raise ValueError(msg)
ValueError: unknown rounding method: False
```

opw-6477587

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

**Steps to reproduce:**
- Install the `l10n_se` module and switch to a SE Company.
- Navigate to Invoicing > Configuration > Taxes.
- Create a tax and set the tax grid to `se_42`.
- Create and confirm an invoice for a Swedish customer using this tax.
- Navigate to Reporting > Tax Report.
- Check the amount of `Fält 42` under `Block E`.

**Observation:**
The `Fält 42 – Övrig försäljning m.m.` field shows the amount as negative 
instead of positive.

**Root Cause:**
At [1], the `se_42` formula is missing the negative sign.

These lines were missed by the `tax_tag_invert` revamp done in https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b.

**Fix:**
This commit adds the missing negative sign to the `se_42` formula, 
ensuring that the amount for `Fält 42` is displayed as positive in the 
Swedish tax report, similar to [2].

[1]:
https://github.com/odoo/odoo/blob/a56038c97e807388772ccc3a794cf0bf658a2076/addons/l10n_se/data/account_tax_report_data.xml#L356-L368

[2]:
https://github.com/odoo/odoo/commit/b8125f38e80c1977eedda5fc6b9466ece5e9fd89

opw-6457529

Forward-Port-Of: odoo/odoo#281925

When printing an invoice, a traceback will occur if the company's partner has an invalid CUIT.

Steps to reproduce the error:
- Install ``l10n_ar_edi`` module with demo data
- Switch to ``(AR) Exento`` Company
- Go to Invoicing > Configuration > Journals > Open ``Ventas Preimpreso`` journal >
  ARCA POS System: ``Electronic Invoice - Web Service`` > Save
- Create a new invoice with ``ADHOC SA`` partner > Confirm the invoice
- Open the ``(AR) Exento`` partner and set the VAT to ``BE0477472701``
- Open the Invoice > print

Traceback:
```py
ValueError: invalid literal for int() with base 10: 'BE0477472701'
```

After this [commit], companies outside the EU can use European VAT numbers.
Consequently, an Argentine partner can have a CUIT number such as ``BE0477472701``,
which is valid as a Belgian VAT number but not as a CUIT.
When printing the invoice, the ``l10n_ar_vat`` field is computed
from the partner's VAT and its value is passed to ``int()``,
causing a traceback at the following line:
https://github.com/odoo/enterprise/blob/d55486866d09f8aa87c2003dab722cfa323068b4/l10n_ar_edi/models/account_move.py#L138

[commit]: https://github.com/odoo/odoo/commit/a2afe3292e1cd0a4f339dc47707e469653d13ea0

Enterprise PR: https://github.com/odoo/enterprise/pull/127820

sentry-7666042143

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

Forward-Port-Of: odoo/odoo#284880
Forward-Port-Of: odoo/odoo#282454

Currently, an error occurs when trying to fill in the company details from the General Ledger.

Steps to Reproduce:
 - Install `l10n_ae_faf` with demo data.
 - Switch to the `AE Company`.
 - Go to `Accounting` > `Reporting` > `Ledgers` > `General Ledger`.
 - Click on `your company` in the company details warning.

`AttributeError: The method 'account.report.action_fill_company_details' does not exist`

In this commit, the company details warning was added to the l10n_ae_faf module, similar to account_saft. 
However, the action_fill_company_details method is only defined in account_saft, which is not a 
dependency of l10n_ae_faf. Therefore, when the user clicks on "your company" to open the company 
form [1], the method is not available and an error is raised.

This commit ensures that action_fill_company_details is added to l10n_ae_faf so that clicking on 
`your company` opens the company form, as it does in account_saft.

[this commit]: https://github.com/odoo/enterprise/commit/dffc4412df42507457810a0895be3b8f4dc7ec3f

[1]- https://github.com/odoo/enterprise/blob/c8c2f13b7fd17e215044fc62774f2b4a378aaf8c/l10n_ae_faf/static/src/components/general_ledger/filters/warnings.xml#L3-L10

sentry-7676719103

Forward-Port-Of: odoo/enterprise#128327

The "Import File" button on the dashboard card only shows up for bank
journals. Credit card journals are treated the same way as bank journals
pretty much everywhere else: the dashboard card itself, the statements list,
the "Transaction Feeds" setting on the journal form (where you can pick the
file import option), and even `create_document_from_attachment` in this
module, which already accepts them. So you end up with a credit card journal
set to import files but nothing on its card to actually do it, and people
assume the feature is simply not there.

Show the button on credit card journals too.

Steps to reproduce:
- Install account_bank_statement_import_csv (or any other import format)
- Create a "Credit Card" journal and set its Transaction Feeds to the file import option
- Go to the Accounting dashboard
- The bank journal card has an "Import File" button, the credit card one doesn't

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

Forward-Port-Of: odoo/enterprise#129546

When printing an invoice, a traceback will occur if the company's partner has an invalid CUIT.

Steps to reproduce the error:
- Install ``l10n_ar_edi`` module with demo data
- Switch to ``(AR) Exento`` Company
- Go to Invoicing > Configuration > Journals > Open ``Ventas Preimpreso`` journal >
  ARCA POS System: ``Electronic Invoice - Web Service`` > Save
- Create a new invoice with ``ADHOC SA`` partner > Confirm the invoice
- Open the ``(AR) Exento`` partner and set the VAT to ``BE0477472701``
- Open the Invoice > print

Traceback:
```py
ValueError: invalid literal for int() with base 10: 'BE0477472701'
```

The issue occurs because when the partner's identification type is CUIT,
At [1] ``_run_check_identification()`` method does not include partners whose identification type has ``is_vat=True``.
As a result, CUIT is not validated by ``_run_check_identification()`` method in ``l10n_ar`` module at [2].
So, partner's ``l10n_ar_vat`` field can be computed as ``BE0477472701``.
Passing this value to ``int()`` raises the traceback during invoice printing at below line.
https://github.com/odoo/enterprise/blob/d55486866d09f8aa87c2003dab722cfa323068b4/l10n_ar_edi/models/account_move.py#L138

[1]:https://github.com/odoo/odoo/blob/c2a39085ba0fbcf8a0e6a55228191e764499caea/addons/l10n_latam_base/models/res_partner.py#L24-L30

[2]:https://github.com/odoo/odoo/blob/c2a39085ba0fbcf8a0e6a55228191e764499caea/addons/l10n_ar/models/res_partner.py#L55-L65

Community PR: https://github.com/odoo/odoo/pull/282454

sentry-7666042143

Forward-Port-Of: odoo/enterprise#129449
Forward-Port-Of: odoo/enterprise#127820

Steps to reproduce:
-------------------
1. Install planning with demo data
2. Create a shift with a resource spanning multiple days
3. Remove default filters and group by role
4. Click on Actions > Print

Issue:
-------
```python
  File "/home/odoo/odoo/enterprise/planning/models/planning_slot.py", line 2029, in action_print_plannings
    "start_datetime": print_planning_get_fake_pill_start_datetime(start_datetime_per_resource_per_day, resource.id, current_day + timedelta(days=1), tz_info),
                                                                                                       ^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'id'
```

Cause:
------------
After this fbf8b2a, the resource is only assigned when grouping by **resource_ids**;
otherwise, it is set to False. https://github.com/odoo/enterprise/blob/0e93fd1177743a4af0f9af153a46ee38b96e9e95/planning/models/planning_slot.py#L1998

When grouping by anything other than 'resource_ids' (e.g. role), `resource` became `False`.
As a result, accessing `resource.id` raised the above traceback.
https://github.com/odoo/enterprise/blob/0e93fd1177743a4af0f9af153a46ee38b96e9e95/planning/models/planning_slot.py#L2029-L2030

Solution:
------------
Fall back to `slot.resource_ids` instead of `False`, and loop over each resource individually.
This correctly handles multi-resource slots regardless of the active group-by, and gives
each resource its own pills with accurate start/end datetimes derived from its individual work schedule.

opw-6203688