**Steps to reproduce:**
* Install *sale_management*, *sale_subscription*, and *stock* modules.
* Go to *Settings* and enable *Dropshipping*.
* Create two products:
  * One *normal dropship* product.
  * One *dropship + subscription* product.
* Create a *Quotation*.
  Add both products to the order.
* Confirm the quotation.

**Observed behavior:**
* A traceback occurs during confirmation:
   File '/home/odoo/workspace/odoo19/odoo/addons/purchase_stock/models/stock_rule.py', line 159, in _run_buy
    date_planned = po.date_planned or min(v['date_planned'] for v in po_line_values)
TypeError: can't compare datetime.datetime to datetime.date

**Cause:**
* In *_run_buy*, the system computes the earliest *date_planned* using:
https://github.com/odoo/odoo/blob/4056fa8036ddad11c898cd775b7fa21ba4f8a5de/addons/purchase_stock/models/stock_rule.py#L159
* Subscription products set *date_planned* as *datetime.date*,
https://github.com/odoo/enterprise/blob/a88c64a224805d95b60a20c502428897655dba53/sale_subscription_stock/models/sale_order_line.py#L153
`current_period_start = self.order_id.last_invoice_date or
self.order_id.start_date or fields.Date.today()`
*  while normal products set *date_planned* as *datetime.datetime*.
https://github.com/odoo/odoo/blob/4056fa8036ddad11c898cd775b7fa21ba4f8a5de/addons/sale_stock/models/sale_order_line.py#L286

before min() It call  `_prepare_purchase_order_line_from_procurement`,
the value is assigned directly from `values.get('date_planned')`, and conversion
with `fields.Datetime.to_datetime()` only happens conditionally:
https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/addons/purchase_stock/models/purchase_order_line.py#L347-L351
As a result, some values remain `date` while others are `datetime`,

* When both are present in *po_line_values*, Python cannot compare the
  two types, causing the crash.

**Fix:**

So by moving the `fields.Datetime.to_datetime()` cast to the initial
assignment of `res['date_planned']`, so it is always a `datetime`
regardless of the source, and removing the now-redundant cast inside
the `if` block.

---

opw-6034079

---

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#255063

This PR addresses three edge cases in the Click & Collect and Delivery availability widget where incorrect availability states were being shown to the user.

Before this PR:
* If a product variant had a tag excluding it from Click & Collect, the logic bypassed the entire stock preparation block. This resulted in the variant falsely hiding the standard Delivery option and showing C&C as unavailable.
*  Products that are not tracked in inventory (consumables/services) were not properly displaying the availability widget with all options open (bypassing stock checks).
* If a product variant was excluded from standard delivery methods via tags, the delivery portion of the widget would still incorrectly render on the frontend.

After this PR:
* The C&C `excluded_tag_ids` check is moved further down so it only restricts the generation of `in_store_stock_data`. Standard `delivery_stock_data` is now evaluated independently.
* *Untracked products now correctly bypass standard stock checks and display all available widget options as expected.
*  Standard delivery carriers are now explicitly filtered against the product's tags (`dm.excluded_tag_ids & product_tags`). If all available delivery methods are excluded, the delivery stock data is correctly omitted, hiding the section.


opw-5990419

**Description:**
The issue is raised in this pr(v19.2) : https://github.com/odoo/odoo/pull/236971
The compute method used a [`return`](https://github.com/odoo/odoo/pull/236971/changes#diff-4e1a18a369f7dd4de264139227676dd818c06612681c88019f43d238bd8a1490R91) statement when a `if condition` was met. While this works correctly for a single record, it causes issues when multiple records are present.
**For example**, if `self` contains records like `project.project(3, 2, 4)`, and the condition **is satisfied** for the first `record (3)`, the method exits early. As a result, the remaining `records (2 and 4)` are **not** processed.
When the compute method is [triggered](https://github.com/odoo/odoo/blob/8c3043b436f8aae295f247341e3ac427fab05474/odoo/orm/fields.py#L1746) this incomplete computation leads to
missing values for some records and can result in errors.

**Solution:**
To resolve this issue, `return` has been replaced with `continue`. 
This ensures that:
Only the current record is skipped when the condition is satisfied and the loop continues processing the remaining records.

**Traceback:**
```.py

Traceback (most recent call last):
  File "/tmp/tmp2cuqrnuy/migrations/testing.py", line 483, in test_check
    self.check(value)
  File "/tmp/tmp2cuqrnuy/migrations/base/tests/test_mock_crawl.py", line 228,
 in check
    self.assertFalse(diff, msg)
AssertionError: [('project.menu_projects', 391, 'Project > Projects', 593)] is
not
false : At least one menu or view working before upgrade is not working after
upgrade.

('project.menu_projects', 391, 'Project > Projects', 593):
 Traceback (most recent call last):
   File "/tmp/tmp2cuqrnuy/migrations/base/tests/test_mock_crawl.py", line
335, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmp2cuqrnuy/migrations/base/tests/test_mock_crawl.py", line
348, in mock_action
    return self.mock_act_window(action)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/tmp/tmp2cuqrnuy/migrations/base/tests/test_mock_crawl.py", line
508, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmp2cuqrnuy/migrations/base/tests/test_mock_crawl.py",
line 541, in mock_view_form
    [data] = record.read(fields_list)
             ^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 2735, in read
    return self._read_format(fnames=fields, load=load)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 2991, in
_read_format
    vals[name] = convert(record[name], record, use_display_name)
                         ~~~~~~^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 6007, in
__getitem__
    return self._fields[key].__get__(self)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/fields.py", line 1805, in
__get__
raise ValueError(f"Compute method failed to assign {missing_recs}.{self.name}")
ValueError: Compute method failed to assign
project.project(2, 4).stat_timesheet_value
```
opw-6046808



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

Forward-Port-Of: odoo/odoo#256048

**Issue:** 
odoo/odoo#250051 consolidated multiple `width: 100%` rules into a single broad selector:

    .o_form_view .o_form_sheet .o_field_widget:not(…) { width: 100% }

This broadened scope from `.o_group/.o_inner_group` to the entire `.o_form_sheet`, which was needed for the new `o_input_box` overlay system. However, the high specificity (0,4,0) now overrides any module-specific rule with lower specificity, such as setting.scss's `width: 50%` rule (0,3,0) for `<setting>` blocks.

This broke settings panels: field widgets stretched to 100% width instead of 50%, causing overflow in layouts like the helpdesk team email alias row.

**Fix:**  
wrap the field widget portion of the selector in `:where()`.

The `:where()` CSS pseudo-class works identically to `:is()` in terms of what it matches, but always contributes zero specificity.

(ref: https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity)
(ref: https://developer.mozilla.org/en-US/docs/Web/CSS/:where)

```
Before (A=0, B=4, C=0):
    .o_form_view .o_form_sheet .o_field_widget:not(…)
    ↑(0,1,0)    ↑(0,1,0)     ↑(0,1,0)      ↑(0,1,0)

After (A=0, B=2, C=0):
    .o_form_view .o_form_sheet :where(.o_field_widget:not(…))
    ↑(0,1,0)    ↑(0,1,0)     ↑(0,0,0) ← :where zeroes this
```

The rule still matches every field widget in the form sheet, but now any component-specific override (settings, helpdesk, custom views) wins naturally without needing specificity hacks.

CSS specificity tiebreaker order:
```
    A: inline styles > B: IDs > C: classes/attrs/pseudo-classes
    Equal specificity → last rule in source order wins
```

task-6005002

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

## Issues
When adding a line in the *Recurring prices* tab (`product.pricelist.item`) of a product with a `company_id`, a "company inconsistencies" error appears.

Also, recurring plans with their *Company* field set do not appear in the list of recurring plans when adding a line in the *Recurring prices* tab.

## Steps to reproduce
1. Install *Subscription* (`sale_subscription`)
2. Create a second company
3. Create a subscription product and set a company in the *Company* field (`company_id`).
4. In the *Recurring prices* tab, add a line (any recurring plan, any price)
5. **An _Invalid Operation_ error appears: _"Uh-oh! You’ve got some company inconsistencies here"_**

For the second issue, after the same 3 first steps:
1. Create a *Recurring Plan* RP with its *Company* field set to the current company
2. On the *Recurring prices* tab of the subscription product, try to add a line with the Recurring plan RP
3. **The Recurring plan RP is missing from the list of available plans.**

## Cause
When adding a line to the *Recurring prices* tab, a new `product.pricelist.item` is created, with no `pricelist_id`. The `ProductPricelistItem._compute_company_id` from `sale_subscription` filters out the items that don't have a `pricelist_id`, which is the case for the line we create. Also, the (potentially new) plan has no `company_id` in most cases.

https://github.com/odoo/enterprise/blob/ccab0c261040ed995d12dca891caae9596bbe1eb/sale_subscription/models/product_pricelist_item.py#L18-L26

By filtering the items with no `pricelist_id`, nothing is passed to the `super()._compute_company_id`, even though it would also handle cases where the item has a `product_tmpl_id`:

https://github.com/odoo/odoo/blob/9c8112d794af1ba84ade8af124967495c2ff8995/addons/product/models/product_pricelist_item.py#L170-L173

opw-5981629
opw-6051978

Forward-Port-Of: odoo/enterprise#109403

Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs.

## Steps to replicate:
- Install Inventory
- Go to Settings and enable Multi-Step Routes > Set Warehouse Routes.
- Configure 2 steps for outgoing shipments.
- Go to Inventory and  create a new delivery with
   - **Source Location:** WH/Stock
   - **Product:**  [E-COM10] Pedal Bin with demand 1
- Mark as Todo then Archive the Pedal Bin product.
- Open that delivery in barcode app
- Pencil icon > +1 > Confirm

## Observed behavior:
TypeError: Cannot read properties of undefined (reading 'qty_available')

## Root cause:
After this [commit], an override was added to the product selector. As a result, when [2] calls the `search_read` method, it only retrieves non-archived products Consequently, if the result is an empty array, attempting to access `qty_available` causes the type error mentioned above.

## Solution:
Adding` active_test = false `to the context ensures that archived products are included in search results. This prevents empty results and avoids the error.

It also allows quantities to be added and confirmed,maintaining the same behavior as when using the increment button
followed by validation, ensuring consistency.

[commit]:
https://github.com/odoo/enterprise/commit/6aa814f59f8641d7b57af160e38b50d5bdfc8a97 
[2]-
https://github.com/odoo/enterprise/blob/e13b44b353e734a6533f7d627ed69b6e7b033ee2/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L45

opw-5980428

Forward-Port-Of: odoo/enterprise#112616
Forward-Port-Of: odoo/enterprise#109204

**Steps to reproduce:**
* Install `l10n_pe_edi`.
* Set SUNAT as the signature provider.
* Create a customer invoice.
* Select a payment term with multiple installments (e.g. 50% (15 days) / 30% (10 days) / 20% (5 days)).
* Confirm the invoice and generate the EDI standard UBL document.

**Observed behavior:**
* The XML `<cac:PaymentTerms>` instalment nodes (Cuota001, Cuota002, etc.) are ordered according to the database insertion order of the receivable lines.
* If the payment term lines are created in a non-chronological order, the installments in the XML mix up the `Cuota` ID, amount, and `PaymentDueDate`.

**Cause:**
* `_add_invoice_payment_terms_nodes` iterates over `invoice.line_ids` to generate the installments, but does not sort the receivable account lines by their `date_maturity`.

**Fix:**
* Explicitly call `.sorted('date_maturity')` on the receivable lines before generating the `invoice_date_due_vals_list`.

opw-6035589

Forward-Port-Of: odoo/enterprise#112698
Forward-Port-Of: odoo/enterprise#112162

When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly

### Steps to reproduce:

* In the settings enable packagings
* Create a storable product P with Units as uom, a barcode and tracked by lots
* Create new lots with barcode for Product P
* Inventory > Configuration > Product > Units & Packagings
* Click on pack of 6 > Packaging Barcodes > New
* Create one for your product with a different barcode
* Go to barcode > Operations > eg. internal transfer > New
* Scan packaging barcode
* Scan one of the lots
-> Issue, the lot create a new line, and will not find the packaging

### Observation:

When scanning a barcode, it will first try to find a match with existing lines,
In our case, it will find a match with the line of the packaging, but since the line is considered as "completed" since there was no expected quantity since we create a new picking:
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_picking_model.js#L1497-L1501
It will erase the line, to avoid to overfill a completed line:
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1459-L1460
and since, it decided to ignore that line, it will not find another lines, and will create a new one :
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1535

Additional Issues
-----------------
Issue 1 : When scaning a packaging, lot1, packaging, lot2, all the packagings will be linked to the first lot, which doesn't allow us to scan multiple lots.
Issue 2 :  When having sublines with different uoms, it will add the quantity without considering the differences in uoms

### Steps to reproduce:

* In the settings enable packagings
* Create a storable product P with Units as uom, a barcode and tracked by lots
* Create new lots with barcode for Product P
* Inventory > Configuration > Product > Units & Packagings
* Click on pack of 6 > Packaging Barcodes > New
* Create one for your product with a different barcode
* Create a packaging 2 with barcode for product A
* Go to barcode > Operations > eg. internal transfer > New
* Scan packaging 1 barcode
* Scan one of the lot 1
* Scan packaging 1
* Scan lot 2
-> Issue 1, the packaging 2 will be link to lot 1, it won't be possible to link any packaging to another lot.
* Scan packaging 2
-> Issue 2, it create a subline (excpeted), but the sum that appear on the main grouped line is wrong, it doesn't considere the difference in uoms

### Observation:
Issue one :
When scanning a barcode, it will first try to find a match with existing lines, since the uom is the same it will not be erased by the full line check
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1456-L1460
and since, it found a line, it will just add it's self to the line

Issue Two:
When creating the group lines it will first calculate the sum of all the quantities:
https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_model.js#L248-L254
And after inside of groupSublines it will choose the main line and it's uom and use the previous sum for the total quantity:
https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_picking_model.js#L1456-L1461

opw-5189492
opw-5408372

Forward-Port-Of: odoo/enterprise#110847
Forward-Port-Of: odoo/enterprise#98701