**Steps to reproduce:**
* Install the *Accounting* module with French localization (*l10n_fr_account*).
* Create a *Sales Tax* with:
  * A new tax group (e.g., 'Codifab').
  * Enable *Affect Base of Subsequent Taxes*.
* Create a *Sales Order*:
  * Add the first tax (with *Affect Base of Subsequent Taxes*).
  * Then add the second tax (eg VAT tax).
* Confirm the *Sales Order*.
* Create a *Down Payment Invoice* (percentage-based).
* Open the generated invoice and:
  * Remove the first tax (the one affecting the base).

**Observed behavior:**
* The amount of the second tax group does not update after removing the first tax, leading to incorrect tax computation.

**Cause:**
* In `_import_base_line_extra_tax_data`, the condition: `all(str(tax.id) in extra_tax_data['manual_tax_amounts'] for tax in sorted_taxes)` only ensured partial matching of taxes.
* This allowed reuse of stale `manual_tax_amounts` when taxes were removed or modified, causing incorrect base values for dependent taxes (e.g., *Affect Base of Subsequent Taxes*).

**Fix:**
* Update the condition to enforce an exact match between current taxes and cached `manual_tax_amounts` by checking both size and membership.
* Prevent reuse of outdated tax data when taxes change, ensuring proper recomputation of dependent taxes.
* Align Python logic with the JS implementation for consistency between `account_tax.py` and `account_tax.js`.

opw-6063970

Forward-Port-Of: odoo/odoo#264434
Forward-Port-Of: odoo/odoo#259566

- Attendance checkout
    - Step to reproduce: with attendance installed and an employee checked in, archive that employee by HR user. If missing attendance rights, the employee will be archived but not checked out from its ongoing attendance.
    - Cause: if no role set for Attendance (default), no permission to update the employee attendance while archiving.
    - Solution: using sudo method so that any user with sufficient rights to archive an employee, can trigger check out of the corresponding attendance.

- Planning access error (fixed in 18.0 by https://github.com/odoo/odoo/pull/219395)
    - Step to reproduce: with attendance and planning installed, archive an employee having planning slots. If missing planning rights, an access error is raised
    - Cause: on employee archive, the corresponding planning.slots are updated and some fields recomputed with insufficient rights.
    - Solution: using sudo method for recompute.

Task: 6131692

Forward-Port-Of: odoo/odoo#264518
Forward-Port-Of: odoo/odoo#260566

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

Currently, an incorrect VAT format is used in the generated `FA3 XML`
for non-Polish partners, where the VAT number includes the country code.

**Steps to reproduce:**
- Install the `l10n_pl_edi` module and switch to a `PL Company`.
- Go to Settings and enable `Allow KSeF integration` (refer to [1]).
- Create and confirm an invoice for a customer (e.g., Azure Interior).
- Send the invoice using `by KSeF (e-Faktura)`.

**Observation:**
In the generated XML file, the `NrID` field contains the VAT number 
`with the country code` for non-Polish partners.

**Root Cause:**
At [2], `get_vat_number` sets the VAT number using `compact` from 
`stdnum.pl.nip`, which only works for Polish VAT numbers.

At [3], `get_vat_number` correctly formats Polish VAT numbers without 
the country code in the `if condition`. However, in the fallback (else) case, 
it returns the VAT number as it is, including the country code.

**Fix:**
This commit ensures that for non-Polish VAT numbers, the country code is 
removed before setting the `NrID` or `NrVatUE` values in the XML, 
aligning the format with KSeF requirements.

Ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf (Page no.: 19)

[1]:
https://www.odoo.com/mail/message/1057847327

[2]:
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/l10n_pl_edi/models/account_move.py#L257

[3]:
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/l10n_pl_edi/data/fa3_template.xml#L67-L82

opw-6120118

Forward-Port-Of: odoo/odoo#263081

**Steps to reproduce in runbot:**
1. Install hr_holidays_attendance.
2. Create an employee with a contract start date (e.g., April 1st).
3. Set the timezone(for both user and emp working schedule) to Europe/Brussels.
4. Create an attendance record (e.g., April 15th).
5. Go to Reporting > Time Off Ledger and remove all filters.
 -> Attendance is correctly shown for all dates from April 1st
6. Create a public holiday on April 16th starting at 00:00.
7. Check the Time Off Ledger again.

**Issue:**
The attendance entry for April 15th disappears after adding the public holiday.

**Cause:**
Calendar leave datetime fields (date_from/date_to) are stored in UTC but compared against attendance dates without converting to the employee's resource calendar timezone, causing date boundaries to shift and records to be incorrectly excluded.
https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_holidays_attendance/report/hr_leave_attendance_report.py#L133-L144

**Solution:**
Convert calendar leave datetimes to the resource calendar timezone before casting to date, ensuring comparisons reflect the correct local boundaries.

**NOTE:**
This issue is mainly reproducible on runbot since its server timezone is
GMT. On local machines configured with UTC, the stored datetime values
already align with the expected conversions, so the date shift does not occur.


opw-6118043




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

Forward-Port-Of: odoo/odoo#262179

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

__
## Short functional explanation of the error
When setting attendances on several consecutive days for a flexible employee, with an overtime ruleset containing a single rule. This rule being based on week and quantity.
When regenerating overtimes for this ruleset, the overtime hours generated isn't correct.

## Reproduction Steps
1. Create an employee. In the Payroll tab, set a start date for their contract. Set Work Entry Source as Attendances. Set their Working Hours as a flexible schedule. Set their weekly hours at 40.
2. Create an Overtime Ruleset. Add a single rule, based on Quantity, if the worked hours on a `Week` differs `from the amount defined on the contract`. Check Pay Extra Hours and leave the Work Entry Type to use as Overtime Hours.
3. Go back to the employee. In Settings, set the Overtime Ruleset field as the new Overtime Ruleset you just created.
4. Create 5 attendances, each from 8 am to 6 pm, from Monday to Friday.
5. Go to the Overtime Ruleset you just created and click on Regenerate Overtimes.
6. Go back to Attendances. Search for your employee, and click on the list view.

### Expected behavior
The employee's schedule is 40 hours per week. They worked 50 hours. 10 hours should be considered as Worked Extra Hours.

### Unexpected behavior
18 hours are considered as extra hours.

## Origin of the issue
To compute the expected duration of the day, we run: https://github.com/odoo/odoo/blob/7fc5edc29f854d619dbcb5fcc3503fb18ca05335/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L303-L304 where `schedule['work']` will contain intervals on 5 consecutive days, from 8 am to 4 pm.
However, the last day of the employee's attendances isn't contained in these intervals. As a result, `period_schedule` will contain 4 days (the common days between the employee's Attendance days and `schedule['work']` ) and thus, `expected_duration` will be set at 36 hours instead of 40.
In the case where overtimes are computed based on hours from the 
contract, for flexible employees, the expected hours are the ones
indicated on their schedule.

__
opw-6131543

Forward-Port-Of: odoo/odoo#263335

### Steps to reproduce:
- Download 'Sales', 'Accounting', and 'l10n_sa_edi' modules
- Settings > Accounting > Rounding Method > Enable global rounding
- Create sale order with 8 lines at 29.7 each with 15% taxes (triggers rounding precision issues)
- Create and confirm 100% downpayment invoice
- Deliver, then create final invoice with downpayment lines
- Call `_l10n_sa_get_prepaid_amount()` on final invoice
> Tax amount was calculated as 35.67 instead of correct 35.64

### Cause of Issue:
The prepaid amount calculation was summing pre-rounded `tax_amount_currency` values from individual downpayment lines (4.45 + 4.46 + 4.46... = 35.67), instead of summing unrounded `raw_tax_amount_currency` values (4.455 × 8 = 35.64) to calculate `tax_amount`. https://github.com/odoo/odoo/blob/27930ae41a5f03bd499983109de7f632472c3650/addons/l10n_sa_edi/models/account_edi_xml_ubl_21_zatca.py#L227-L240

This violates Odoo's [recent change](https://github.com/odoo/odoo/pull/180062) in `round_globally` pattern which states:
https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/account/models/account_tax.py#L2208

### Fix:
Ensure cumulative rounding errors are avoided and correct global rounding is applied.

opw-5881564

Forward-Port-Of: odoo/odoo#264713
Forward-Port-Of: odoo/odoo#261278

## 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#264798
Forward-Port-Of: odoo/odoo#245905

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

Steps to Reproduce:
---
1. Create a new project.
2. Convert it into a template.
3. Click on "Undo".
4. Try to convert the project into a template again.

Issue:
---
After undoing the template conversion, the project's original documents folder
remained archived while the template's documents folder stayed active. This
inconsistent state prevented subsequent template creation from the same project.

Current behaviour:
---
A UserError is raised: "You cannot duplicate document(s) in the Trash."

Expected behaviour:
---
Undoing the template conversion should properly restore the original project's
documents folder to active state and clean up the template's documents folder,
allowing template conversion again without document folder conflicts.

Fix:
---
- Archive original project's documents folder during template creation to
prevent mixed active/inactive states during copy operations
- Implement callback system to properly unarchive original project's
documents folder during undo

task-4916027

Forward-Port-Of: odoo/odoo#264429
Forward-Port-Of: odoo/odoo#223152

When computing `qty_to_order` 1-3 extra queries are made by `get_lead_days()`, which can cause performance issues when computing `qty_to_order` for a large number of orderpoints.

This commit aims to prevent these extra queries by returning early if the current product is not associated with a bom. The amount this commit speeds up the compute depends on how many of products passed into `_get_lead_days()` are associated with a bom.

`qty_to_order` is no longer a stored field after this commit: https://github.com/odoo/odoo/pull/159432
This benchmark was done in 18.0 on /stock.warehouse.orderpoint/search_panel_select_range. This call does not trigger the compute on all orderpoints in 17.0 as the field is stored but calling the compute directly on all orderpoints results in the same speed up as seen in 18.0.

| Orderpoints | % of products linked to a bom | Time before | Queries before | Time after | Queries After |
|-------------|-------------------------------|-------------|----------------|------------|---------------|
|         800 | 50%                           | 2.8s        |           1570 | 2.3s       |           818 |
|       8,000 | 0%                            | 28.2s       |         16,698 | 15.3s      |           242 |
|       8,000 | 25%                           | 29.6s       |         16,833 | 19.2s      |          4497 |
|       8,000 | 50%                           | 29.8s       |         16,925 | 23.2s      |          8693 |
|       8,000 | 75%                           | 31.6s       |         16,949 | 27.6s      |         12827 |

Forward-Port-Of: odoo/odoo#262321

__

## Short functional explanation of the error
When for an employee with a Flexible schedule, we set a shift overlapping on two days. The attendance report displays twice the worked hours.

## Reproduction Steps
1. Create an employee with a flexible schedule and with Work Entry Source set at Planning.
2. Go to Planning. Create a Planning Slot for this employee from 9 pm to 5 am, then Send and Publish it.
3. Click on the Reporting tab > Planning / Attendance Analysis.

### Expected behavior
The total for this Month for this employee under the Planned Time field should be equal to 8 hours, which is the duration of the planning slot.

### Unexpected behavior
The total for this Month for this employee under the Planned Time field is equal to 16 hours.

## Origin of the issue
This report is a view, for which the SQL is defined starting this line: https://github.com/odoo/enterprise/blob/7362f1c5be7f496bdab660ed8fad37a6dd283616/planning_attendance/report/planning_attendance_analysis_report.py#L27 the issue stems from here:
https://github.com/odoo/enterprise/blob/7362f1c5be7f496bdab660ed8fad37a6dd283616/planning_attendance/report/planning_attendance_analysis_report.py#L56 where we don't select distinct the planning entries based on their ID. As our shift overlaps 2 days, there will be only one entry for this shift in the `planning_slot`, but because of that, it will be duplicated.

__
opw-6146052

Forward-Port-Of: odoo/enterprise#115447