**Description:**

In previous versions, a single move could have multiple payments linked to it, and that move could also be linked to multiple
expenses. When opening expenses from the payment action, which caused a singleton error when multiple expenses were linked.

This situation can occur during upgrades because older versions https://github.com/odoo/upgrade/pull/9685/changes here is identified allowed creating such records. However, after the removal of expense reports [^1], this type of record can no longer be created in newer versions.

**To fix the issue**

the code now handles multiple expenses instead of assuming a singleton.

```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2283, in _serve_db
    return service_model.retrying(serve_func, env=self.env)
  File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 185, in retrying
    result = func()
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2338, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2553, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_http.py", line 355, in _dispatch
    result = endpoint(**request.params)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 794, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/src/odoo/19.0/addons/web/controllers/dataset.py", line 38, in call_button
    action = call_kw(request.env[model], method, args, kwargs)
  File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 94, in call_kw
    result = method(recs, *args, **kwargs)
  File "/home/odoo/src/odoo/19.0/addons/hr_expense/models/account_payment.py", line 37, in action_open_expense
    'name': self.expense_ids.name,
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1659, in __get__
    record.ensure_one()
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5940, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: hr.expense(22, 21)
```

opw-5494047
upg-3974547

[^1]: https://github.com/odoo/odoo/pull/189701

Forward-Port-Of: odoo/odoo#254167

Step to reproduce:
- setup Restaurant and do the following config
- set "self-ordering" -> "Qr Menu + Ordering"
- set "service At" -> "pickup zone"
- save and print the qr-code ( option is right there below these configs)

Observation:
- in downloaded pdf, we see a wrong url, which includes table_id, which shouldn't be.
- QRs do not have table_id

Cause:
- there is issue in `generate_qr_codes_page` method, which uses table_id even if ordering mode is "pickup zone"

Fix:
- we only use table_id when ordering_mode = 'table'.

**Before:** 
<img width="1002" height="397" alt="image" src="https://github.com/user-attachments/assets/e6dc50e5-6384-45b8-8ee5-817526769dc2" />


**After**
<img width="1021" height="405" alt="image" src="https://github.com/user-attachments/assets/0be9b902-3870-4fc7-a409-e01265b7a1b3" />


opw-5095607


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

Forward-Port-Of: odoo/odoo#251759
Forward-Port-Of: odoo/odoo#247184

Steps to reproduce:
------------------------------
1. Install Subscription module
2. Create a new subscription and confirm it
3. Create an invoice from the subscription.
  * Register a payment and ensure the invoice is in the Paid state.
4. Go back to the subscription and close it with any reason
5. Open the related invoice.
  * Create and Confirm Credit Note.
  * Register a payment for the credit note.
6. Go back to subscription

Observation:
------------------------------
The subscription is automatically set back to `In Progress` even  though it was previously churned.

Issue:
------------------------------
The method `_reopen_paid_churned_subscription` reopens churned subscriptions when an invoice is set to `in_payment` or `paid`. There was no check to exclude refund moves (`move_type = 'out_refund'`), causing the subscription to be reopened when a credit note is paid.

Solution:
------------------------------
Add a condition to exclude refund invoices from the reopening logic

opw-5947999

Forward-Port-Of: odoo/enterprise#108487

- Some lots were found to contain very large delivery sets (7k+ picking IDs) with multiple parents.
- Updating parent sets in a single operation caused a MemoryError for large datasets.

```sql

Traceback (most recent call last):
   File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
    return self.mock_act_window(action)
   File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 539, in mock_view_form
    [data] = record.read(fields_list)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3858, in read
    return self._read_format(fnames=fields, load=load)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4089, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7078, in __getitem__
    return self._fields[key].__get__(self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1311, in __get__
    self.compute_value(recs)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1493, in compute_value
    records._compute_field_value(self)
   File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 442, in _compute_field_value
    return super()._compute_field_value(field)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5297, in _compute_field_value
    fields.determine(field.compute, self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
    return needle(*args)
   File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_lot.py", line 149, in _compute_delivery_ids
    delivery_ids_by_lot = self._find_delivery_ids_by_lot_iterative()
   File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_lot.py", line 385, in _find_delivery_ids_by_lot_iterative
    delivery_by_lot[parent_id].update(delivery_by_lot[lot_id])
 MemoryError

(Pdb)len(all_lot_ids)
22166
(Pdb)len(barren_lines)
9682
(Pdb)len(lots_to_propagate)
9682

Lot_id 11412: delivery_by_lot size = 7420, parents = 3

Lot_id 11753: delivery_by_lot size = 0, parents = 7

Lot_id 12845: delivery_by_lot size = 11, parents = 5

Lot_id 14646: delivery_by_lot size = 12, parents = 2

Lot_id 15801: delivery_by_lot size = 1700, parents = 3

Lot_id 19817: delivery_by_lot size = 0, parents = 4

Lot_id 22370: delivery_by_lot size = 0, parents = 1

Lot_id 25072: delivery_by_lot size = 6827, parents = 2

Lot_id 25134: delivery_by_lot size = 3, parents = 2

Lot_id 25135: delivery_by_lot size = 1, parents = 2
```
- Previous fix adds all child deliveries, even if some already exist, but this new patch adds only the missing ones

UPG - 3869661
OPW - 5900313

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

Forward-Port-Of: odoo/odoo#248826

**PROBLEM**
Here is the client use case:
The client uses fixed tax to do 'vidange/consignage'. When selling a product with a 'consigne/vidange', they add a fixed tax which amount correspond to the 'consigne/vidange'. When returning the 'consigne', you would create an invoice line, with a product with a price of 0, negative quantity,a 0% tax and the fixed tax for the 'consigne'. When an invoice contains such lines, it fails peppol validations.

**STEP TO REPRODUCE**
1. Create a fixed tax used for 'vidange/consigne'.
2. Create an invoice, with a line with unit price of 0, negative quantity, a 0% tax and the fixed tax for the 'consigne'.
3. Send the invoice using peppol, use a validator to validate the xml and notice you get the following errors: [BR-E-01] [BR-E-08].

**CAUSE**
Fixed tax (like the one used for vidange) are aggregated in new invoice lines by the function `_ubl_turn_emptying_taxes_as_new_base_lines()`. Let say we have the following invoice:
line 1: qty=2, unit_price=3, taxes: 21% & vidange(fixed tax of 1). line 2: qty=-1, unit_price=0, taxes: 0% & vidange.

After calling `_ubl_turn_emptying_taxes_as_new_base_lines()`, we got: line 1: qty=2, unit_price=3, taxes: 21%.
line 2: qty=-1, unit_price=0, taxes: 0%.
line 3: qty=1, unit_price=1(amount of the fixed tax), taxes:None.

When generating the VAT breakdown, we have 2 line will end up being tax exempted (line 2 and 3). Because the `tax_exemption_reason` differs, they will not be merged in the same entry in the breakdown, which break the constraint of peppol saying we can only have one VAT breakdown with code 'Exempt from tax'.
Line 2 reason comes from:
https://github.com/odoo-dev/odoo/blob/de22093ee225df499b2de80e1f07dd281ac686bc/addons/account_edi_ubl_cii/models/account_edi_common.py#L271-L274

opw-5912986

Forward-Port-Of: odoo/odoo#250413

Backport of https://github.com/odoo/odoo/pull/249869

Description
This PR addresses a critical validation issue in the accounting module where the system blocks the creation of new journals if a default account linked to an existing journal has been archived.

Current Behavior
Currently, when a user creates a new journal (e.g., a "Bank" type journal), the system automatically generates or assigns a default account. If the user subsequently archives that default account, any future attempt to create a new journal of the same type results in a Validation Error:

"Account codes must be unique. You can't create accounts with these duplicate codes: [XXXXXX]"

This happens because the system's uniqueness check for account codes includes archived accounts, but the automated journal setup logic fails to account for this state, effectively locking the user out from creating new journals until the archived account is manually renamed or unarchived.

Desired Behavior
After this PR is merged, users should be able to create new journals seamlessly, even if previous journals have archived default accounts.

video
https://drive.google.com/file/d/1VzAskdTwF7lNc1y8PIpvN0T2zzKTMtdJ/view

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

**Description of the issue/feature this PR addresses:**
When an activity description is cleared, the stored value may still contain empty HTML content. The UI was still rendering this as a note, resulting in unnecessary blank space in the activity card.

**Current behavior before PR:**
Even when the activity description is cleared and contains only empty HTML, the activity note container is still rendered, leaving visible empty space in the UI.

**Desired behavior after PR is merged:**
The activity note is rendered only when it contains meaningful content. Empty HTML descriptions are ignored, preventing blank space from appearing in the activity card UI.

Before
<img width="445" height="84" alt="image" src="https://github.com/user-attachments/assets/f6648bb0-78d9-4063-a347-fe664370106e" />

After
<img width="459" height="72" alt="image" src="https://github.com/user-attachments/assets/84c2063a-7c68-4dfe-b729-566ca4b5dcd1" />

task-[4752613](https://www.odoo.com/odoo/project/1519/tasks/4752613)

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

Forward-Port-Of: odoo/odoo#252139

Steps to reproduce:
- Enable analytic distribution in Accounting settings
- Create a storable product "P1":
  - Routes: MTO + Buy
  - Vendor: add any supplier
- Create a Sale Order:
  - Add 1 unit of P1
  - Set any analytic distribution
- Confirm the Sale Order

Result:
A Purchase Order is created, but the analytic distribution is not propagated
to the purchase order line.

Problem:
When the Sale Order is confirmed, `_action_launch_stock_rule()` is triggered.
It creates and confirms the corresponding stock move with values from the
sale order line.

Since the product uses the MTO route, the procurement rule is executed.
The rule prepares procurement values from the stock move, but the analytic
distribution is not included in these values:

https://github.com/odoo/odoo/blob/18.0/addons/stock/models/stock_move.py#L1539

Later, `_run_buy` is triggered. It uses the procurement values coming from the
stock move to find an existing purchase order line candidate or to create a
new one. Because the analytic distribution is missing from the values, the
created (or matched) purchase order line does not contain the analytic
distribution:

https://github.com/odoo/odoo/blob/621a93b7b723999d943f1c4da78547763498c008/addons/purchase_stock/models/stock_rule.py#L113

Solution:
Propagate the analytic distribution from the sale order line through the stock
move so it can be included in the procurement values and correctly applied to
the purchase order line.

opw-5936971

Forward-Port-Of: odoo/odoo#252577
Forward-Port-Of: odoo/odoo#252292