## **Issue**

When a cash basis tax is configured with a payable/receivable
transition account, tax journal items are generated on that account
without a due date.

Since payable/receivable accounts require a due date on journal
items, this leads to a validation error during move creation:

"Any journal item on a payable account must have a due date and vice versa."

## **Steps to reproduce:**

1. Install the Accounting and Inter-Company modules.
2. Create an additional company so that there are a total of two companies, then switch to Company 1.
3. Create a product with a price and assign a tax to it.
4. Navigate to Accounting → Configuration → Settings and enable Cash Basis accounting.
5. Go to Accounting → Configuration → Taxes and open the purchase tax (or the tax assigned to the product).
6. In the Tax Computation section, ensure that Group of Taxes is not selected.
7. Under the Advanced Options tab, set Tax Exigibility to Based on Payment.
8. Set the Cash Basis Transition Account to a payable account.
9. Open Company Settings, select Company 1, go to the Inter-Company Transactions section, and enable Synchronize invoices/bills.
10. Switch to Company 2 and create an invoice using the same product. Select the contact that is the partner of Company 1.
11. Confirm the invoice.

The following error is raised:

"Any journal item on a payable account must have a due date and vice versa."

## **With This Commit:**
Added a domain on the Cash Basis Transition Account field to prevent
users from selecting payable or receivable accounts, avoiding invalid
configurations and runtime validation errors.

opw-6189615

Forward-Port-Of: odoo/odoo#264777
Forward-Port-Of: odoo/odoo#263792

Steps to reproduce:-
- Navigate to Time off Dashboard calendar view.
- Create a leave. First approve it then refuse it.
- Now on the same day create a leave and approve it.
- Now re-approve the previously refused leave from step 2.
- System will let user to create 2 leave of same types on same day!

Cause:-
In `_compute_dashboard_warning_message`, refused/cancelled leaves were
excluded from warning computation. When approving a refused request,
the warning message was not set, allowing the constraint check to pass
even when conflicting approved requests existed for the same period.

Fix:-
1. Refactored `_compute_dashboard_warning_message` to only compute
   warnings for active leaves (non-refused/cancelled) while still
   detecting conflicts with already approved requests
2. Updated `_check_date` constraint to skip validation for refused/
   cancelled leaves, but enforce it when state changes to validate
3. Added 'state' to constraint triggers to ensure validation runs
   when approving previously refused requests

task-[6181717](https://www.odoo.com/odoo/project/1251/tasks/6181717)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#265192
Forward-Port-Of: odoo/odoo#262703

The `partner_pages_tree_view` was attempting to modify `activity_ids` field attributes, but this field is added by the mail module in a sibling inheritance branch ([mail.res_partner_view_tree_inherit_mail]), making it unreachable from the [`partnership.view_res_partner_grade_tree`] ancestry chain:
```py
  base.view_partner_tree → partnership.view_res_partner_grade_tree → partner_pages_tree_view
  base.view_partner_tree → mail.res_partner_view_tree_inherit_mail ← activity_ids lives here
```
This caused a ParseError during base module upgrade:
```py
  File "/home/odoo/odoo/odoo/odoo/tools/convert.py", line 639, in _tag_root
    raise ParseError(msg) from None  # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
odoo.tools.convert.ParseError: while parsing /home/odoo/odoo/odoo/odoo/addons/base/views/res_partner_views.xml:13
Error while parsing or validating view:
Element '<field name="activity_ids">' cannot be located in parent view
View error context:
{'file': '/home/odoo/odoo/odoo/odoo/addons/base/views/res_partner_views.xml',
 'line': 1,
 'name': 'Partner Pages List',
 'view': ir.ui.view(2148,),
 'view.model': 'res.partner',
 'view.parent': ir.ui.view(2108,),
 'xmlid': 'website_crm_partner_assign.partner_pages_tree_view'}
```

**Steps to reproduce:**
- In a v19.1 db install `website_crm_partner_assign`
- Go to apps and search base module and click upgrade

**Fix:**
Make the partner view from partnership inherit from the one defined in mail instead of the one defined in base. 

opw-6186684

[mail.res_partner_view_tree_inherit_mail]: https://github.com/odoo/odoo/blob/saas-19.3/addons/mail/views/res_partner_views.xml#L58C21-L67
[`partnership.view_res_partner_grade_tree`]: https://github.com/odoo/odoo/blob/f3b317310b84edb073009f7d15d7fec002f3ccf0/addons/partnership/views/res_partner_views.xml#L48-L57





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

Forward-Port-Of: odoo/odoo#264639

**Steps to reproduce:**
1. Install Time Off
2. Go to Accrual Plans and create a new plan with a milestone
3. Set frequency to Weekly and choose a day other than Monday (e.g., Tuesday)
4. Save and check the displayed weekday in the accrual plan level

**Issue:**
The displayed weekday is incorrect (e.g., shows Monday instead of Tuesday).

**Cause:**
Previously, the weekday value was directly displayed using: https://github.com/odoo/odoo/blob/b40184ab371f7a4708621ecf7f25b4e2daaae38d/addons/hr_holidays/views/hr_leave_accrual_views.xml#L212-L214 so no conversion was involved.

Now, the value is processed using Luxon. However, the week_day field stores values from 0 (Monday) to 6 (Sunday), while Luxon expects ISO weekday numbers from 1 (Monday) to 7 (Sunday). This mismatch causes an off-by-one error during conversion.
https://github.com/odoo/odoo/blob/1b3d0a3c2f794324f8b230a9ae19f097454e3bdd/addons/hr_holidays/models/hr_leave_accrual_plan_level.py#L54-L62

**Solution:**
Adjust the value before passing it to Luxon by adding +1 to match ISO format.

opw-6112614




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

Forward-Port-Of: odoo/odoo#259054

Steps to reproduce:
===================
1. Enable a second language on the website
2. Add a Table of Content snippet to a page
3. Apply bold (or any inline style) to one of the headings, save
4. Switch to the second language in translation mode
5. Translate the styled heading and save

=> The TOC navbar entry keeps showing the source text on reload.
=> Expected: navbar shows the translated heading text, unstyled.

Cause:
======
When a TOC heading carries inline markup, the server emits the
heading and the navbar entry as two independent translation terms
with different `data-oe-translation-source-sha` values, even though
their textContent matches. A translation written under the heading's
sha therefore never reaches the navbar's slot.

`handleToC` was meant to bridge that by aliasing the navbar span's
sha to the heading's during translation-mode setup, but two issues
prevented it from working in saas-18.4+:

- The TOC navbar lives under `.o_not_editable`, so its translation
  spans were excluded from `findOEditable` and `handleToC` never
  ran on them. The class `o_translation_without_style` was never
  added, and the sha was never aliased.

Solution:
=========
- `prepareTranslation` iterates TOC navbar translation spans
  explicitly, so `handleToC` reaches them despite `findOEditable`
  skipping `.o_not_editable`.
- `handleToC` always tags the navbar span with
  `o_translation_without_style` when a matching heading exists.
- An `after_replication_handlers` hook flags every replicated
  unstyled-translation target as `.o_dirty`, so the replicated
  translation is included in the save.

opw-5950228

Forward-Port-Of: odoo/odoo#263547
Forward-Port-Of: odoo/odoo#260378

Version:
--------
- saas-19.1+

Step to reproduce:
----------------------
* Install *sale_management* and *stock* modules.
* Create a Sale Order with at least two order lines.
  * Set different *Customer Lead Time* (it is optional hide by default)
 on each line:
    * Line A: 5 days
    * Line B: 10 days
* Confirm the Sale Order.
* Open the generated Delivery Order.
* Enable the *Deadline* field on stock moves (it is optional hide by default).
* Check the *Deadline* value for each move

issue:
-----
 * Both stock moves have the same *Deadline*, corresponding to the minimum
  lead time (earliest date), instead of their respective values.
 
Root cause:
-----------
1. User confirms a Sale Order with two lines:
     - Line A: customer_lead = 5  → _expected_date() = order_date + 5
     - Line B: customer_lead = 10 → _expected_date() = order_date + 10

2. sale.order.action_confirm()
   └─ Before calling `_action_confirm()`, the method set:
        `order.commitment_date = order.expected_date`
      where `expected_date = min(all line._expected_date()) = order_date + 5`

3. sale.order._action_confirm()
   └─ calls order_line._action_launch_stock_rule()
https://github.com/odoo/odoo/blob/00edcf55380431c454857b2749f2fe4930b1e758/addons/sale_stock/models/sale_order.py#L209

4. sale.order.line._action_launch_stock_rule()
   └─ per line: calls line._prepare_procurement_values()

5. sale.order.line._prepare_procurement_values()
   └─ date_deadline = self.order_id.commitment_date or self._expected_date()
      Because commitment_date was force-set in step 2, BOTH lines resolve to
      order_date + 5 instead of their individual values.

https://github.com/odoo/odoo/blob/00edcf55380431c454857b2749f2fe4930b1e758/addons/sale_stock/models/sale_order_line.py#L281

NOTE:
------

This issue originates from changes introduced in task: https://www.odoo.com/odoo/project/966/tasks/4687135
That task aimed to add the Promise Date to Purchase Order Lines and, during 
confirmation, assign it as the expected arrival date.

* This behavior works correctly in Purchase Orders because the Promise Date is
 applied at the purchase order line level and aligned with each 
line’s expected arrival date.  It does not participate in the computation of 
date_deadline.

- In the purchase flow:
The incoming stock move date_deadline is directly derived from each line’s 
expected arrival date.
https://github.com/odoo/odoo/blob/00edcf55380431c454857b2749f2fe4930b1e758/addons/purchase_stock/models/purchase_order_line.py#L308
There is no dependency on a promise date.
As a result, deadlines remain per-line and accurate.

However, in the Sale Order flow, the same approach introduces an issue.

Here:
The Promise Date (commitment_date) exists at the order level, not at line level.
During confirmation, it is set using the minimum of all line expected dates.
The delivery stock move date_deadline depends on this commitment_date.

As a consequence:

Setting a single order-level promise date overrides all per-line expected dates.
All stock moves receive the same (minimum) deadline.

Additionally, this is not aligned with the business logic:

Example:
Line A → lead time = 5 days
Line B → lead time = 10 days
Current behavior sets deadline = min(5, 10) = 5 days for all moves,
which incorrectly forces later deliveries to be scheduled earlier than intended.

Solution:
---------
* Remove the automatic assignment of commitment_date = expected_date in action_confirm().
commitment_date is a user-defined promised delivery date and should not be
 implicitly set during confirmation. By leaving it unset, procurement values
correctly fall back to line._expected_date(), restoring per-line deadline
computation.

---

opw-6106045

Forward-Port-Of: odoo/odoo#258911

Commit 28b840b introduced logic to include `freight_costs` in the customs document generated bySendcloud. It introduced 2 new issues as a result:

1. When creating backorders, the `freight_costs` are not divided but instead propagated to all of the pickings.
2. When there is no SO, we were taking the total value of all delivered goods, which doesn't make much sense considering the `freight_costs` field should be the cost of the delivery itself.

Solution
-----
For the first problem, there are a couple things to keep in mind:
- the total `freight_costs` declared to the customs entity should be the amount invoiced to the customer
- products can be added and removed from the picking after the SO has been confirmed
- actual delivery cost can change between invoice date and actual delivery date
- picking can be split into multiple packages at the user's discretion

Considering all of the above, we will simply forward the invoiced amount with the first confirmed picking and none of the backorders.

-----
Ticket:
opw-6013387

Forward-Port-Of: odoo/enterprise#117115
Forward-Port-Of: odoo/enterprise#111304

**Steps to reproduce:**
* Install `l10n_mx` module.
* Go to Accounting > Assets and create a new asset.
* Attempt to select a Fixed Asset account in the corresponding field.

**Observed behavior:**
* No existing Fixed Asset accounts correctly show up in the selection.
* Even if an asset goes through by force-creating an account, the automatic depreciation flow fails because the depreciation models generate a single yearly entry instead of monthly, and the depreciation/expense accounts have incorrect account types.

**Cause:**
* The chart of accounts had Accumulated Depreciation template accounts (e.g., `171.05.01`) set to `expense_depreciation` instead of `asset_non_current`, rendering them unavailable for the Accumulated Depreciation field.
* The Depreciation Expense accounts (e.g., `613.05.01`) were conversely set as `expense_direct_cost` instead of `expense_depreciation`.
* The main Fixed Asset accounts (e.g., `156.01.01`) were completely missing the explicit mappings for `asset_depreciation_account_id` and `asset_expense_account_id` within the CSV definition.
* The depreciation models in `account.depreciation.model-mx.csv` were configured with a `method_period` of `12`, resulting in yearly rather than standard monthly entries.

**Fix:**
* Modify `account.account-mx.csv` to convert all `171.xx/183.xx` accounts to `asset_non_current` and all `613.xx/614.xx` accounts to `expense_depreciation`.
* Introduce the `asset_depreciation_account_id` and `asset_expense_account_id` columns into the `account.account-mx.csv` file, properly linking each Fixed Asset account to its correct depreciation targets.
* Update `account.depreciation.model-mx.csv` to use a `method_period` of `1` (monthly) and convert the `method_number` logic from yearly durations to full month durations (12, 36, 60, and 120 months respectively) for creating accurately timed entries.

opw-6091214

Forward-Port-Of: odoo/odoo#259781

# How to reproduce
- Create 2 MO's A & B, both having the same product_id & bom_id
- Split MO A into two MO's A1 & A2
- Merge MO's A1 & B

# The issue
MO A2 no longer has a production group (visible via Studio).
If the user tries to partially produce the MO and create a backorder, a traceback popup appears with :

"ValueError: max() iterable argument is empty"

# Cause
The traceback is triggered because we use the `max()` function on `self.production_group_id.production_ids` when creating the backorder, but `production_ids` is an empty recordset since `production_group_id` is also empty.

https://github.com/odoo/odoo/blob/0d8eaeeb971f2f670aebb1b72ed03f4a2d5e0105/addons/mrp/models/mrp_production.py#L1936

The production group is empty because when merging two MO's we delete it without paying attention to other remaining links.

https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/mrp/models/mrp_production.py#L2555

Note : the production groups were introduced by this commit (https://github.com/odoo/odoo/commit/2713876dbc70d3984e584a9037a2206dcda4e84a)

# Proposed solution
When merging, we unlink the original MO's from their production group.
Then, we check every altered production group : if they are not linked to any MO anymore, we delete them.

opw-6055376

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

Forward-Port-Of: odoo/odoo#256600

### Description of the issue/feature this PR addresses: 
**Issue**: During KSeF authentication, some foreign qualified certificates causes a crash with error _"Failed to authenticate with XAdES: 400 Client Error: Bad Request for url: https://api.ksef.mf.gov.pl/v2/auth/xades-signature"_ This is due to Odoo not handling different `SubjectIdentifierType`

**Solution**: Implement a try/except block to safely check for the NIP in the certificate's subject string, defaulting the identifier type to `certificateFingerprint` when the NIP is missing or a ValueError is caught.

### Current behavior before PR:
The `SubjectIdentifierType` is hardcoded as `certificateSubject`, and does not handle `certificateFingerprint` at all. This causes there to be an error when trying to authenticate with the KSeF server using XAdES signature.

### Desired behavior after PR is merged:

The sign_authentication_challenge method will now safely evaluate the subject string. It assigns `certificateSubject` only if the NIP is verified to be in the subject string. If the NIP is absent or a ValueError occurs during parsing, the system safely falls back to using `certificateFingerprint`. This prevents tracebacks and ensures the correct XML payload is sent to the KSeF server.

Ticket [link](https://www.odoo.com/odoo/project.task/6125243)
opw-6125243

Forward-Port-Of: odoo/odoo#264851

### Description of the issue/feature this PR addresses:

The business premises label on Croatian invoices can legitimately contain alphanumeric characters (e.g., "v1"), as noted in the field's tooltip.

However, the regex pattern inside `_get_l10n_hr_fiscalization_number` used to extract the sequence parts strictly expected digits (`\d+`) for the premises label segment. Because of this, if an invoice was generated with an alphanumeric sequence like `INV-2026-0001/v1/1`, the regex failed to match and returned `False`, leading to a traceback when the system attempted to process the fiscalization number.

This commit updates the regex to correctly accept alphanumeric characters for the premises label, ensuring the sequence parses successfully.

opw-6129009

### Steps to reproduce:

- Settings > Users & Companies > Companies > New > set Address country to Croatia
- Select the newly created Croatian company
- Apps > Activate l10n_hr_edi module
- Accounting > Configuration > Accounting > Journals > click Sales journal > change “Business premises label” to “v1”
- Contacts > New > set Address country to Croatia
- Accounting > Customers > Invoices > New > select the newly created contact and choose any product > Confirm

### Current behavior before PR:

Traceback error when attempting to confirm an invoice when both the company and the customer have their country code set to 'HR'. This is because `_get_l10n_hr_fiscalization_number` does not accept alphabet characters in the premises label section of the regex.

### Desired behavior after PR is merged:

- No traceback error when confirming the invoice
- `_get_l10n_hr_fiscalization_number` correctly parses the fiscalization number

Forward-Port-Of: odoo/odoo#263650

Behavior before:
The import flow could crash with an "Expected singleton" error if multiple
journals shared an IBAN. Additionally, the system blindly accepted the
current context ('self') as the target journal, even if its currency or
bank account mismatched the statement, often leading to avoidable
UserErrors.

Behavior after:
The system now validates 'self' against the statement's currency and IBAN
before assignment. If a mismatch is found, it automatically searches for
the correct journal. The search is now restricted by currency and includes
a limit=1 to prevent crashes and ensure accurate selection.

Root Cause:
In _find_additional_data(), 'journal = self' was assigned without validation.
Furthermore, the fallback search lacked a record limit and currency matching
logic, allowing multiple records to be returned when duplicates or
multi-currency setups existed.

Fix:
- Added validation for the initial 'self' candidate (currency and IBAN match).
- Refined the search domain to include currency matching (journal or
  company fallback).
- Added limit=1 to the search to guarantee a singleton recordset.

opw-5462037

Forward-Port-Of: odoo/enterprise#117394
Forward-Port-Of: odoo/enterprise#115475

This commit stabilizes the tour flow by ensuring the sliding panel is
fully closed before proceeding to the next step.

Issue:
The tour steps selects a shape, which triggers [hideSlidingPanel]. That
function focuses a `BuilderButton` after a timeout.

This introduced a race condition: if the timeout executes before the
tour interacts with the `OverlayButtons`, the overlay gets hidden due to
the `focusin` event registered on the builder (outside the iframe) [1],
which ultimately hides the overlay buttons.

The issue made the tour undeterministic following commit [2], which
removed several intermediary steps between the shape selection and the
failing step.

Fix:
Wait for the sliding panel to fully close before continuing the tour
flow.

[hideSlidingPanel]: https://github.com/odoo/odoo/blob/saas-19.3/addons/html_builder/static/src/core/building_blocks/builder_sliding_panel.js#L73-L81
[1]: https://github.com/odoo/odoo/blob/saas-19.3/addons/html_editor/static/src/core/selection_plugin.js#L265
[2]: https://github.com/odoo/odoo/commit/fa328f4e1798a9547e9df749c4144478357e1764

runbot-[242702](https://runbot.odoo.com/odoo/error/242702)

Currently an error occurs when the user removes the Source Entity Id Type on Super Contributions.

**Steps to Reproduce:**
 - Install `l10n_au_hr_payroll_account` with demo data.
 - Switch to an `Australian` company.
 - Go to `Payroll` > `Reporting` > `Australia` > `Super Contributions`.
 - Open an existing record or create a new one.
 - Remove the `Source Entity Id Type` value and click anywhere.

`ValueError: Compute method failed to assign l10n_au.super.stream(<NewId origin=1>,).source_entity_id`

After [change] in the selection field behavior, when the user removes the Source Entity Id 
Type, the compute method is triggered to compute the Source Entity ID. However, the 
condition in the compute method is not match, so no value is assigned. As a result, 
the method fails and raises an error.

This commit ensures that if the condition is not match, the Source Entity ID is explicitly 
set to False.

[1]- https://github.com/odoo/enterprise/blob/9d523d7aabffda277e1ef734caf2b0e434545dca/l10n_au_hr_payroll_account/models/l10n_au_super_stream.py#L61-L65

[change]: https://github.com/odoo/odoo/pull/214422/changes/8d2a42ac419fdf7943a0c11beb8c5de6c6f85bef

Forward-Port-Of: odoo/enterprise#115466

When you open a contact, click the Opportunities smart button, then click New and open the Sales Team dropdown, archived sales teams show up in the list. The same thing happens for the user, tags and stage dropdowns. Creating an opportunity from the CRM app does not have this issue.

`res.partner.action_view_opportunity` sets `active_test: False` in the action context so archived opportunities show up in the list view. That context is passed down to the form opened from the action, and to every search the form runs to fill its dropdowns. So the dropdowns also return archived records.

The action's domain already has `('active', 'in', [True, False])`, which is enough to keep archived opportunities in the list on its own (the ORM only adds the "active = True" filter when `active` is not already in the domain). So we can just remove `active_test: False` from the context. This is what 18.0 was doing before https://github.com/odoo/odoo/commit/59feed9f26937ae8e2cab5cd7d2b6743ab6c0717 put the context flag back in.

The override in `website_crm_partner_assign` was setting `active_test: False` back on the action context for the same reason (so its extra search for assigned leads picks up archived ones). The flag is now applied locally on the `crm.lead` handle used for those searches, so archived leads are still found without polluting the action's context.

Steps to reproduce:
1. Archive a Sales Team in CRM > Configuration > Sales Teams
2. Open the Contacts app and pick any contact
3. Click the Opportunities smart button
4. Click "New" and open the Sales Team dropdown

=> Archived teams appear in the dropdown

Ticket [link](https://www.odoo.com/odoo/project.task/6134801)
opw-6134801

Forward-Port-Of: odoo/odoo#263283
Forward-Port-Of: odoo/odoo#261300

Steps to reproduce:
===================
1. Configure website with at least 1 language installed different from English. ex: English and French.
2. As anonymous user, change wehbsite language and make a donation via the donation snippet.
3. Check the outgoing confirmation email.

=> Email body is rendered in English.

Cause:
======
The donation confirmation email rendered with `self.partner_id.lang`. For anonymous donors, `partner_id` is the website's shared public user partner, so every anonymous donor received the email in whatever language was set on that partner (or English if unset), regardless of the language they were browsing in.

Solution:
=========
`payment.transaction` already has a `partner_lang` field auto-filled from `partner.lang` at creation.
- override it in the `/donation/transaction` controller with `request.env.lang`
when the public partner is used, capturing the request language at donation time (also works later from `_cron_post_process`, which has no request context);
- render `_send_donation_email` using `self.partner_lang` instead of `self.partner_id.lang`.

opw-5875338


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

Forward-Port-Of: odoo/odoo#264657
Forward-Port-Of: odoo/odoo#259351

The combined query for sale.commission.achievement.report originally performs several bitwise shifts, starting with the max AML ID. This is done to create a composite number ID for the combined IDs.

`MAX(aml.id)::bigint <<20) | max(rules.id)::bigint <<10 | rules.user_id <<10`

This shifts the max aml.id 40 bits to the left.

Example:
Let's say MAX(aml.id) = 1; we will set the other variables to 1, as they often have little impact on the total size of the number.

1 << 20 = 1048576
1048576 | 1 = 1048577
1048577 << 10 = 1099512676352
1099512676352 | 1 = 1099512676353
1099512676353 << 10 = 1152922604119523328

With this format, the highest guaranteed AML ID this query can handle is under 838,861.

The last 10-bit shift is unnecessary and increases the result. If we remove the last shift, the AMD ID this query can handle becomes much higher.

`MAX(aml.id)::bigint <<20) | max(rules.id)::bigint <<10 | rules.user_id`

|  | AML Max | RULES.ID Max |RULES.USER_ID Max|
| --------------------- | ------ | ------ |  ------ | 
| Before | 838,861  | 1,048,576 | 1,024 |
| After | 858,993,459 |1,048,576 | 1,024|

opw-6124026

Forward-Port-Of: odoo/enterprise#114711

## Issue
When making a request for quotation for a subcontracted product and returning the delivery "for exchange", the new incoming delivery does not have the correct destination. Instead of having the stock of the user, the destination of the new incoming delivery is the same as its source: the subcontracting location.

<img width="1254" height="257" alt="5479900" src="https://github.com/user-attachments/assets/c7e6d392-8328-4a03-a71e-466e768f448b" />

## Steps to reproduce
1. Install MRP Subcontracting (`mrp_subcontracting`) and Purchase (`purchase`)
2. In Settings, enable *Subcontracting*
3. Create a Product P and a subcontracting BoM with Subcontractor S
4. Create a Request for Quotation
    - Vendor: Subcontractor S
    - Product: Product P (any quantity > 0)
5. Confirm the RFQ, receive the PO, validate the picking
6. On the validated picking, click *Return*, set the quantity of products to return, and click *Return for Exchange*
    - This creates two new pickings, one to return the product(s) we received, and one to receive new products
7. Validate the two new pickings
8. **In Inventory > Reporting > Moves History, the very last `stock.move.line` has the same location in the *From* (`location_id`) and the *To* (`location_dest_id`) columns**

## Cause
The `location_dest_id` of the new `stock.move` is updated in `StockReturnPickingLine._prepare_move_default_values`.

https://github.com/odoo/odoo/blob/fb534f1eadcb8ef74e2ee6fd5b68872dddb978e3/addons/mrp_subcontracting/wizard/stock_picking_return.py#L20-L25

The condition added by https://github.com/odoo/odoo/commit/5404b426aac9 sets the destination of all returned subcontracted moves to the subcontractor location. This is incorrect when using "return for exchange", as in this case, the return move is directed towards the user's stock. In fact, when using "return for exchange", the following pickings are created:

| id | name         | return_id |   |
|:--:|--------------|:---------:|---|
| 1  | WH/IN/00001  |           | Initial RFQ delivery |
| 2  | WH/OUT/00001 |     1     | Return of the initial RFQ delivery |
| 3  | WH/IN/00002  |     2     | New products delivery to replace the initial delivery. The stock.move.line of this stock.picking has a wrong `location_dest_id` |

## Fix
In the context of return for exchanges, the returned item must be directed to the *Subcontracting Location* while the new item must be directed to   the *Stock*. In the `_prepare_move_default_values`, we should only set   the `location_dest_it` to the subcontractor location for outgoing pickings.

opw-5479900

Forward-Port-Of: odoo/odoo#265071
Forward-Port-Of: odoo/odoo#245905

**Problem:**
When a project analytic budget is revised, the project update description shows an inflated total budget — the sum of both the original and the revised amounts — instead of reflecting only the active (confirmed) revision.

**Steps to reproduce:**
1. Create a project with an analytic account
2. Create an analytic budget of $10,000 and confirm it
3. Create a revision of that budget for $15,000 and confirm it
4. Create a new project update
5. The update shows "$25,000" as the total budget instead of "$15,000"

**Current behavior:**
The project update displays the sum of all budget revisions ($25,000), regardless of their state.

**Expected behavior:**
Only the active confirmed budget ($15,000) should be used.

**Cause of the issue:**
`_compute_budget` queries all `budget.line` records matching the project's analytic account without filtering by the parent `budget.analytic` state. When a budget is revised, the original transitions to state `revised` while the new one becomes `confirmed`. Because `_compute_budget` has no state filter, it sums both, producing an inflated `total_budget_amount`. This field is then used in the project update template to compute the displayed budget total and percentage. By contrast, `_get_budget_items` — used for the detail rows — already applies `state in ['confirmed', 'done']`, so the two methods were inconsistent.

**Fix:**
Applying the same state filter to `_compute_budget` as already present in `_get_budget_items` ensures both methods draw from the same set of active budgets, keeping the project update totals consistent with the budget detail rows.

opw-6128855

Forward-Port-Of: odoo/enterprise#117490
Forward-Port-Of: odoo/enterprise#115285