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

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

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

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

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