Currently, when a user creates a kit, the price of the kit itself is included in stock valuation.

## Steps to produce:
* Install `mrp_account` without demo data.
* Create a product with inventory tracking enabled.
* Create a BoM of type kit for that product.
* Add component products with a defined cost and on-hand quantity greater than 0 to the BoM.
* Recompute the kit product’s cost from its BoM on the product page.
* Go to Inventory > Reporting > Stock.

## Observed Behavior:
The cost of the kit is currently being included in the stock valuation.

For example, consider a kit product called **“Computer”** that is composed of the
following components:
| Product | Quantity | Cost |
|--------|--------|--------|
| CPU | 1 | $300 |
| Motherboard | 1 | $300 | 

The total cost of the Computer kit is therefore $600. Since the Computer is made up of the CPU and Motherboard, the total inventory value should be $600. However, the system is currently calculating the total inventory value as $1,200
, which is incorrect because it is counting both the kit and its components.

## Root cause:
This behavior started after the refactor in [1], where the `_compute_value_svl`
function was replaced by the `compute_value` function to calculate both average and total value for 
inventory valuation.

With this change, the new compute function in [2] now also includes kit products when calculating inventory valuation based on their costing method.

In earlier versions, this did not occur because `_compute_value_svl` depended on valuation layer groups. Kit products were excluded at [3] through the  `_get_valuation_layer_groups()` call, as illustrated in image [4].

[2]-
https://github.com/odoo/odoo/blob/1b9937a702fbeb47cd6d42d8119cead5828fd3fe/addons/stock_account/models/product.py#L139-L169 
[3]-
https://github.com/odoo/odoo/blob/a9d2e54201173d1d2d5ab97de0904d63a4b6b82b/addons/stock_account/models/product.py#L284

## Solution:
To ensure correct total inventory valuation, kit products should be excluded from valuation and only their individual components should be calculated.

This can be achieved by modifying the domains used in 'action_product_stock_view` and `_get_accounts_by_product`
to exclude the kits so that the kit products get filtered out, allowing the report to consider only its components.

**Before:**
<img width="1857" height="938" alt="image" src="https://github.com/user-attachments/assets/bbd4eb94-ba1a-429a-a61c-afbe33729ac0" />

**After:**
<img width="1915" height="883" alt="image" src="https://github.com/user-attachments/assets/c93d55c8-8197-4e57-9f87-b2159fe67d87" />

[1]:
https://github.com/odoo/odoo/pull/222169/commits/6e694b79b8892d693117f6c79df1a2d3a4759f4f 
[4]:
https://drive.google.com/file/d/1g4BzGscCW2K0rf5iDKrq-psYRlKhYkDP/view?usp=sharing

opw-5462515

Forward-Port-Of: odoo/odoo#244030

The invoice outstanding credits/debits widget currently displays all reconcilable items for a partner across the same account, regardless of the company they belong to.

In multi-company environments, specifically when accounts have been merged, this allows users to see
and try to reconcile payments from Company A into an invoice from Company B. This action eventually triggers a validation error stating that entries must belong to the same company.

This commit adds a company filter to the widget's logic to ensure only relevant outstanding payments are suggested, preventing cross-company reconciliation errors and improving UX.

**Description of the issue/feature this PR addresses:**
This PR fixes a validation error in multi-company environments where the invoice_outstanding_credits_debits_widget suggests payments or credit notes belonging to a different company than the current invoice.

The issue typically arises when a partner has outstanding transactions in multiple companies and the accounts (e.g., Account Receivable) have been merged, allowing the widget to query lines that are not valid for the current record's company context.

**Current behavior before PR:**
When viewing an invoice for Company A, the "Outstanding Credits/Debits" widget displays all reconcilable account.move.line records for that partner that match the account type, regardless of their company_id.

If a user clicks "Add" on a payment that belongs to Company B, Odoo attempts to reconcile them, resulting in a traceback or a validation error:

"Invalid Operation: All tracebacks/entries must belong to the same company."

This creates confusion for the end-user, as they are presented with "ghost" credits that cannot actually be applied.

**Desired behavior after PR is merged:**
The invoice_outstanding_credits_debits_widget (and the underlying logic in account.move) will strictly filter the suggested outstanding items by self.company_id.

Users will only see and be able to reconcile payments, credit notes, or debits that belong to the same company as the invoice they are currently processing. This ensures data integrity and a seamless UX in multi-company setups.

**Steps to reproduce:**
1) Enable Multi-Company: Ensure you have at least two companies (e.g., Company A and Company B) active in your database.

2) Chart of Accounts Setup:

In both companies, use the same account for Receivables (or merge them so they share the same ID/Code if testing a migrated environment).

3) Ensure the account is marked as Allow Reconciliation.

4) Create a Payment in Company B:

5) Post the payment so it remains as an "Outstanding Receipt".

6) Create an Invoice in Company A

7) Confirm/Post the invoice.

8) Check the Widget:
Scroll down to the bottom of the Invoice form in Company A.

9) Observe the "Outstanding Credits" widget.

The Error:
The payment from Company B will appear as an available credit for the invoice in Company A.

10) Click on "Add".

A validation error (UserError) will pop up: "All entries must belong to the same company."

**video**
https://drive.google.com/file/d/1PfBxupP8t-t21wsP2FIgNXFnTP0Zq140/view

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

Forward-Port-Of: odoo/odoo#255875

Since odoo/odoo#249455 the order payload from the self order frontend is being checked to ensure the data is valid. However, these checks did not account for the situation where payment data is included, as is the case when using a self order kiosk with a payment terminal connected. The result was that using the kiosk with a payment terminal would result in an error even though the payment was successful on the terminal.

Steps to reproduce:
- Configure a self order kiosk POS
- Connect a payment terminal (Adyen, Stripe, Viva etc.)
- Try to pay for an order from the kiosk

EXPECTED:
- The order is made successfully.

ACTUAL:
- A generic error message is shown and the order fails. The payment goes through successfully on the payment terminal.

The fix is to allow a payment to be included in the self order data, but only in Kiosk mode and only if the payment amount is valid.

We also now validate that the self ordering type is correct, this
ensures that a kiosk payment cannot be spoofed for a mobile self order
POS.

Finally, there is also a small change for Viva.com to use the PoS config
name instead of UUID, since UUID is no longer loaded in self order.

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

Forward-Port-Of: odoo/odoo#256042

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
- Inventory > Configuration > Warehouse Management > Routes
- Unarchive MTO
- Create a storable product with a vendor using the MTO route
- Create and confirm an SO for 1 unit of that product
- Cancel and reset to draft the associated draft PO
- Update the SO demand from 1 to 2 units
#### > A new draft PO is created rather than updating the existing one.

### Cause of the issue:

Both the confirmation and the demand updates of the SO call the `_action_launch_stock_rule` to generate the related PO. The procurement and PO generated in both cases including the `stock_reference_ids` of the SO: https://github.com/odoo/odoo/blob/3891dd471d64629634644c0b022a171bbaa65b49/addons/sale_stock/models/sale_order_line.py#L277-L289
However, cancelling the PO will remove its assocaited stock reference: https://github.com/odoo/odoo/blob/3891dd471d64629634644c0b022a171bbaa65b49/addons/purchase_stock/models/purchase_order.py#L201-L202
As such, when the second procurement is run, the `_run_buy` will not consider the existing PO without reference as a valid candidate to update:
https://github.com/odoo/odoo/blob/3891dd471d64629634644c0b022a171bbaa65b49/addons/purchase_stock/models/stock_rule.py#L370-L372
An it will therefore create a new one:
https://github.com/odoo/odoo/blob/3891dd471d64629634644c0b022a171bbaa65b49/addons/purchase_stock/models/stock_rule.py#L101-L115

opw-5940590

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

Forward-Port-Of: odoo/odoo#258696

Steps to produce:
---
- Install the `Sales` module.
- Enable discounts from settings.
- Create a Sale Order with a negative discount on an order line.
- Preview the Sale Order and click on the view details button.

Issue:
---
- Negative discount values are not shown in the preview (portal view), but they are displayed in the generated PDF.

Root cause:
---
- At [1], the portal template includes a condition to display discounts only when they are greater than 0, while the report templates lack this check, leading to inconsistent behavior.

Solution:
---
- Applied the same condition in the report templates to align the PDF output with the portal preview behavior.

Before:
---
<img width="787" height="136" alt="image" src="https://github.com/user-attachments/assets/d32311be-4aec-4d6f-b905-d5e52f712ba4" />

After:
---
<img width="775" height="139" alt="image" src="https://github.com/user-attachments/assets/2614a8ad-dca6-49ca-b720-5c234aa91cf6" />


[1]https://github.com/odoo/odoo/blob/0f463fd247d2f5da79d6ec2b6bec18774f6f600b/addons/sale/views/sale_portal_templates.xml#L539

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

opw-6061568

Forward-Port-Of: odoo/odoo#258981
Forward-Port-Of: odoo/odoo#255735

Steps to reproduce:
-------------------------
1. Install the Time Off module.
2. Go to Time Off > Management > Allocations, create an allocation for an employee, and approve it.
3. Go to Reporting > Balance and apply the filter Department > Employee.
4. Change the employee’s department.
5. Create an allocation for the same employee and approve.
6. Apply the Department > Employee filter again.

Observed behaviour:
----------------------------
After a department change:
* Existing allocations keep the old department
* New allocations use the new department

As a result, duplicate employee entries appear in the report

Cause:
----------
It is using allocation.department_id.
Allocations store the department at creation time, which may differ from the employee’s current department, causing an incorrect report filtering.

Solution:
------------
Fetch department_id from hr_version instead of hr_leave_allocation in the hr_leave_employee_type_report.

This ensures:
* Leave balances always follow the employee’s current department
* Correct aggregation when grouping by Department → Employee

opw-5220577

Before:
<img width="1238" height="857" alt="image" src="https://github.com/user-attachments/assets/15e1293b-dc50-4067-a12f-079c046c2074" />

After:
<img width="1247" height="824" alt="image" src="https://github.com/user-attachments/assets/feea32de-0d9c-4eef-9ae5-639f4658560c" />





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

Forward-Port-Of: odoo/odoo#258562

### Steps to reproduce:
	- Create an accrual plan of one level to give 20 days at the start of the year
	- Create an allocation with different mode than 'By Employee'
	- Set the accrual plan for the allocation and date from 1st Jan
	- Notice the Allocation number of days doesn't get automatically calculated

### Cause:
This is happening because when trying to process the accrual plan we won't have any records in the field employee_id

https://github.com/odoo/odoo/blob/bcdd12d13d73915e565fd2c8478b936a16efb9f4/addons/hr_holidays/models/hr_leave_allocation.py#L892-L893

And since employee_id is computed field when computing it we don't handle the case of any other mode other than 'By Employee'.

https://github.com/odoo/odoo/blob/bcdd12d13d73915e565fd2c8478b936a16efb9f4/addons/hr_holidays/models/hr_leave_allocation.py#L259-L270

### Fix:
If we have different mode in the allocation we fetch the employees in this mode (Department, Company, Employee Tag) and set them as the allocation employee_ids so when computing the employee_id we will have a record in the field and it won't be null

P.S. In the forward port we will have to introduce another fix for the multi allocation wizard

opw-5888023

Forward-Port-Of: odoo/odoo#258520
Forward-Port-Of: odoo/odoo#247091

Before this commit, the message highlight was too distracting. This was improved [1] so that highlighted message doesn't have the vertical translation during the highlight duration. To make the message more visible than the other messages, other messages have their opacity reduced.

While reduced opacity is good, there was an extra blur, which is more distracting. This commit fixes it by removing it.

Also at the end of message highlight, the scroll position of message list was changing when this shouldn't. This happens for 2 reasons:

1. The "Welcome to conversation" message was mistakenly displayed during the message highlighting, thus when message highlight ended its removal would substract some scrollTop and move scroll up.
2. The "Load More" was temporarily not shown during the message highlight. This is a problem because when message highlight ended, this was adding slightly more scollTop and move scroll down.

The "Welcome to conversation" should not be shown when there's logically a "Load more", which this commit fixes. The hiding of "Load More" was intended to avoid their triggering when opening conversation [2], but the logic around these triggers had been improved [3] therefore this is no longer necessary. This commit relaxes the showing of "Load more" to display them even during a message highlighting.

Task-6121035

[1]: https://github.com/odoo/odoo/pull/246989
[2]: https://github.com/odoo/odoo/pull/181392
[3]: https://github.com/odoo/odoo/pull/216776

Before / After

_(before visual artifacts come from GIF recorder that doesn't like blur)_
![before](https://github.com/user-attachments/assets/2a1ab290-7df3-49db-b132-67599ef693e7)
![after](https://github.com/user-attachments/assets/ad531b18-71af-4704-ad5a-29e630e87d6a)

[FIX] purchase: set the correct price in alternative PO
Steps to reproduce the bug:
- Enable "Purchase Alternatives" in settings
- Go to Accounting > Configuration > Taxes:
    - Configure a 15% purchase tax:
    - Advanced Options tab:
    - Included in Price: enabled

- Create a storable product "P1":
    - Tax: 15%
    - In the Purchase tab, add vendors:
        - "Azure Interior": price = $10, min qty = 1
        - "Deco Addict": price = $15, min qty = 1

- Create a purchase order for "Azure Interior":
    - Order 100 units → total price is automatically computed as $1000
- Create an alternative purchase order:
    - Vendor: "Deco Addict"
    - Copy products: enabled

Problem:
The price is $1360, instead of $1500

When the alternative purchase order is created and the product is set
on the purchase order line, the required onchange methods are not
triggered:
https://github.com/odoo/odoo/blob/ad253ef4c2cb06536b99bb919a3e01ed980d2e96/addons/purchase/models/purchase.py#L1169

As a result, both the unit price and the taxes are missing on the
purchase order line. When `_compute_price_unit_and_date_planned_and_name`
is triggered, it attempts to compute the `price_unit`.

https://github.com/odoo/odoo/blob/fb24ad03fc47a303fa8719c0795e1afa9a7eb821/addons/purchase/models/purchase_order_line.py#L345-L346

At this point, it checks whether the purchase order has a vendor.
Since "Deco Addict" is set, it calls `_fix_tax_included_price_company`
using:
- the supplier price ($15)
- the supplier tax (15%)

However, since no taxes are yet set on the purchase order line,
`_fix_tax_included_price_company` incorrectly assumes the price is
tax-included and converts it to a tax-excluded price
(~13.04 instead of 15).

https://github.com/odoo/odoo/blob/7076b4f4d0d933d93b24e8e4c7cf21ef0b0008e5/addons/account/models/account_tax.py#L571-L573

Then, a 15% tax is applied on top of this incorrect base price, leading
to the wrong total.

opw-6047004

Forward-Port-Of: odoo/odoo#258154

PR #212726 removed a Many2One field and replaced it with an existing binary field (`l10n_it_edi_attachment_file`) and a new Char field (`l10n_it_edi_attachment_name`) to store E-invoice files as XMLs. This change was made for security reasons.

This pre-existing binary field was already used for importing SDI documents, which caused errors resolved in PR #252806.

The new char field was not set during the SDI import process in PR #212726. This can cause errors when exporting invoice documents, as our code sees content in the binary field and expects the name to also be present. See [`_get_invoice_legal_documents()`](https://github.com/odoo/odoo/blob/f48f221c91b8d123bcaf1c4d8ed6c7dfba763ae6/addons/l10n_it_edi/models/account_move.py#L411).

This commit ensures that the name of an imported SDI document is set in the move's `l10n_it_edi_attachment_name` field.

opw-6023263
[link](https://www.odoo.com/odoo/my-tasks/6023263)

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

Forward-Port-Of: odoo/odoo#258882
Forward-Port-Of: odoo/odoo#257586