When we erase a sn/lot on a MO for a product that is tracked by lot, we will be deadlocked.

### Steps to reproduce:
* Create a product tracked by lot and lot_valuated
* Create a BoM for this product
* Create a MO for this product
* Confirm and Produce all
* erase the lot and save -> the MO is deadlock, it's not possible to modify the lot number, nor it's possible to unbuild.

### Current behavior:
A user is able to erase a lot/SN from a MO of a lot_valuated product.

### Expected behavior:
It should not be possible to erase a lot/SN form a MO of a lot_valuated product.

### Observation:
When the MO is done, its valuation will be calculated which in our case, it means, we have to have a lot number. When trying to add a lot/SN of a MO where it has been erased, we will remove the quantities from the previous lot, but in our case, since we don't have one, it will trigger the user error. https://github.com/odoo/odoo/commit/33e192de30526ea7fe320bcaa7a16dac8108feff
This error is not triggered when removing the SN/lot because when we remove the value, it will be update to False which means it will skip _update_svl_quantity():
https://github.com/odoo/odoo/blob/109f829c2b461b14167e9227e42d096d4410a3b3/addons/stock_account/models/stock_move_line.py#L35-L36
https://github.com/odoo/odoo/blob/109f829c2b461b14167e9227e42d096d4410a3b3/addons/stock_account/models/stock_move_line.py#L62-L65
This use case is also protected when creating a product tracked by lot but not lot_valuated: https://github.com/odoo/odoo/commit/4963103e5587d36364b8df84d0b3407a1977efdf

opw-6039885

Forward-Port-Of: odoo/odoo#257949
Forward-Port-Of: odoo/odoo#255098

**Context:**
For payment methods of type SEPA Credit Transfer, the vendor field is required in a vendor payment but not in the expense form. Since a vendor payment is created from the expense form, if the vendor information is not provided in the expense form for a SEPA payment method, the vendor payment and the expense will not be able to be resetted to draft. As it's being locked into a state of paid.

**Before this commit:**
The user can create an expense with a SEPA Credit Transfer payment method without filling the vendor field. When the user tries to reset to draft the expense or the vendor payment, the missing required fields message will block them from doing it. Since the state is in draft, the user cannot fill the vendor field and reset it to draft.

**After this commit:**
The vendor field is required in the expense form when the payment method is of type SEPA Credit Transfer. This directly prevents the issue from happening.

opw-6073594

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

Currently, an error occurs when the Peppol: update message status scheduled action is executed.

**Error:**
`AttributeError: 'account_edi_proxy_client.user' object has no attribute 'get_peppol_error_message'.`

**Cause:**
When the scheduled action runs, it attempts to update message statuses and retrieve the processing 
state of previously sent invoices using their message UUIDs [1].
If a message is in an error state, the system tries to convert the error dictionary into a readable, 
translated message based on the error code and details [2]. And, this raises an error because account_edi_proxy_client.user does not have the method get_peppol_error_message when retrieving 
the error message [3], as it is defined in an exception file.

This commit ensures the correct usage of get_peppol_error_message, as it is already imported, instead 
of calling it on account_edi_proxy_client.user.

[1]: https://github.com/odoo/odoo/blob/f7c309cdac754ead9e00b3443a2fe764efec819c/addons/account_peppol/models/account_edi_proxy_user.py#L351

[2]: https://github.com/odoo/odoo/blob/f7c309cdac754ead9e00b3443a2fe764efec819c/addons/account_peppol/models/account_edi_proxy_user.py#L379

[3]: https://github.com/odoo/odoo/blob/f7c309cdac754ead9e00b3443a2fe764efec819c/addons/account_peppol/models/account_edi_proxy_user.py#L384

sentry-7395549907

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

Currently, when a user creates a quotation from the Opportunities available in Contacts, archived warehouses are also considered for the quotation.

## Steps to replicate:
- Install Sales, CRM, and Inventory.
- Create a new Warehouse and move it to the first position in the warehouse list view (highest priority).
- Archive the newly created warehouse.
- Navigate to Contacts > Acme Corporation > Opportunities >Office Design Project
- New Quotation > Other Info > Delivery and check the Warehouse field.

## Observed behavior
The archived warehouse is still assigned to the Warehouse field in the Delivery section. This issue does not occur when the user creates a quotation directly from the CRM app, it only happens when the quotation is created through the Contacts apps.

## Root cause:
This unintentional behavior was introduced after commit [1]. When a user opens 'Opportunities' from the contacts view, the function `action_view_opportunity` [2] is triggered, which sets `active_test` to False in the context.

Later, when a new quotation is created, the compute method [3] is executed. This method calls `_get_default_warehouse_id` [4], which performs a search. Because `active_test` is already set to False in the context, the search also includes archived warehouses, causing them to be fetched unintentionally.
[2]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/crm/models/res_partner.py#L39-L53 [3]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/sale_stock/models/sale_order.py#L194-L204 
[4]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/stock/models/res_users.py#L9-L12

## Solution:
Explicitly set `active_test=True` in the context when preparing the quotation for an opportunity. This ensures that archived warehouses are excluded from the search and prevents them from being selected.

**Alternate Solution:**
We could also make `active_test` to true when searching for warehouse directly as well.
```py
 def _get_default_warehouse_id(self): 
     # !!! Any change to the following search domain should probably 
     # be also applied in sale_stock/models/sale_order.py/_init_column. 
     return self.env['stock.warehouse'].with_context(active_test=True).search([('company_id', '=', self.env.company.id)], limit=1)
```
[1]:
https://github.com/odoo/odoo/commit/59feed9f26937ae8e2cab5cd7d2b6743ab6c0717 

opw-5999034

Forward-Port-Of: odoo/odoo#252166

Steps to reproduce:
1. Create a currency with a non-1 exchange rate with the company's
currency (e.g. VEF with a rate of 0.000005 against USD).
2. Create a pricelist in that currency.
3. Create an event.
4. Create a sale order with the new pricelist.
5. Add a sale order line with a ticket of the event and confirm
the order.
6. Go to the event's page and check the total sales smart button.
7. Check the total sales of the event: it should be equal to the sale
order's total price converted to the company's currency, but it is not,
because of the wrong conversion (it used the inverse of the correct
exchange rate, which is 200000 instead of 0.000005 in our example).

Problem:
The total sales smart button in an event's page shows wrong totals when
sales are in a currency other than the company's currency.

Cause:
The code converts the sale price from the event's currency (which is the
same as the company's currency) to each sale order's currency, while it
should be the other way around (from each sale order's currency to the
event's currency).
https://github.com/odoo/odoo/blob/3cd709172e997f5a726cf3ae85ffcb9965619fcb/addons/event_sale/models/event_event.py#L38

opw-5494790

Forward-Port-Of: odoo/odoo#258000
Forward-Port-Of: odoo/odoo#253605

### Steps to reproduce:

- In the settings Dropshipping
- Put you warehouse in 2 steps delivery
- Create a kit product with 2 components: COMP1, COMP2
- Set a vendor on COMP2 and the dropship route
- Create and confirm an SO for 1 unit of your kit
- Validate the ship and pick for COMP1
- Confirm the PO for COMP2 and validate the associated dropship
#### > The qty_delivered on the sol is still at 0

### Cause of the issue:

The `delivered_qty` is computed via the `_prepare_qty_delivered`: https://github.com/odoo/odoo/blob/9b9ff3ddcba6f0c9d37d08fb4fb900bed3b396a4/addons/sale/models/sale_order_line.py#L887-L902 However, since at least on of the component is dropshipped, the qty_delivered is computed by this condition: https://github.com/odoo/odoo/blob/9b9ff3ddcba6f0c9d37d08fb4fb900bed3b396a4/addons/sale_mrp/models/sale_order_line.py#L54-L63 Which is 0 since the pick `location_dest_id.usage` is not `customer`.

### Additional issue:

The delivered quantity of a Kit with at least one dropshipped component can only be 0 or the full demand.

- In the settings enable Dropshipping
- Create a kit product with 2 components: COMP1, COMP2
- Set a vendor on COMP2 and the dropship route
- Create and confirm an SO for 3 unit of your kit
- Validate the delivery for COMP1 for 2 units and backorder
- Confirm the PO for COMP2 and validate the associated dropship for 1 unit and do not backorder
#### > The qty_delivered on the sol is 0 instead of 1
- Cancel the backorder for COMP1
### > The qty_delivered on the sol is 3 instead of 1

### Cause of the issue:

This is caused by the exact same dropship computation: https://github.com/odoo/odoo/blob/9b9ff3ddcba6f0c9d37d08fb4fb900bed3b396a4/addons/sale_mrp/models/sale_order_line.py#L63-L66

### Note:

The behavior should be consistent if the components are fully dropshipped or MTO buy and as such they should not be considered to be in all or nothing shipping policy.

opw-6040640

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

Steps to reproduce:
- Use a Luxembourg company
- Post a P&L result for the year and do the year-end affectation (Dr 142 / Cr 1412)
- Open the Luxembourg balance sheet (full or abbreviated)

Issue:
Line "V. Profit or loss brought forward" shows incorrect values.

Cause:
The `accounts` expression for that line used `account_codes` engine with formula `-14`,
which only sums accounts by code prefix. Account 1412 ("Results brought forward (assigned)")
was typed as `equity`, so its balance was carried forward as an initial balance instead of
being captured as retained earnings in the formula.

Solution:
- Set account 1412 to `equity_unaffected`, consistent with account 142.
- Change the `accounts` expression of Line V in both the full and abbreviated balance sheet
  to use the `domain` engine:
  `['|', ('account_id.code', '=like', '14%'), ('account_id.account_type', '=', 'equity_unaffected')]`
  with subformula `-sum`.
  This correctly captures the balance of all 14x accounts and any `equity_unaffected` accounts,
  which covers the standard year-end affectation workflow.

opw-5883505

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/4561a9a809 [REL] 19.0.29 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/cd7707f944 [FIX] format: keep negative accounting suffix in large number [Task: 6068834](https://www.odoo.com/odoo/2328/tasks/6068834)
https://github.com/odoo/o-spreadsheet/commit/f7b1c449c8 [IMP] tests: add image snapshots for renderer store tests [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/46c70d8670 [FIX] renderer: rendering tests are wrong [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/bd47b32e9e [IMP] tests: update jest to v30 [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/bfb8e0595f [FIX] cf: add sanity checks on conditional format type/operator [Task: 6106092](https://www.odoo.com/odoo/2328/tasks/6106092)
https://github.com/odoo/o-spreadsheet/commit/aee92bcbdd [FIX] live-server: specify host to avoid issues with some browsers [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/f5e1d32287 [FIX] spreadsheet: chart side panel content should use full height [Task: 6080680](https://www.odoo.com/odoo/2328/tasks/6080680)
https://github.com/odoo/o-spreadsheet/commit/89c8b30ee2 [FIX] xlsx: export formula that returns an error [Task: 6008904](https://www.odoo.com/odoo/2328/tasks/6008904)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Steps to Reproduce:
-
1. In the Project app, create a new project and enable "Timesheets".
2. Create a parent task with allocated hours (e.g., 20h).
3. Create one or more sub-tasks under the parent, also with allocated hours (e.g., 8h and 5h).
4. Log in to the portal and navigate to the project's task list.
5. Observe the "Total" allocated time shown in the list header.

Issue:
-
- The total allocated time displayed in the portal incorrectly sums the hours of the parent task and all its sub-tasks (e.g., 20h + 8h + 5h = 33h). This leads to an inflated and confusing total for the customer.

Cause:
-
- The `_get_portal_total_hours_dict` method calculated the sum of `allocated_hours` on the entire recordset of tasks passed to it, without distinguishing between parent tasks and their children when both were present.

Fix:
-
- This commit excludes sub-task hours from the total allocated time computation if their parent task is also present in the view.
- The total time spent now uses parent `total_hours_spent` which includes both time spent on parent and sub-task.

task-4939234

Forward-Port-Of: odoo/odoo#258485
Forward-Port-Of: odoo/odoo#221563

… sheet

Steps to reproduce:
- Use a Luxembourg company
- Post a P&L result for the year and do the year-end affectation (Dr 142 / Cr 1412)
- Open the Luxembourg balance sheet (full or abbreviated)

Issue:
Line "V. Profit or loss brought forward" shows incorrect values.

Cause:
The `accounts` expression for that line used `account_codes` engine with formula `-14`, which only sums accounts by code prefix. Account 1412 ("Results brought forward (assigned)") was typed as `equity`, so its balance was carried forward as an initial balance instead of being captured as retained earnings in the formula.

Solution:
- Set account 1412 to `equity_unaffected`, consistent with account 142.
- Change the `accounts` expression of Line V in both the full and abbreviated balance sheet to use the `domain` engine: `['|', ('account_id.code', '=like', '14%'), ('account_id.account_type', '=', 'equity_unaffected')]` with subformula `-sum`. This correctly captures the balance of all 14x accounts and any `equity_unaffected` accounts, which covers the standard year-end affectation workflow.

opw-5883505

**Issue**:
Even when creation of new Serial Numbers for components is disabled
on the Manufacturing Operation Type, it is still possible to create
them from the shopfloor application.

**Steps to reproduce**:
- Enable "Lots & Serial Numbers", on the global settings
- Create two products, one tracked by unique serial number
- Go to Inventory > Configuration > Warehouse Management > Operations Types
- Select Manufacturing and disable "Create New Lots/Serial Numbers for Components"
- Create and confirm a MO using the tracked product as component
- Go to shopfloor
- Click the "+" button next to the component, then "New"
-> No error is raised when creating a serial number

**Cause**:
The `_check_create` constraint relies on `active_mo_id`:
https://github.com/odoo/odoo/blob/494cdcfdf4ec166e0a643ee70a53c12c810d02b4/addons/mrp/models/stock_lot.py#L11-L19
However, the shopfloor does not pass this, in context:
https://github.com/odoo/enterprise/blob/54c6252a0e13b11fc297b6828883923c0f89881a/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L193-L199

As a result, the check is bypassed.

opw-6041241