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

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

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)

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

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

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

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 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 employee 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

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

# 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

Issue:
------
`l10n_br.address_form_fields` inherits from `portal.address_form_fields` but targets a `<select>` element that was moved to `portal_address_extended.address_extended_form_fields` in [saas~19.2].

Traceback:
----------
```py
Error while parsing or validating view:

Element '<xpath expr="//select[@name=&#39;city_id&#39;]/option[not(@value=&#39;&#39;)]">' cannot be located in parent view
```

Steps to reproduce:
-------------------
1. Install `l10n_br` in v19
2. Upgrade to v19.2
3. Upgrade the `l10n_br` module →  Traceback

Root cause:
-----------
The view is adapting an element owned by a sibling view, making the inheritance hierarchy conceptually wrong and fragile.

Solution:
---------
Update the `inherit_id` of `l10n_br.address_form_fields` to `portal_address_extended.address_extended_form_fields` so it correctly inherits from the view that owns the targeted element.

opw: [6125901]

[saas~19.2]: https://github.com/odoo/odoo/commit/026c6f9f2a388ee509a135c53e38f5bb3d08ff73
[6125901]: https://www.odoo.com/odoo/70/tasks/6125901?debug=1

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

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

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

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

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

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

# 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

Currently, an error occurs when a user selects a shift template on a planning slot.

**Steps to Reproduce:**

 - Install the `Planning` module with demo data.
 - Create a `Resource Time Off` record with `start` and `end date` separated by more than 
  `1400 days (around 3.9 years)`, and Set the Working Hours field to Standard 40 hours/week.
 - Go to `Planning` > `Configuration` > `Shift Templates`, open an `existing record` or create 
   a `new one`, and set the `Working Days` to more than 1 day.
 - Create a new `planning slot`, Assign the resource `Abigail Peterson`, and select the above 
   `shift template`.

`AttributeError: 'bool' object has no attribute 'replace'`

This error occurs because when the user sets the shift template, the compute method runs to 
calculate the start and end datetimes [1]. It computes the end datetime by adding the template 
duration in working days from the given start datetime using the resource working calendar within 
a searchable range of around 1400 days [2]. During this computation, leaves and non-working days 
are skipped [3]. If no valid working interval is found within the searchable range, then it returns 
False [4], which raises the error [5].

This commit ensures that if plan_days returns False, the computation falls back to the previously 
calculated end date.

[1]: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/planning/models/planning.py#L662-L671

[2]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L826-L835

[3]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L533-L537

[4]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L835

[5]- https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/planning/models/planning.py#L653-L654

sentry-7472958590

Forward-Port-Of: odoo/enterprise#117073

When generating a VAT return with an unclaimed tax amount carried to the
next month, the carryover reimbursement move amounts are computed with
an incorrect ratio.

Steps to reproduce:
- Create and post a bill in May containing a VAT amount.
- Create and post a bill in June containing a VAT amount.
- Create a VAT return for May to carry over the VAT amount to the next
  month.
- Create a VAT return for June, requesting the full VAT amount to be
  reimbursed.
- Validate and send the June VAT return.
- Check the generated reimbursement move

Issue: Line values does not correspond to anything real/tangible.  It
occurs because when computing the ratio for the move we check the last
tax report entry, where we find the amount of tax from the past months
and a line balancing the last month that should not be taken into
account.  The "Balance tax current account (receivable)" line from the
tax closing entry is mistakenly picked up as a tax carried forward line,
throwing off the amounts.

opw-5961836

Forward-Port-Of: odoo/enterprise#116930
Forward-Port-Of: odoo/enterprise#115451

__

## Short functional explanation of the error
When checking the dashboard on a project we created with a yearly subscription, the values shown are incorrect.

## Reproduction Steps
1. Create a new product. Check the Subscription field and set the Product type as Service. On the Create on Order field, set Project & Task. Then, in the Recurring Price tab, add a Monthly plan with price 50 and yearly plan with price 40.
2. Create a new Quotation. Set a customer and add the product you just created in an Order line. Set the Quantity to 100 and set the recurring plan as Yearly. You'll see the amount be at 4000, and the total amount at 4600 with taxes. Click on Confirm.
3. Create an invoice and confirm it.
4. Click on the Project smart button. Then, on the top right, click on the view menu > Top Menu. Select Dashboard and click on it.

### Expected behavior
On the dashboard, we should see the Revenues under Profitability at 4000. To invoice should be left at 0 and Invoiced should be at
4000. Expected should be at 4000.

### Unexpected behavior
On the dashboard, To Invoice is at 333, and Expected is at 4333. This corresponds to our invoice + 4000/12 -> monthly recurring plan, with the price of the yearly plan!

## Origin of the issue
We always add the `recurring_monthly` value when showing the profitability, no matter the recurring plan:
https://github.com/odoo/enterprise/blob/cdc0d5d57f6b27a6bb5e451d48bdbef4e3dde5cb/project_sale_subscription/models/project_project.py#L86
We should only add the `recurring_monthly` value for as many monthly
subscriptions we have, not for *all* the subscriptions.
__
opw-5916688

Forward-Port-Of: odoo/enterprise#113918

Steps to reproduce:
===================
1. Go to the shop page and use the rental date picker to select a start and end date with hours.
2. Find a rental product configured with "Days" pricing.
3. Add to card directly from the product card
4. Add a rental product from product image that has date type value date
5. Go to that product details page.
6. Click add to cart

-> Invalid operation, You cannot mix different rental periods...

Cause:
======
When adding a product from the shop list view, the system uses the default start/end dates (from the rental period) exactly as first added.

However, the "Add to Cart" logic on the product details page attempts to adapt the selected dates to the product's specific rental unit (e.g., normalizing the time component for 'Day' pricing).

This re-calculation creates a timestamp mismatch between the item already in the cart (from the shop view) and the new item being added (from the details page).

Solution:
=========
The add-to-cart flow has been updated to correctly utilize the default duration values (the globally selected dates) if they exist.

opw-5450576

Forward-Port-Of: odoo/enterprise#103373

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

Currently, an error occurs when a user selects a shift template on a planning slot.

**Steps to Reproduce:**

 - Install the `Planning` module with demo data.
 - Create a `Resource Time Off` record with `start` and `end date` separated by more than 
  `1400 days (around 3.9 years)`, and Set the Working Hours field to Standard 40 hours/week.
 - Go to `Planning` > `Configuration` > `Shift Templates`, open an `existing record` or create 
   a `new one`, and set the `Working Days` to more than 1 day.
 - Create a new `planning slot`, Assign the resource `Abigail Peterson`, and select the above 
   `shift template`.

`AttributeError: 'bool' object has no attribute 'replace'`

This error occurs because when the user sets the shift template, the compute method runs to 
calculate the start and end datetimes [1]. It computes the end datetime by adding the template 
duration in working days from the given start datetime using the resource working calendar within 
a searchable range of around 1400 days [2]. During this computation, leaves and non-working days 
are skipped [3]. If no valid working interval is found within the searchable range, then it returns 
False [4], which raises the error [5].

This commit ensures that if plan_days returns False, the computation falls back to the previously 
calculated end date.

[1]: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/planning/models/planning.py#L662-L671

[2]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L826-L835

[3]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L533-L537

[4]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L835

[5]- https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/planning/models/planning.py#L653-L654

sentry-7472958590

Forward-Port-Of: odoo/enterprise#117073

**Steps to reproduce:**
- Create a company in Belgium and set the fiscal localisation accordingly.
- In the same company, create a fiscal position in Switzerland, set the foreign tax ID and then generate the taxes for it.
- Install the module account_edi_ubl_cii.
- Create and invoice for a belgian customer, with one product line having a 0% tax.
- Export the invoice as XML.
- Go to taxes, filter by purchase, and make sure that the 0% switzerland tax has a higher sequence than the belgian 0% tax.
- Import the previous invoice XML as a vendor bill.

**Issue:**
After importing the bill, the switzerland tax is used even though the fiscal localisation is belgian, which is wrong as it violates the constraint _validate_taxes_country

**Solution:**
Added a more selective domain to _import_fill_invoice_line_taxes

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

Forward-Port-Of: odoo/odoo#263560
Forward-Port-Of: odoo/odoo#255848

When selling event tickets in POS while offline, the order could be synced later but without creating event registrations (tickets) after a page reload.

Steps to reproduce:
-------------------
* Open a POS session with `pos_event`
* Sell an event ticket
* Switch to offline mode
* Validate payment while offline (order becomes paid but unsynced)
* Reload/close and reopen POS, then reconnect
* Let the order sync

> Observation:
The `pos.order` is created on the backend, but `event.registration` and `event.registration.answer` are missing so tickets are not generated.

Why the fix:
------------
`pos_event` used `order.finalized` as IndexedDB cleanup condition for `event.registration` and `event.registration.answer`. For paid-but-unsynced orders, `finalized` is already true, so those records can be removed from IndexedDB too early. After reload, the order is restored/synced but without its event registration payload.

Implementation:
---------------
Use `order.canBeRemovedFromIndexedDB` instead of `order.finalized` for `event.registration` and `event.registration.answer` retention rules, so records are kept locally until the order is truly synced (server id assigned) or canceled.

Test Note:
---------------
Use case is hard to simulate exactly.
Add a basic unit test to assert both registration models are kept for paid unsynced orders and only removable once synced.

opw-6056079

Forward-Port-Of: odoo/odoo#263912
Forward-Port-Of: odoo/odoo#256615

**Steps to reproduce:**
- Install Accounting and Point of Sale

- In Accounting settings, activate "AvaTax"
- Configure the AvaTax fiscal position and activate "Detect Automatically" option
- Make sure that the other fiscal positions don't have that option set or that they are ordered after the AvaTax one

- Go to the settings of a point of Sale
- Activate "Flexible Taxes" and configure "Default" and "Allowed"
- Make sure that AvaTax fiscal position is not allowed
- Do not activate "AvaTax PoS Integration"

- Open a POS session
- Select a customer with an address in the US and without fiscal position
- Check the fiscal position

**Issue:**
The selected fiscal position is the AvaTax one even though AvaTax is not activated in the POS.

**Cause:**
We force the use of a fiscal position if it is configured on a customer.
In this case, as no fiscal position is configured on the customer, we try to retrieve one that matches the condition and the AvaTax one is selected.

**Solution:**
When searching for the fiscal position of a customer, if AvaTax is not configured in the POS and if its fiscal positions are not allowed in POS, we ignore the fiscal positions using AvaTax.

opw-6154089




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

**Steps to reproduce:**
- Install Accounting and Point of Sale

- In Accounting settings, activate "AvaTax"
- Configure the AvaTax fiscal position and activate "Detect Automatically" option
- Make sure that the other fiscal positions don't have that option set or that they are ordered after the AvaTax one

- Go to the settings of a point of Sale
- Activate "Flexible Taxes" and configure "Default" and "Allowed"
- Make sure that AvaTax fiscal position is not allowed
- Do not activate "AvaTax PoS Integration"

- Open a POS session
- Select a customer with an address in the US and without fiscal position
- Check the fiscal position

**Issue:**
The selected fiscal position is the AvaTax one even though AvaTax is not activated in the POS.

**Cause:**
We force the use of a fiscal position if it is configured on a customer.
In this case, as no fiscal position is configured on the customer, we try to retrieve one that matches the condition and the AvaTax one is selected.

**Solution:**
When searching for the fiscal position of a customer, if AvaTax is not configured in the POS and if its fiscal positions are not allowed in POS, we ignore the fiscal positions using AvaTax.

opw-6154089

### Issue:
When importing EDI documents such as Peppol files, Swiss VAT numbers are often provided in a flat format (e.g., CHE530781296TVA), while existing Odoo partners usually store them in the official formatted version (e.g., CHE-530.781.296 TVA)

This mismatch prevents proper partner matching and may create duplicate partners during import

### Cause:
`_retrieve_partner` lacks Swiss-specific VAT normalization logic in `_import_retrieve_customer_from_vat()`
As a result, the matching process fails to:
- match formatted and unformatted Swiss VAT numbers
- properly handle language suffixes such as `TVA`, `MWST`, or `IVA`

If `base_vat` is installed, and the imported XML VAT is `CHE530781296TVA`, a new partner will be created with the structure format  `CHE-530.781.296 TVA`
As the match won't be made new partner will be created at each import

### Steps to reproduce:
- Install `account`
- Create a Vendor (Name: Test CH Vendor, Country: Switzerland, Tax ID: CHE-530.781.296 TVA)
- Import the bill [CH_bill_to_import.xml](https://github.com/user-attachments/files/27202997/CH_bill_to_import.xml) from the ticket 

Before the fix, the existing partner is not matched and a duplicate partner is created

opw-6072239

### Issue:

The `Print Label`, `Register Production`, `Register By-products`and `Register Consumed Materials` are all available in the test types at control point creation.

### Expected behavior:

These test types are only meant for manufacturing operations and are supposed to be hidden by the field domain:
https://github.com/odoo/enterprise/blob/f56aa85b4ad32c5d9ad5593df1366d72e88da0e4/mrp_workorder/models/quality.py#L102-L104 https://github.com/odoo/enterprise/blob/00d6cccd75c402378698a6fd11ee2692f2361c7f/mrp_workorder/models/quality.py#L20-L24

### Cause of the issue:

Since saas-18.1: 5ef007a2116e528b796ebe80fb291ba5f1a94c8f domains are optimised into equivalents SQL clause with better sql performances. This optimization results in the following match for boolean fields: 
`('field', '=', True)` -> `('field', 'in', OrderedSet([True]))` 
`('field', '=', False)` -> `('field', ' not in', OrderedSet([True]))`
Because of these:
https://github.com/odoo/odoo/blob/82b16e8feb3d60a9a3855e3adb3164ae5a6c041d/odoo/orm/domains.py#L1058-L1079 https://github.com/odoo/odoo/blob/82b16e8feb3d60a9a3855e3adb3164ae5a6c041d/odoo/orm/domains.py#L1215-L1236
Now the issue is that the specific `search_method` of the `allow_registration` field is then called with this optimized domain: https://github.com/odoo/odoo/blob/82b16e8feb3d60a9a3855e3adb3164ae5a6c041d/odoo/orm/domains.py#L860-L866 https://github.com/odoo/enterprise/blob/00d6cccd75c402378698a6fd11ee2692f2361c7f/mrp_workorder/models/quality.py#L20-L24
And since `value` is defined as a non empty ordered set in both cases it the search method returns a True leaf as search domain.

opw-5915197

**Issue**
Reducing the PO quantity after performing a partial receipt, in multi-step receipts warehouse
can incorrectly update the remaining receipt quantity.

**Steps to reproduce**
- Setup 2-route receipt warehouse (Inventory > Configuration > Warehouse Management > Warehouses)
- Create a PO for 35 units and confirm it
- Click on receive products, set received quantity to 10 and create a backorder
- Validate the next transfer
- Go back to the PO and change the quantity to 20
- Check the receipt demand
-> The backorder picking demand become 35 instead of 10

**Cause**
Updating the quantity of a purchase order line, also updates the related picking:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L120
It updates the picking associated to the backorder since the other one is done:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L185-L187
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L197
This ultimately calls:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L228
To compute the new demand for the picking, it retrieves the `move_dest`:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L240
To compute `qty_to_push`:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L247-L249
However, since we are in a 2-route receipt setup, `move_dest` is the move from Input to stock for the done picking.
Thus, `qty_to_push` is `20 - 10 = 10` instead of `20 - 35 = -15`

**Solution**
The previous logic assumes a pull flow, where downstream (move_dest_ids) quantities are always up-to-date and can be used as the source of truth to recompute demand.
In push flows (e.g., multi-step receipts), this assumption does not hold. 
To fix this, we instead base the computation on the quantity of the current moves (qty) if nothing has to be attached. 

**Additional information**
Known limitation: this does not address inconsistencies in return flows. When there're returns, units 
define in the pol and the one define in the sum of the picking can diverge, thus this pr won't fix that.

opw-5512172

Forward-Port-Of: odoo/odoo#263294
Forward-Port-Of: odoo/odoo#248626

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

opw-6125243

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

Forward-Port-Of: odoo/odoo#265390

Currently, an error occurs when a user selects a shift template on a planning slot.

**Steps to Reproduce:**

 - Install the `Planning` module with demo data.
 - Create a `Resource Time Off` record with `start` and `end date` separated by more than 
  `1400 days (around 3.9 years)`, and Set the Working Hours field to Standard 40 hours/week.
 - Go to `Planning` > `Configuration` > `Shift Templates`, open an `existing record` or create 
   a `new one`, and set the `Working Days` to more than 1 day.
 - Create a new `planning slot`, Assign the resource `Abigail Peterson`, and select the above 
   `shift template`.

`AttributeError: 'bool' object has no attribute 'replace'`

This error occurs because when the user sets the shift template, the compute method runs to 
calculate the start and end datetimes [1]. It computes the end datetime by adding the template 
duration in working days from the given start datetime using the resource working calendar within 
a searchable range of around 1400 days [2]. During this computation, leaves and non-working days 
are skipped [3]. If no valid working interval is found within the searchable range, then it returns 
False [4], which raises the error [5].

This commit ensures that if plan_days returns False, the computation falls back to the previously 
calculated end date.

[1]: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/planning/models/planning.py#L662-L671

[2]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L826-L835

[3]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L533-L537

[4]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L835

[5]- https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/planning/models/planning.py#L653-L654

sentry-7472958590

Forward-Port-Of: odoo/enterprise#117073

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

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

### *Why this commit*: 
---
Ensures Quality Checks Shop Floor regardless of the "Auto-close Production" setting.

### *Steps to Reproduce*
---
1. Define a product tracked by Serial Numbers with a Manufacturing BoM.

2. Create a Quality Control Point for the product on the Manufacturing
operation.

3. In Inventory Configuration, disable "Auto-close Production" on the
Manufacturing operation type.

4. Create a Manufacturing Order (MO) and open it in the Shop Floor view.

5. If the MO has no operations, try to use Mass Produce.

### *Before this PR*
---
When auto_close_production was set to False, the Shop Floor card footer
incorrectly hid  the Quality Checks button.
This blocked users completing mandatory
quality check steps.



### *After this PR*
---
The visibility logic for Shop Floor actions is now decoupled from the closing
permission. The workflow follows this corrected sequence:

Quality Checks: Remain accessible to ensure all mandatory tests are
passed before production progresses.

Close Production: Only appears if "Auto-close Production" is enabled
on the operation type.

Mass Produce: allow serial registration and backorder
creation even if the MO cannot be closed from the Shop Floor.


OPW: 5473839

Forward-Port-Of: odoo/enterprise#103926

**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#116670
Forward-Port-Of: odoo/enterprise#115285

When generating a VAT return with an unclaimed tax amount carried to the
next month, the carryover reimbursement move amounts are computed with
an incorrect ratio.

Steps to reproduce:
- Create and post a bill in May containing a VAT amount.
- Create and post a bill in June containing a VAT amount.
- Create a VAT return for May to carry over the VAT amount to the next
  month.
- Create a VAT return for June, requesting the full VAT amount to be
  reimbursed.
- Validate and send the June VAT return.
- Check the generated reimbursement move

Issue: Line values does not correspond to anything real/tangible.  It
occurs because when computing the ratio for the move we check the last
tax report entry, where we find the amount of tax from the past months
and a line balancing the last month that should not be taken into
account.  The "Balance tax current account (receivable)" line from the
tax closing entry is mistakenly picked up as a tax carried forward line,
throwing off the amounts.

opw-5961836

Forward-Port-Of: odoo/enterprise#116822
Forward-Port-Of: odoo/enterprise#115451

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

Currently, an error occurs when a user selects a shift template on a planning slot.

**Steps to Reproduce:**

 - Install the `Planning` module with demo data.
 - Create a `Resource Time Off` record with `start` and `end date` separated by more than 
  `1400 days (around 3.9 years)`, and Set the Working Hours field to Standard 40 hours/week.
 - Go to `Planning` > `Configuration` > `Shift Templates`, open an `existing record` or create 
   a `new one`, and set the `Working Days` to more than 1 day.
 - Create a new `planning slot`, Assign the resource `Abigail Peterson`, and select the above 
   `shift template`.

`AttributeError: 'bool' object has no attribute 'replace'`

This error occurs because when the user sets the shift template, the compute method runs to 
calculate the start and end datetimes [1]. It computes the end datetime by adding the template 
duration in working days from the given start datetime using the resource working calendar within 
a searchable range of around 1400 days [2]. During this computation, leaves and non-working days 
are skipped [3]. If no valid working interval is found within the searchable range, then it returns 
False [4], which raises the error [5].

This commit ensures that if plan_days returns False, the computation falls back to the previously 
calculated end date.

[1]: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/planning/models/planning.py#L662-L671

[2]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L826-L835

[3]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L533-L537

[4]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L835

[5]- https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/planning/models/planning.py#L653-L654

sentry-7472958590

Forward-Port-Of: odoo/enterprise#117073

[FIX] hr_attendance_gantt: fix gantt view with public holidays

Bug reproduction:
    1 - Select flex schedule employee (or change its schedule to 40h flex one) and make its contract before 01/01/2026
    2 - Create a new public holiday on 01/01/2026 (from 00.00 to 23.59 or 23.55 (depends on version, it does not matter))
    3 - in attendance app the cell from 00.00 to 01.00 seems white for that day and for selected employee (this cell seems like not holiday and employee can work)

Bug cause:
    1 - After a long traceback, _gantt_unavailability in hr_attendance_gantt/HrAttendance, if an employee is flexible then unavailable_intervals is calculated with the Brussel time zone
    2 - All other unavailable intervals are converted to the UTC in the function of _gantt_unavailability except in the final lines of the function.
    3 - When the employee is flexible and since the conversion is not done in the final lines, it remains 1 hour more (UTC+1), it is from 1 am to 1 am of next day instead of 0 am to 23.59.

Bug solution:
    1 - I converted the timezone to UTC to solve the problem.

task - 6067070

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

opw-6125243

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

Steps to reproduce
1. Install hr_holidays and hr_contract.
2. Take a demo employee currently on a validated time off covering now.
3. Set the employee's running contract Working Schedule to empty (fully flexible).
4. Run the "HR Contract: update state" cron (or otherwise leave the contract in state open / close, or draft + kanban Ready).
5. Open the Employees app or any view rendering that employee's chatter / follower panel.

Issue
A traceback "Expected singleton: resource.calendar()" is raised. If the employee's chatter is open, the failing compute is re-fired on every store refresh and the UI becomes unusable.

For fully flexible contracts, hr.contract has no resource_calendar_id, so _get_calendar_periods appends period tuples with an empty calendar recordset (https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/hr_contract/models/hr_employee.py#L184). _get_first_working_interval then forwarded that empty recordset to _work_intervals_batch, which calls ensure_one() and crashes.

This regressed when _compute_leave_status was switched from a single calendar lookup to per-period iteration in
https://github.com/odoo/odoo/commit/bf73b63eec56a822edec2d9ecfeb231a0fbfbbe8 which did not consider that a period in the chain can come from a contract with no calendar.

Solution
Fall back to the company's calendar when the period's calendar is empty, matching the guard already present from saas-18.4 onwards in https://github.com/odoo/odoo/commit/21f18b1a6fdbf1a01c3dda83acfa66addd01a759.

opw-6168264

Issue is really similar to commit 21877c09863222a237fe99334787ac46935dcca4 except here the compensations 
amls are created in _stock_account_prepare_anglo_saxon_in_lines_vals
because of a difference between bill price and product cost

**Steps to reproduce:**
- create storable product with category standard auto
- on the category, set an account in the field 'price difference account'
- set a cost of 10
- set a purchase tax
- confirm a PO for 1 @ 15 and validate receipt
- create bill, set a date, save
- on the Bill set the total tax at 100 (it's bellow 'untaxed amount'
on the bottom right of the bill and should be 2.25 before you
change it, if the tax is 15%)
- confirm the bill 

**Current behavior:**
tax was reset to 2.25

**Expected behavior:**
It should stay 100 as it was manually set

**Cause of the issue:**
The total tax amount is computed based on the tax lines 
in Journal Items
https://github.com/odoo/odoo/blob/2744396733bb3ad60813e9e093d67192c0d38b36/addons/account/models/account_move.py#L1171
So the problem is actually that a recomputation of the balance
of the tax account.move.line (the one with the account "tax paid" in 
journal items) is triggered when we confirm the Bill.

That's because:
 When we confirm the bill, 
_stock_account_prepare_anglo_saxon_in_lines_vals() creates 
two amls : 
- one debiting 5 on the account set in the field 'price difference 
account'
- one crediting 5 in the stock interim received account
(This makes sense and is there to realign with the fact that, on the 
account move linked to the svl, the amount credited from stock 
interim received is rightfully 10 because that's cost of the product 
and it's a standard price product)

When we create those amls from,  the create method 
from account.move.lines calls super() inside a context manager 
calling _sync_dynamic_lines().
https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move_line.py#L1628-L1635
the yield of sync_dynamic_lines() is inside a context manager
calling _sync_tax_lines.
https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move.py#L3250
Therefore, the first half of sync_tax_lines() (untill the yield) is ran 
before the call to super and the rest (from the yield) is ran 
after the call to super. 
Because we added two lines in the account.move, get_changed_lines
will return those 2 new line and because there is a tax_ids on the new lines
round_from_tax will be False.
https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move.py#L3034-L3041
Therefore we won't reach continue.
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move.py#L3055-L3059
And the tax line will be recomputed using 
_prepare_tax_line()
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move.py#L3065

Here is why there is a tax_ids on the new lines : 
The field is precompute so if we don't set a value for 
it, _compute_tax_ids will be ran to compute it.
As the account move on which the lines are added 
is a bill, the tax_ids will the supplier_tax_id of the product.
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move_line.py#L898-L901

**fix**
There is no need for a tax_ids on these lines as they 
are not meant to (and should'nt) impact the taxes.

opw-6014710

### Issue before this commit:
When importing an Italian electronic vendor bill using the AssoSoftware standard, pension fund taxes (Cassa Previdenziale) are not applied to the invoice lines.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it_edi_witholding
2. Change VAT number of IT company with the one in the xml
3. Go to Taxes > 4%F.Pens. > Advanced Options and change Pension Fund Type with TC02
4. Import xml of the ticket in vendor bills
5. P.Fund tax is not assigned

### Cause of the issue:
The issue is caused by the following line:
https://github.com/odoo/odoo/blob/669b9b84f4d5c8765dc4b451d5da6a95dbb9ded8/addons/l10n_it_edi_withholding/models/account_move.py#L247 Currently, the parser strictly expects the optional <RiferimentoTesto> tag alongside <TipoDato>AswCassPre</TipoDato>. However, several third-party software providers generate valid XML files containing only the  AswCassPre block without any optional child tags.

### Reason to introduce the fix:
Ensure that the pension fund tax mapped to the line's VAT rate is correctly applied whenever the AswCassPre data type is present, even if the optional reference tags are omitted.

opw-6189225

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