Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active.

Steps to reproduce: (19.0)
- Install `account` module
- Set Company currency to `INR` and deactivate `USD` in currencies.
- Install `hr_expense_stripe`
- Create New company > Set `Country` and `Currency` (eg: India and INR) > 
  Switch to New company > Open `Invoicing` you will get the error.

Steps to reproduce: (saas-19.1)
- Install `account` module
- Set Company currency to `INR` and deactivate `USD` in currencies.
- Install `hr_expense_stripe` > Open `Invoicing` you will get the error.

Traceback:
`ValueError: Expected singleton: res.currency()`

In this [PR], the behavior is such that if `company.stripe_currency_id` is not set, we do not create the "Stripe Issuing".

In 19.0, `@template` was executed after the post-init hook, and we were preventing the creation of the [journal] at that stage. However, when a new company is created, the template data is automatically loaded for companies 
with a matching chart of accounts. As a result, the `stripe_issuing_journal` is created, which leads to the error.

However, in saas-19.1, due to recent improvements in a [commit], the `@template` will now loads data for companies without post init hook. As a result, the `stripe_issuing_journal` is being created, and we are encountering an error.

Solution:
- The`Stripe Issuing` journal will no longer be created on installing the module.
- For existing databases, we will use the company currency as a fallback value to ensure that a valid currency is applied.

[PR]: https://github.com/odoo/enterprise/pull/96271
[journal]: https://github.com/odoo/enterprise/blob/fea009f98885a97439edfea75376b7323c8c9a03/hr_expense_stripe/models/res_company.py#L186-L187
[commit]: https://github.com/odoo/odoo/pull/228950/changes/21fd14ed5e8bdd2cf203d466069437a62a87f2bd

sentry-7284934493

Forward-Port-Of: odoo/enterprise#108436

**Steps to reproduce:**
1. Install module `l10n_pe_edi`.
2. Switch company to PE.
3. Create a tax:
   - Name: ICBPER
   - Amount type: Fixed
   - Code: ICBPER
   - Amount: 0.5(e.g.)
   - Set the tax group to ICBPER (In Advance Option)
4. Create a invoice and add a product with ICBPER tax.
5. Post the invoice and click "Process Now" (at header).

**Issue:**
Processing the invoice raises:
    AttributeError: 'dict' object has no attribute '_get_downpayment_lines'

**Cause:**
When `fixed_taxes_as_allowance_charges` is True, `_setup_base_lines()` calls `_turn_emptying_taxes_as_new_base_lines()`, which splits fixed taxes (e.g., ICBPER) into separate base lines.

During this process, `base_line['record']` is no longer the original `account.move.line` record. Instead, it becomes a dictionary containing record under `base_line['record']['record']`.
  - With the flag enabled: `base_line['record']` -> dict `line._get_downpayment_lines()` -> AttributeError
  - With the flag disabled: `base_line['record']` -> `account.move.line``line._get_downpayment_lines()` -> works correctly
 
The Peru EDI implementation directly accesses `base_line['record']` expecting an `account.move.line`. The the nested dict structure causes the crash during file generation.

**Solution:**
Override `_add_invoice_config_vals()` to explicitly set `fixed_taxes_as_allowance_charges = False`
- Add test to ensure invoices with ICBPER fixed taxes generate XML without error

**opw-5809939**

Forward-Port-Of: odoo/enterprise#108638

## [FIX] planning_field_service*,worksheet: fixes follow-up

This commit fixes and improves field service feature in planning to be
sure to not have any regression compared to the previous field service
app.

In detail, this commit will:

- better handle SOL generation
- fix buttons visibility, display name, multi-company issues
- fix mix up demo and data
- auto install when sale timesheet and field service
- display the first slot for today in the stat button
- handle multi-company issue in slot conflicts
  Make partner phone readonly if no Contact access. Hide the Serial/Lot products
  from the shift catalog if the user has no inventory access
- display view itinerary label in mobile
- set role in field service product
- fix the domain of SO stat buttons related to shifts
- fix the default groups of "Planning By ..."" actions.
- use a custom search view for 'resource_ids' in kanban of shifts
- ask to switch in employee portal
- hide by default some fields in list view of shift
- avoid recomputing when a worksheet property changed
- display message to design worksheet in desktop only
- display plan intervention in ticket
- recompute allocated hours when break time changed
- rename Publish & send button into Publish in form view of
  planning.slot model
- display full form in my planning only

## [FIX] planning: manage state in copy_data

Before this commit, when the shift is duplicated, the state is not reset
as expected.

This commit sets copy=False on state field of planning.slot model, to
handle that in copy_data when the shift is splitted because in that case
we want to keep the state instead of resetting it.

## [FIX] planning: display notification error when save as template a template

Before this commit, since the Save as template button is in the cog
menu, it is still displayed even if shift has already generated a shift
template.

This commit will display a notification in the action of that button
when there is already a template linked to that shift.

## [FIX] planning: display planned dates in display_name when empty

Before this commit, the display_name of a shift could be empty and
displays "Unamed" in the breadcrumb due to project, task, customer
and role can be unset on the shift.

This commit will display the planned dates of shift when the other
fields used in the compute of display name are unset. However, the
planned dates are not displayed in the display name if the view is gantt
or calendar because the planned dates are already displayed and would be
redundant.

## [FIX] worksheet: hide section when separator is folded

Before this commit, when the definition of a worksheet defines 2
sections folded by default with some properties inside of each one and
the worksheet template is used for a shift, if the user just unfolds one
section to fill in just this one and lets the other section unfolded,
then the properties in the both sections are displayed in the portal of
the shift even if the second section is folded. The reason is because
the value of the second separator is not in the properties of the shift
because it is untouched.

This commit checks if the separator is by default folded if its value is
not in the properties of the shift.

task-6020304

Co-Authored: Xavier Bol (xbo) <xbo@odoo.com>

An error is thrown when an employee's contract starts mid-period.
```py
Invalid Operation

Wrong python code defined for:
- Employee: Cesar Osbaldo Cruz Solorzano
- Version: False
- Payslip: Payslip - Cesar Osbaldo Cruz Solorzano - 01/16/2026 - 01/31/2026
- Salary rule: Integrated Daily Wage (Base) (INT_DAY_WAGE_BASE)
- Error: AttributeError("'bool' object has no attribute 'year'") while evaluating
'\nresult = round(payslip.l10n_mx_integration_factor * payslip.l10n_mx_daily_salary, 4)\n
```

Steps to reproduce:
1. Install `l10n_mx_hr_payroll` modules
2. Switch to ESCUELA KEMPER URGATE company
3. Go to Employees and open Cesar Osbaldo Cruz Solorzano
4. Go to Payroll tab, change the start date of contract to 01/10/2026 and save
5. Go to Payroll > Payslips > Payslips and create a new pay run
6. Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Monthly' and Period '01/01/2026 -> 01/31/2026'
7. Click on Continue, select Cesar and click on Select
8. An error is thrown

Problem:
In `_compute_integration_factor` method, `_get_first_contract_date` is called with context `before_date`, it returns `False` as the contract starts after the payslip period. This causes an error when trying to access the `year` field of `start_date`.

Solution:
Add a fallback to call `_get_first_contract_date` without context in case the first call returns `False`.

target: saas-18.4
task-6034836

Forward-Port-Of: odoo/enterprise#111007
Forward-Port-Of: odoo/enterprise#110568

Currently, when a user creates a Sale Order for MTO products that share the same component (which itself has a BOM), the system does not create a separate child MO for each manufacturing order.

## Steps to produce:
- Install Sales and Manufacturing
- Go to Settings and turn on Replenish on Order (MTO).
- Create products 'Wooden Arrow' and 'Wooden Rod' with a BOM that includes:
   - 'Stick', which itself has a BOM with 'Raw stick'.
- On each product page, go to Inventory and enable the MTO route, except for 'Raw Stick' .
- Create a Sale Order for Wooden Arrow and Wooden Rod for Customer 'Administrator'.
- Confirm the Sale Order.
- Go to Manufacturing > Open and check both Manufacturing Orders.

## Observed Behavior:
Currently, the manufacturing order for 'Wooden Arrow' has a child MO, but the order for 'Wooden Rod' does not.

The child MO under 'Wooden Arrow' produces two sticks at once. However, each manufacturing order should have its own separate child MO so that every item is produced and tracked individually.

## Root cause:
The issue happens because when a Sale Order is confirmed, [_run_manufacture](https://github.com/odoo/odoo/blob/7c7c6663e28974834d1569b27605f6ce400c7b16/addons/mrp/models/stock_rule.py#L81-L120) is called. This method creates a new MO or updates an existing one based on the domain returned by `_make_mo_get_domain` [1].

For 'Wooden Arrow' and 'Wooden Rod; new MOs are created because no existing MO matches their BOM ID, product ID, or reference.
They are added to `new_productions_values_by_company` [2], which is then used to create the MOs [3].

When `_run_manufacture` runs for 'Stick', it is triggered twice since both MOs require it as a component. The first time, no MO matches the domain, so a new one is created. The second time, the domain matches the existing MO (same BOM ID and product ID), so that MO is updated instead [4]. Because of this, `new_productions_values_by_company` is not filled again, and no second child MO is created.

[1]-
https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/mrp/models/stock_rule.py#L146-L165 
[2]-
https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/mrp/models/stock_rule.py#L98-L103 
[3]-
https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/mrp/models/stock_rule.py#L113-L115 
[4]-
https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/mrp/models/stock_rule.py#L105-L110

## Solution:
To resolve this issue, the domain has been tightened to include the parent production group ID. Since the parent MO’s group ID is passed through the procurement variable when `_run_manufacture` is executed for its component products, this group ID can be used to ensure the correct MO is matched.

**Why modify the existing test case?:**
With this change, in the `test_sale_mrp_pickings` test case, a new child MO for 'Stick' is created under the MO for 'Arrow' instead of modifying another parent MO for 'Stick'. The test case has been updated accordingly. (Confirmed the new behavior with CRL and TAGO)



opw-5480133

Forward-Port-Of: odoo/odoo#248229

Steps to reproduce:
1. Install `contacts`
2. Create an individual contact with a phone number
3. Try to edit the phone number on the mobile

Issue:
- Unable to edit in mobile view

Cause:
- On mobile devices, the utility buttons (Call, SMS, WhatsApp) inside the phone widget consume significant horizontal space. Due to the flex layout, this forces the actual phone input field to shrink too much, making it hard/impossible to view or edit the number.

Solution:
- Hide the text labels of the utility buttons to save space, showing only the icons
- make input's width 100% on mobile screens in partner form

<table>
  <thead>
    <tr>
      <th>Before</th>
      <th>After</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td align="center">
        <img
          src="https://github.com/user-attachments/assets/a620d417-119e-4e28-a62b-f63031e72598"
          alt="Before"
          width="500"
        />
      </td>
      <td align="center">
       <img width="500" height="354" alt="image" src="https://github.com/user-attachments/assets/6adc4c77-767d-491d-a468-8463c0f77666" />
      </td>
    </tr>
  </tbody>
</table>

opw-5489021

Forward-Port-Of: odoo/odoo#250256
Forward-Port-Of: odoo/odoo#246295

**PROBLEM**
Here is the client use case:
The client uses fixed tax to do 'vidange/consignage'. When selling a product with a 'consigne/vidange', they add a fixed tax which amount correspond to the 'consigne/vidange'. When returning the 'consigne', you would create an invoice line, with a product with a price of 0, negative quantity,a 0% tax and the fixed tax for the 'consigne'. When an invoice contains such lines, it fails peppol validations.

**STEP TO REPRODUCE**
1. Create a fixed tax used for 'vidange/consigne'.
2. Create an invoice, with a line with unit price of 0, negative quantity, a 0% tax and the fixed tax for the 'consigne'.
3. Send the invoice using peppol, use a validator to validate the xml and notice you get the following errors: [BR-E-01] [BR-E-08].

**CAUSE**
Fixed tax (like the one used for vidange) are aggregated in new invoice lines by the function `_ubl_turn_emptying_taxes_as_new_base_lines()`. Let say we have the following invoice:
line 1: qty=2, unit_price=3, taxes: 21% & vidange(fixed tax of 1). line 2: qty=-1, unit_price=0, taxes: 0% & vidange.

After calling `_ubl_turn_emptying_taxes_as_new_base_lines()`, we got: line 1: qty=2, unit_price=3, taxes: 21%.
line 2: qty=-1, unit_price=0, taxes: 0%.
line 3: qty=1, unit_price=1(amount of the fixed tax), taxes:None.

When generating the VAT breakdown, we have 2 line will end up being tax exempted (line 2 and 3). Because the `tax_exemption_reason` differs, they will not be merged in the same entry in the breakdown, which break the constraint of peppol saying we can only have one VAT breakdown with code 'Exempt from tax'.
Line 2 reason comes from:
https://github.com/odoo-dev/odoo/blob/de22093ee225df499b2de80e1f07dd281ac686bc/addons/account_edi_ubl_cii/models/account_edi_common.py#L271-L274

opw-5912986

Forward-Port-Of: odoo/odoo#254875
Forward-Port-Of: odoo/odoo#250413

Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active.

Steps to reproduce: (19.0)
- Install `account` module
- Set Company currency to `INR` and deactivate `USD` in currencies.
- Install `hr_expense_stripe`
- Create New company > Set `Country` and `Currency` (eg: India and INR) > 
  Switch to New company > Open `Invoicing` you will get the error.

Steps to reproduce: (saas-19.1)
- Install `account` module
- Set Company currency to `INR` and deactivate `USD` in currencies.
- Install `hr_expense_stripe` > Open `Invoicing` you will get the error.

Traceback:
`ValueError: Expected singleton: res.currency()`

In this [PR], the behavior is such that if `company.stripe_currency_id` is not set, we do not create the "Stripe Issuing".

In 19.0, `@template` was executed after the post-init hook, and we were preventing the creation of the [journal] at that stage. However, when a new company is created, the template data is automatically loaded for companies 
with a matching chart of accounts. As a result, the `stripe_issuing_journal` is created, which leads to the error.

However, in saas-19.1, due to recent improvements in a [commit], the `@template` will now loads data for companies without post init hook. As a result, the `stripe_issuing_journal` is being created, and we are encountering an error.

Solution:
- The`Stripe Issuing` journal will no longer be created on installing the module.
- For existing databases, we will use the company currency as a fallback value to ensure that a valid currency is applied.

[PR]: https://github.com/odoo/enterprise/pull/96271
[journal]: https://github.com/odoo/enterprise/blob/fea009f98885a97439edfea75376b7323c8c9a03/hr_expense_stripe/models/res_company.py#L186-L187
[commit]: https://github.com/odoo/odoo/pull/228950/changes/21fd14ed5e8bdd2cf203d466069437a62a87f2bd

sentry-7284934493

Forward-Port-Of: odoo/enterprise#108436

Currently, an error occurs when the "Payroll: Update Data" scheduled action is executed.

**Steps to Reproduce:**
 - Install `l10n_sa_hr_payroll` with demo data.
 - Switch to `Saudi Arabian` company.
 - Go to `Payroll` > `Configuration` > `Salary` > `Rule Categories`.
 - Delete all records related to the Saudi Arabian company.
 - Go to `Scheduled Actions` and run `"Payroll: Update Data"`.

`ValueError: External ID not found in the system: l10n_sa_hr_payroll.l10n_sa_category_provision`

After [this commit], the category_id field becomes non-required, allowing users to delete 
a rule category record even if it is linked to a salary rule. When updating the data file [1], 
this causes an error due to the missing rule category [2].

This commit ensures that, when updating the salary rule data, the rule category data is updated 
beforehand, as shown here [3].

[this commit]: https://github.com/odoo/enterprise/commit/c663fd2a81b7f6b34f8199fdbdc4a75c4f21379e

[1]- https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_sa_hr_payroll/models/hr_payslip.py#L157-L165

[2]: https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_sa_hr_payroll/data/hr_salary_rule_saudi_data.xml#L249

[3]: https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_ke_hr_payroll/models/hr_payslip.py#L9-L18

sentry-7349905716

**Steps to reproduce:**
1. Install module `l10n_pe_edi`.
2. Switch company to PE.
3. Create a tax:
   - Name: ICBPER
   - Amount type: Fixed
   - Code: ICBPER
   - Amount: 0.5(e.g.)
   - Set the tax group to ICBPER (In Advance Option)
4. Create a invoice and add a product with ICBPER tax.
5. Post the invoice and click "Process Now" (at header).

**Issue:**
Processing the invoice raises:
    AttributeError: 'dict' object has no attribute '_get_downpayment_lines'

**Cause:**
When `fixed_taxes_as_allowance_charges` is True, `_setup_base_lines()` calls `_turn_emptying_taxes_as_new_base_lines()`, which splits fixed taxes (e.g., ICBPER) into separate base lines.

During this process, `base_line['record']` is no longer the original `account.move.line` record. Instead, it becomes a dictionary containing record under `base_line['record']['record']`.
  - With the flag enabled: `base_line['record']` -> dict `line._get_downpayment_lines()` -> AttributeError
  - With the flag disabled: `base_line['record']` -> `account.move.line``line._get_downpayment_lines()` -> works correctly
 
The Peru EDI implementation directly accesses `base_line['record']` expecting an `account.move.line`. The the nested dict structure causes the crash during file generation.

**Solution:**
Override `_add_invoice_config_vals()` to explicitly set `fixed_taxes_as_allowance_charges = False`
- Add test to ensure invoices with ICBPER fixed taxes generate XML without error

**opw-5809939**

Forward-Port-Of: odoo/enterprise#108638

Steps to reproduce (singleton crash):

Create an employee in a UTC+ timezone (e.g. Asia/Shanghai or Australia/Adelaide) with an overtime ruleset containing a paid rule. Generate work entries for a period, then create two consecutive midnight-to-midnight attendances in the employee's local timezone. Creating the second attendance crashes with: "ValueError: Expected singleton: hr.attendance.overtime.line(...)".

Steps to reproduce (stale overtime lines):

With the same setup, delete the attendance after it generated overtime lines. The overtime lines remain in the database instead of being removed.

The singleton crash occurred because `end_of_day` in `_get_overtime_intervals` was computed as a naive datetime, implicitly treated as UTC. For UTC+ timezones, the actual local end of day is earlier than UTC midnight. As a result, overtime intervals were computed with a stop time extending past the real local midnight into UTC time. When consecutive attendances were processed together, these extended intervals overlapped. The `Intervals` class (`keep_distinct=True`) merges overlapping intervals into a single entry with a multi-record recordset as payload. The subsequent `overtime.rule_ids.work_entry_type_id` and `overtime.status` calls expected a singleton but received a multi-record set, causing the crash. The same multi-record issue also affected the iteration in `_set_real_overtime_intervals` and the overtime work entry loop in `_get_attendance_intervals`.

The stale overtime lines issue occurred because `_get_overtimes_to_update_domain` (hr_attendance) built its search date range from raw UTC `.date()` values instead of the employee's local timezone. For UTC+ employees whose attendance spans local midnight, the overtime line is dated in the next local calendar day. Since the domain was derived from UTC dates, that next local day fell outside the search range, so the overtime line was never found and deleted when the attendance was removed.

Solution:
- In `_get_overtime_intervals`, localize `end_of_day` to the employee's timezone before converting to UTC, so overtime intervals are correctly bounded by the local end of day.
- In `_set_real_overtime_intervals` and the overtime loop in `_get_attendance_intervals`, iterate over individual records from potentially multi-record `Intervals` payloads to avoid singleton errors.
- In `_get_overtimes_to_update_domain` (hr_attendance), localize check_in/check_out to the employee's timezone before computing the date range so overtime lines for dates that only exist in local time are correctly included in the delete-and-recreate cycle.

opw-5931665

Forward-Port-Of: odoo/enterprise#109419

Currently, when a user creates a Sale Order for MTO products that share the same component (which itself has a BOM), the system does not create a separate child MO for each manufacturing order.

## Steps to produce:
- Install Sales and Manufacturing
- Go to Settings and turn on Replenish on Order (MTO).
- Create products 'Wooden Arrow' and 'Wooden Rod' with a BOM that includes:
   - 'Stick', which itself has a BOM with 'Raw stick'.
- On each product page, go to Inventory and enable the MTO route, except for 'Raw Stick' .
- Create a Sale Order for Wooden Arrow and Wooden Rod for Customer 'Administrator'.
- Confirm the Sale Order.
- Go to Manufacturing > Open and check both Manufacturing Orders.

## Observed Behavior:
Currently, the manufacturing order for 'Wooden Arrow' has a child MO, but the order for 'Wooden Rod' does not.

The child MO under 'Wooden Arrow' produces two sticks at once. However, each manufacturing order should have its own separate child MO so that every item is produced and tracked individually.

## Root cause:
The issue happens because when a Sale Order is confirmed, [_run_manufacture](https://github.com/odoo/odoo/blob/7c7c6663e28974834d1569b27605f6ce400c7b16/addons/mrp/models/stock_rule.py#L81-L120) is called. This method creates a new MO or updates an existing one based on the domain returned by `_make_mo_get_domain` [1].

For 'Wooden Arrow' and 'Wooden Rod; new MOs are created because no existing MO matches their BOM ID, product ID, or reference.
They are added to `new_productions_values_by_company` [2], which is then used to create the MOs [3].

When `_run_manufacture` runs for 'Stick', it is triggered twice since both MOs require it as a component. The first time, no MO matches the domain, so a new one is created. The second time, the domain matches the existing MO (same BOM ID and product ID), so that MO is updated instead [4]. Because of this, `new_productions_values_by_company` is not filled again, and no second child MO is created.

[1]-
https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/mrp/models/stock_rule.py#L146-L165 
[2]-
https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/mrp/models/stock_rule.py#L98-L103 
[3]-
https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/mrp/models/stock_rule.py#L113-L115 
[4]-
https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/mrp/models/stock_rule.py#L105-L110

## Solution:
To resolve this issue, the domain has been tightened to include the parent production group ID. Since the parent MO’s group ID is passed through the procurement variable when `_run_manufacture` is executed for its component products, this group ID can be used to ensure the correct MO is matched.

**Why modify the existing test case?:**
With this change, in the `test_sale_mrp_pickings` test case, a new child MO for 'Stick' is created under the MO for 'Arrow' instead of modifying another parent MO for 'Stick'. The test case has been updated accordingly. (Confirmed the new behavior with CRL and TAGO)



opw-5480133

Forward-Port-Of: odoo/odoo#248229

This commit resolves a performance bottleneck that occurred when handling very
large sale orders (e.g., ~200 order lines). Previously, the util function
`getParentSectionRecord` determined the parent (sub)section of an order line by
iterating over all preceding order lines. Since this logic was executed for each
order line, the overall complexity became O(n²).

Moreover, this function was invoked inside the `shouldCollapse` method, which is
used in multiple UI flows during rendering. As a result, large sale orders could
cause noticeable UI slowdowns and block the main JavaScript thread.

To address this, we now build a parent–child section mapping once per render
in O(n) time. Subsequent lookups simply read from this mapping instead of
recomputing the parent by scanning previous lines.

This significantly reduces the computational cost and prevents UI blocking when
working with large orders, leading to a much smoother rendering experience.

opw-5865167

Benchmark:

| No. records | Before      | After        |
|----------------|---------------|--------------|
|       150      |   1300ms  |   ~850ms |


| Before      | After        |
|---------------|--------------|
|   <img width="287" height="284" alt="image" src="https://github.com/user-attachments/assets/dd73ab18-3c53-4958-99b7-083dd5cd9e64" />  |   <img width="311" height="277" alt="image" src="https://github.com/user-attachments/assets/b6e90fa3-85eb-4d72-b616-28aff9a938e8" />|
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#252991

**PROBLEM**
Here is the client use case:
The client uses fixed tax to do 'vidange/consignage'. When selling a product with a 'consigne/vidange', they add a fixed tax which amount correspond to the 'consigne/vidange'. When returning the 'consigne', you would create an invoice line, with a product with a price of 0, negative quantity,a 0% tax and the fixed tax for the 'consigne'. When an invoice contains such lines, it fails peppol validations.

**STEP TO REPRODUCE**
1. Create a fixed tax used for 'vidange/consigne'.
2. Create an invoice, with a line with unit price of 0, negative quantity, a 0% tax and the fixed tax for the 'consigne'.
3. Send the invoice using peppol, use a validator to validate the xml and notice you get the following errors: [BR-E-01] [BR-E-08].

**CAUSE**
Fixed tax (like the one used for vidange) are aggregated in new invoice lines by the function `_ubl_turn_emptying_taxes_as_new_base_lines()`. Let say we have the following invoice:
line 1: qty=2, unit_price=3, taxes: 21% & vidange(fixed tax of 1). line 2: qty=-1, unit_price=0, taxes: 0% & vidange.

After calling `_ubl_turn_emptying_taxes_as_new_base_lines()`, we got: line 1: qty=2, unit_price=3, taxes: 21%.
line 2: qty=-1, unit_price=0, taxes: 0%.
line 3: qty=1, unit_price=1(amount of the fixed tax), taxes:None.

When generating the VAT breakdown, we have 2 line will end up being tax exempted (line 2 and 3). Because the `tax_exemption_reason` differs, they will not be merged in the same entry in the breakdown, which break the constraint of peppol saying we can only have one VAT breakdown with code 'Exempt from tax'.
Line 2 reason comes from:
https://github.com/odoo-dev/odoo/blob/de22093ee225df499b2de80e1f07dd281ac686bc/addons/account_edi_ubl_cii/models/account_edi_common.py#L271-L274

opw-5912986

Forward-Port-Of: odoo/odoo#254875
Forward-Port-Of: odoo/odoo#250413

Steps to reproduce:
-------------------
* Let's say you're on company A, create a pos payment method
* Don't assign a pos yet
* Create a branch company sub_A
* Switch to that branch company
* Create a pos
* Now switch to company A but also select sub_A
* In the config of the pos from sub_A, try to add the new payment method and save
> Validation error -> Normal
* Now instead go to the payment method form
* In the point of sales select the pos sub_A
* Save
> No error
* Try opening the pos sub_A
> Validation error, same as the first one -> Normal

Why the fix:
------------
We already have a contraint on the pos config model checking that the companies match.
https://github.com/odoo/odoo/blob/88df50bc96448dfaff28bd37e970ffd18bf8d554/addons/point_of_sale/models/pos_config.py#L469-L473

However when writing on the model pos payment there is no constraint and the ORM currently does not trigger constraints on comodel of the field we're modifying so we need to add this constraint on the pos payment method model as well

opw-6000206

Forward-Port-Of: odoo/odoo#253858

Steps to reproduce (singleton crash):

Create an employee in a UTC+ timezone (e.g. Asia/Shanghai or Australia/Adelaide) with an overtime ruleset containing a paid rule. Generate work entries for a period, then create two consecutive midnight-to-midnight attendances in the employee's local timezone. Creating the second attendance crashes with: "ValueError: Expected singleton: hr.attendance.overtime.line(...)".

Steps to reproduce (stale overtime lines):

With the same setup, delete the attendance after it generated overtime lines. The overtime lines remain in the database instead of being removed.

The singleton crash occurred because `end_of_day` in `_get_overtime_intervals` was computed as a naive datetime, implicitly treated as UTC. For UTC+ timezones, the actual local end of day is earlier than UTC midnight. As a result, overtime intervals were computed with a stop time extending past the real local midnight into UTC time. When consecutive attendances were processed together, these extended intervals overlapped. The `Intervals` class (`keep_distinct=True`) merges overlapping intervals into a single entry with a multi-record recordset as payload. The subsequent `overtime.rule_ids.work_entry_type_id` and `overtime.status` calls expected a singleton but received a multi-record set, causing the crash. The same multi-record issue also affected the iteration in `_set_real_overtime_intervals` and the overtime work entry loop in `_get_attendance_intervals`.

The stale overtime lines issue occurred because `_get_overtimes_to_update_domain` built its search date range from raw UTC `.date()` values instead of the employee's local timezone. For UTC+ employees whose attendance spans local midnight, the overtime line is dated in the next local calendar day. Since the domain was derived from UTC dates, that next local day fell outside the search range, so the overtime line was never found and deleted when the attendance was removed. Additionally, `_get_localized_times` called `.astimezone()` on naive UTC datetimes without first localizing them, producing incorrect local times for the same reason.

Solution:
- In `_get_overtimes_to_update_domain`, localize check_in/check_out to the employee's timezone before computing the overtime search date range (with a ±1 day buffer) so overtime lines for dates that only exist in local time are correctly included in the delete-and-recreate cycle.
- Fix `_get_localized_times` to call `utc.localize()` on naive UTC datetimes before converting to the employee's timezone.

opw-5931665

Forward-Port-Of: odoo/odoo#251812

**Steps to reproduce:**
- Install Accounting and l10n_be
- Switch to a Belgian company (e.g. BE Company CoA)
- In Accounting settings:
  * activate Peppol
  * set "Rounding Method" to "Round Globally"

- Create an invoice:
  * Customer: [a Belgian customer with a VAT]
  * Invoice Lines:

    | Label | Quantity | Price | Taxes | 
    | ------- | ---------- | ------- | ------- |
    |  Line 1   |   1.0    | 90.30 |   0%  |
    |  Line 2   |   0.45   |  2.54 |   6%  |
    |  Line 3   |   0.28   |  6.87 |   6%  |

- Confirm the invoice
- Send the invoice to Peppol

**Issue:**
The generated XML has a line with `<cbc:LineExtensionAmount>` set to 90.31, `<cbc:InvoicedQuantity>` set to 1.0 and `<cbc:PriceAmount>` set to 90.30, which fails the validation with the following error:

`[BR-E-08]-In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Exempt from VAT" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are "Exempt from VAT".`

**Cause:**
The use of decimal number in quantity generates a 0.01 rounding difference in the base amounts.
The extra cent is dispatched in one of the `<cbc:LineExtensionAmount>` node.

**Solution:**
There is no easy solution to handle these rounding cases. The solution used in this fix is to handle the extra cents as if they are cash rounding amount and declare them in `<cbc:PayableRoundingAmount>` node.

opw-5933545




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

Forward-Port-Of: odoo/odoo#255095
Forward-Port-Of: odoo/odoo#253625

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

Some stock queries determine whether a location belongs to the subtree of a set of locations by checking the parent_path prefix against candidate parent locations. This is done using a correlated EXISTS subquery with a LIKE parent.parent_path || '%' condition.

When the list of candidate locations becomes large (for example tens or hundreds of thousands of ids), this approach causes extremely poor performance because the database must repeatedly compare hierarchical path strings for every candidate row.

This PR improves the performance of this ancestry check by replacing the string prefix comparison with a direct check on the ancestor ids contained in parent_path.

### Current behavior before PR:

The query determines whether a location belongs to the subtree of one of the provided locations using:

location.parent_path LIKE parent.parent_path || '%'

For each row, PostgreSQL must evaluate a correlated subquery against all candidate parent locations. Because this relies on string prefix comparisons on parent_path, when the location list is large, this results in extremely slow queries.

### Desired behavior after PR is merged:

Instead of performing string prefix comparisons, the query extracts the ancestor ids directly from parent_path.

The path is:

1. Trimmed to remove leading and trailing /
2. Split into an array of ancestor ids
3. Expanded using unnest
4. Checked for intersection with the provided location ids

This converts the ancestry check from repeated string comparisons into a simple integer membership check.

### Benchmarks

Comparing performance of old subquery:

```
SELECT stock_location_inner.id 
FROM stock_location AS stock_location_inner 
WHERE EXISTS (
    SELECT 1
    FROM stock_location parent
	WHERE parent.id IN (long list)
		AND stock_location_inner.parent_path LIKE parent.parent_path || '%%'
);
```

to new one:

```
SELECT stock_location_inner.id 
FROM stock_location AS stock_location_inner 
WHERE EXISTS (
    SELECT 1
    FROM unnest(
        string_to_array(trim(both '/' FROM stock_location_inner.parent_path), '/')::int[]
    ) AS path_id(id)
	WHERE path_id.id IN (long list)
);
```

Depending on the number of elements in 'long list'

| # of elements | Before | After |
| --- |---|---|
| 130,000 | 21min | 0.8sec |  
| 10,000 | 95sec | 0.5sec |  
| 1,000 | 10.5sec | 0.5sec |  

In practice, on the reference ticket this causes the "Validate" button on a stock picking to go from timing out to taking 8 seconds. 

### Reference

opw-5932436

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

Forward-Port-Of: odoo/odoo#254245

In `ThreadedServer,` the http daemon will create threads to handle incoming requests. The creation of these threads doesn't wait until the registry is loaded because the request could be serving static files. In the WSGI application entry point `__call__`, the threads will be going into `self.get_static_file` and up until this point, there's no locking whatsoever on these threads. Inside `get_static_file`, the `self.statics` lazy_property is evaluated which will walk the addons path.

Before this PR, the order of the conditions in the or statement will always evaluate the lazy property regardless of the other parts of the condition. This means that every single request that comes in will do an unnecessary `os.listdir` on all addons paths.

For customers with a very large and deeply nested addons path like in opw-5877522 (they had over 93K dirs), this is a tremendous load on the system when there are multiple threads doing that due to the amount of syscalls involved for no reason whatsoever. This is especially worse on SH because disks are not local, so an individual syscall is more expensive.

This is slowing down all requests as well as the registry loading time which is a prerequisite for any non-static request.

This PR simply reorders this check to only evaluate the self.statics property if all other parts of the condition are False. This means it'll only have to do this expensive `os.list` for a fewer number of requests which are much more unlikely to coincide at the startup of a worker. On top of that it's a better optimization to avoid doing this expensive check for every request.

Benchmarks

|No. files in addons path| No. concurrent threads  | Registry loading time Before PR | Registry loading time After PR |
|--------|--------|--------|--------|
| 93447 | 5  | 53.23 s  | 4 s  |



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

Forward-Port-Of: odoo/odoo#254660

Case 1:
---
**Steps to produce:**
- Install `pos_sale` module.
- Enable `Automatic Invoice` in settings
- Create a new SO with product price 1000.
- In `Other Info`, set `Online Payment` to 30%.
- Preview > make payment > down payment of 300 is created in SO.
- In POS, open Furniture Shop register > Actions > Quotation/Order > select the SO > settle order.

**Issue:**
- The down payment line is added twice in the POS order.

**Root cause:**
- At [1], `sale_order.amount_paid` = 300, so `addDownPaymentProductOrderlineToOrder` adds the line in order.
- At [2], the down payment line from the SO is added again.
- Here, when `Automatic invoice` is on and we make the online payment
  then `amount_paid` is updated and the downpayment invoice is also created.
- So, we have also downpayment line in sale order also.

**Solution:**
- Ensure that if a downpayment line has already been added to the POS order,
  the first downpayment line matching `amount_paid` is skipped.

[1]: https://github.com/odoo/odoo/blob/54a62bdbe927108a7f85374db26787f8ba45f6ac/addons/pos_sale/static/src/overrides/models/pos_store.js#L88-L93
[2]: https://github.com/odoo/odoo/blob/54a62bdbe927108a7f85374db26787f8ba45f6ac/addons/pos_sale/static/src/overrides/models/pos_store.js#L109-L111

Before:
<img width="484" height="279" alt="image" src="https://github.com/user-attachments/assets/c803c9bd-0751-4a90-81f4-8fb3da3b393e" />


After:
<img width="490" height="235" alt="image" src="https://github.com/user-attachments/assets/2ec4ac43-1db3-4c2e-bfcf-8c52a4830dac" />

Case 2:
---
**Steps to produce:**
- Install `pos_sale` module.
- Enable `Automatic Invoice` in settings
- Create a new SO with product price 1000.
- In `Other Info`, set `Online Payment` to 30%.
- Preview > make payment.

**Issue:**
-The computed value of amount_unpaid is 400, whereas it should be 700.

**Root cause:**
- When Automatic Invoice is enabled and an online payment is made, the invoice
  is automatically created and amount_paid is also updated.
- At [3], the logic subtracts both the total invoice amount and amount_paid from
  the actual total, which results in an incorrect calculation.

**Solution:**
- When an online payment is made, a transaction is created and linked to
  an invoice.
- While computing the total invoice amount, if the transaction’s invoice ID is
  encountered again, it should be skipped to avoid double-counting.

[3]: https://github.com/odoo/odoo/blob/75f6be6744006ed1a3c0857881822723f90f5d4a/addons/pos_sale/models/sale_order.py#L46-L51

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

Forward-Port-Of: odoo/odoo#254964
Forward-Port-Of: odoo/odoo#242026

To reproduce the issue:

- Setup tax periodicity to "trimester"
- Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly Italian tax report for an example)
- Create the appropriate data so that in the current trimester, the report line evaluates to 42, and to 1 in the previous trimester
- Open the report for the second month of the trimester => The line has value 42, while it should have 1.

This happens because the date bounds for previous_tax_period were computed too naively, considering the date_from was always the first day of the tax period. The first day of the second month of the trimester, it's not the case, and we return the period boundaries of the day before that day. That day is the last day of the first month of the trimester, but belongs to the same trimester, so it's the same tax period. Therefore, we display the value of the current tax period, which is wrong.

Forward-Port-Of: odoo/enterprise#111330
Forward-Port-Of: odoo/enterprise#110504

To reproduce the issue:

- Setup tax periodicity to "trimester"
- Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly Italian tax report for an example)
- Create the appropriate data so that in the current trimester, the report line evaluates to 42, and to 1 in the previous trimester
- Open the report for the second month of the trimester => The line has value 42, while it should have 1.

This happens because the date bounds for previous_tax_period were computed too naively, considering the date_from was always the first day of the tax period. The first day of the second month of the trimester, it's not the case, and we return the period boundaries of the day before that day. That day is the last day of the first month of the trimester, but belongs to the same trimester, so it's the same tax period. Therefore, we display the value of the current tax period, which is wrong.

Forward-Port-Of: odoo/enterprise#111330
Forward-Port-Of: odoo/enterprise#110504

Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active.

Steps to reproduce: (19.0)
- Install `account` module
- Set Company currency to `INR` and deactivate `USD` in currencies.
- Install `hr_expense_stripe`
- Create New company > Set `Country` and `Currency` (eg: India and INR) > 
  Switch to New company > Open `Invoicing` you will get the error.

Steps to reproduce: (saas-19.1)
- Install `account` module
- Set Company currency to `INR` and deactivate `USD` in currencies.
- Install `hr_expense_stripe` > Open `Invoicing` you will get the error.

Traceback:
`ValueError: Expected singleton: res.currency()`

In this [PR], the behavior is such that if `company.stripe_currency_id` is not set, we do not create the "Stripe Issuing".

In 19.0, `@template` was executed after the post-init hook, and we were preventing the creation of the [journal] at that stage. However, when a new company is created, the template data is automatically loaded for companies 
with a matching chart of accounts. As a result, the `stripe_issuing_journal` is created, which leads to the error.

However, in saas-19.1, due to recent improvements in a [commit], the `@template` will now loads data for companies without post init hook. As a result, the `stripe_issuing_journal` is being created, and we are encountering an error.

Solution:
- The`Stripe Issuing` journal will no longer be created on installing the module.
- For existing databases, we will use the company currency as a fallback value to ensure that a valid currency is applied.

[PR]: https://github.com/odoo/enterprise/pull/96271
[journal]: https://github.com/odoo/enterprise/blob/fea009f98885a97439edfea75376b7323c8c9a03/hr_expense_stripe/models/res_company.py#L186-L187
[commit]: https://github.com/odoo/odoo/pull/228950/changes/21fd14ed5e8bdd2cf203d466069437a62a87f2bd

sentry-7284934493

Forward-Port-Of: odoo/enterprise#108436

Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient.

### Steps to reproduce

1. Drag and drop multiple files into a WhatsApp Discuss channel.
2. Send the message.

-> Odoo shows all files, but only the first reaches the destination.

### Cause

WhatsApp's API permits only one media object per message. Odoo's "Composer" enforces this by blocking uploads if an attachment is already present. However, it only evaluates the *current* state; dropping multiple files into an empty composer passes the check because the count is zero. On the server, the WhatsApp backend (constrained by the API) is hardcoded to send only the first attachment, silently discarding the rest.

### Fix

Updated frontend validation to inspect the incoming file list during drop and paste actions. The process is now blocked if the total of existing plus incoming files exceeds one, ensuring the user is notified and preventing silent data loss.

opw-5889035

Forward-Port-Of: odoo/enterprise#111001
Forward-Port-Of: odoo/enterprise#107424

**Steps to reproduce:**
1. Install module `l10n_pe_edi`.
2. Switch company to PE.
3. Create a tax:
   - Name: ICBPER
   - Amount type: Fixed
   - Code: ICBPER
   - Amount: 0.5(e.g.)
   - Set the tax group to ICBPER (In Advance Option)
4. Create a invoice and add a product with ICBPER tax.
5. Post the invoice and click "Process Now" (at header).

**Issue:**
Processing the invoice raises:
    AttributeError: 'dict' object has no attribute '_get_downpayment_lines'

**Cause:**
When `fixed_taxes_as_allowance_charges` is True, `_setup_base_lines()` calls `_turn_emptying_taxes_as_new_base_lines()`, which splits fixed taxes (e.g., ICBPER) into separate base lines.

During this process, `base_line['record']` is no longer the original `account.move.line` record. Instead, it becomes a dictionary containing record under `base_line['record']['record']`.
  - With the flag enabled: `base_line['record']` -> dict `line._get_downpayment_lines()` -> AttributeError
  - With the flag disabled: `base_line['record']` -> `account.move.line``line._get_downpayment_lines()` -> works correctly
 
The Peru EDI implementation directly accesses `base_line['record']` expecting an `account.move.line`. The the nested dict structure causes the crash during file generation.

**Solution:**
Override `_add_invoice_config_vals()` to explicitly set `fixed_taxes_as_allowance_charges = False`
- Add test to ensure invoices with ICBPER fixed taxes generate XML without error

**opw-5809939**

**Steps to reproduce**
1. Have an employee using a flexible schedule
2. Create a slot from e.g. 20PM to 4AM for this employee. Make
sure this is the only slot that week for the employee.
3. Publish the Schedule and send it to the employee. Open the
outgoing mail to access the link to the planning view.

Issue: the slot is not visible in the week view.

**Cause**
https://github.com/odoo/enterprise/blob/04a885dbb6eed96297cb5ce9a155ebf8e169427c/planning/controllers/main.py#L193-L194
The `event_hour_min` and `event_hour_max` returned by `planning_get`
and used to control the min/max hours displayed in the week view,
didn't account for slots over multiple days.
For a slot between 20pm and 4am, the `event_hour_max` should be the
end of the day, and the `event_hour_min` should be the start of the
day.

**Solution**
- we change the `event_hour_min` and `event_hour_max` for multi-day
slots to display the full days in the week view
- the previous point has the drawback of displaying the full days
for non-flexible employees even when not necessary. This is because
`slots_start_datetime` and `slots_end_datetime` contained the
`planning.slot` start and end. Instead, we can look at the actual
slot values displayed (by `_get_slots_vals`). For example, a 5 day
slot for a non-flexible employee may contain actual slot values
corresponding to a typical 8-17 working day.

opw-5245985

Forward-Port-Of: odoo/enterprise#99784

The Batch Account Move Lines option in the settings is used to aggregate together the different payslips of a payrun and to create only one move with aggregated lines, per account. This is done to enforce privacy and avoid having lines for each employee in the payrun. If salary rules with analytic distributions are involved, though, the lines are not merged and we lose the anonimity.

This happens because in the _get_existing_lines funciton, that should return the lines to be merged with the input line (line), the condition for the rules that have an analytic distribution is wrong.

In particular, the condition is wrong because the
distribution_analytic_account_ids field is a recordset of the accounts, while line_id['analytic_distribution'] is a dictionary with keys that are comma separated strings of the ids of the accounts, with values reflecting the percentage.

For example, if a rule has one analytic distribution for 40% and involving accounts 13,7 and 12 + another analytic distribution for 60% involving accounts 3 and 5, line_id['analytic_distribution'] will be {'13,7,12': 40.0, '3,5': 60.0} while distribution_analytic_etc will be a recordset containing (13,7,12,3,5). To fix the problem and keep everything inline, we extract the logic to a new function, where we first unravel the ids from the keys of the dictionary and only then try to match them to the values in the recordset.

Task: 6043957

Steps to reproduce
==================

- Install contacts,web_studio
- Login as admin
- Go to contacts
- Open any record
- Open studio
- Click on any field
- Add the "Role / Portal" group
- Toggle the "Show invisible Elements" checkbox
- Click on the same field

=> The field is marked as invisible

- Add an invisible condition

=> The invisible condition is lost (but still applied on the view)

Cause of the issue
==================

In studio, when fetching the view, the invisible attribute is set to True when the user does not have access to the field (when he is not part of the groups).

The goal is to make the field invisible in studio unless the "Show invisible Elements" is toggled.

But this causes the actual value of the invisible attribute to be lost.

Note that this also applies to the column_invisible attribute.

Solution
========

If an invisible/column_invisible attribute is present on the nodes with missing access, we copy the actual value to the `actual_invisible` attribute.

We then use that value in the editor, when present.

opw-6026971

**Steps to reproduce:**

- Make sure you have 3 companies (comp A, B and C)
- Navigate to Settings/Users & Companies/ Companies 
- for each company in the 'Inter Company Transactions' tab: 
check 'generate Sale Orders', 'generate purchase orders' and 
'synchronize Deliveries to your receipts' then select a warehouse 
and a receipt operation type

From company A
- create a storable product
- in the Purchase tab, set the company B as a vendor

From company B 
- in the Purchase tab of the product, set company C as a vendor

From company C
- set a positive on hand quantity

From Company A
- create a SO for 1 quantity of your product
- on the sale order line, unhide de route_id column and 
set it to dropship
- confirm the SO and the linked PO

From company B
- on the SO created with company A as customer (you might need to 
remove the 'my quotations filter to find it), set the dropship 
route in the route_id column of the sale order line
- confirm the SO and the linked PO

From company C
- confirm SO created with company B as customer
- validate the delivery

From company B
- validate the dropship

**Current behavior:**
the quantity delivered on the sale order line is 0 

**Expected behavior:**
it should be 1

**Cause of the issue:**
inside _compute_qty_delivered, we fetch the incoming 
and outgoing moves using _get_outgoing_incoming_moves()
https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L200
There, for the move of the dropship picking, inside the 
if condition, move._is_dropshipped_returned() will be True
https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L348-L354
That's because the move is going from transit to transit
https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/stock_account/models/stock_move.py#L186-L195
So it will not be added to the outgoing moves and 
qty_delivered will stay 0.

**fix**
is_dropshipped_returned should not prevent the move 
to be added to the outgoing moves if is_dropshipped() is 
aslo true (i.e. it's a transit to transit move)

opw-5023215

Description of the issue/feature this PR addresses:
When using the loyalty module with Chilean localization and a sale in UF or Dollars, an error occurs when calculating the promotion amount.

When the system evaluates whether a promotion is applicable, it appears to be taking the value of the sale line after applying the company currency rounding instead of the sale order currency rounding. In the case of Chile with the peso currency, where rounding is applied to the unit, if the value of a line is less than 0.50 UF, the system rounds it to 0. By interpreting the line value as zero, the promotion engine does not recognize the existence of valid products and the "Promotions/Reward" button does not display any available options, even though the program conditions are met.

The root cause of the problem is that the `compute_all` method of taxes is being called without specifying the currency, which causes it to use the company currency instead of the sale order currency.

Current behavior before PR:
- Create a Promotions program (Discount & Loyalty) that applies, for example, a 10% discount without complex minimum restrictions.
- Create a Sales Order and add a product line whose unit price is less than 0.50 (e.g. 0.34 UF).
- Click on the "reward" button. Result: No available promotions are shown or it does not apply if there is only one active promotion.

Desired behavior after PR is merged:
- Create a Promotions program (Discount & Loyalty) that applies, for example, a 10% discount without complex minimum restrictions.
- Create a Sales Order and add a product line whose unit price is less than 0.50 (e.g. 0.34 UF).
- Click on the "reward" button. Result: The button now detects the promotion and allows it to be applied.




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

## Issue before this commit:

Creating an invoice from a POS order with **Cash Rounding enabled only for cash payment methods** raised an unexpected validation error:

> *"The operation cannot be completed: Missing required account on accountable line."*

This happened when the order was paid using a **non-cash payment method**, but rounding logic was still applied.

## Steps to Reproduce:

1. Install the `point_of_sale` module.
2. Go to POS Configuration → Settings:

   * Enable **Cash Rounding**
   * Set a **Rounding Method**
   * Enable **Only on cash methods**
3. Create a product:

   * Sale Price: 260
   * Tax: 6%
4. Open a POS session.
5. Add the product to an order.
6. Apply a discount (e.g., 1.123).
7. Pay using a **non-cash payment method** (journal not marked as cash).
8. Enable **Invoice** and validate the order
   *(or create the invoice later from the Orders menu)*

## Cause of the Issue:

While `_prepare_invoice_vals` correctly avoids setting `invoice_cash_rounding_id` for non-cash payments, `_create_invoice` still executes rounding logic whenever cash rounding is enabled on the POS configuration.

This leads to a mismatch where:

* No rounding configuration is set on the invoice
* Rounding logic still attempts to create/update rounding lines
* Required accounts (profit/loss) cannot be determined
* A validation error is raised due to missing account on the generated line

## With This Commit:

The rounding logic in `_create_invoice` is now guarded by checking the presence of `invoice_cash_rounding_id`.

This ensures rounding is only applied when properly configured and avoids unexpected validation errors for non-cash payment invoices.

Steps To Reporduce: [Video Link](https://drive.google.com/file/d/10ticlUW5i5pbu_oDDPqR-jg0hVcNWf3Z/view?usp=sharing)

opw-6005320
opw-5951991
opw-6036870

**Steps to reproduce:**

- Make sure you have 3 companies (comp A, B and C)
- Navigate to Settings/Users & Companies/ Companies 
- for each company in the 'Inter Company Transactions' tab: 
check 'generate Sale Orders', 'generate purchase orders' and 
'synchronize Deliveries to your receipts' then select a warehouse 
and a receipt operation type

From company A
- create a storable product
- in the Purchase tab, set the company B as a vendor

From company B 
- in the Purchase tab of the product, set company C as a vendor

From company C
- set a positive on hand quantity

From Company A
- create a SO for 1 quantity of your product
- on the sale order line, unhide de route_id column and 
set it to dropship
- confirm the SO and the linked PO

From company B
- on the SO created with company A as customer (you might need to 
remove the 'my quotations filter to find it), set the dropship 
route in the route_id column of the sale order line
- confirm the SO and the linked PO

From company C
- confirm SO created with company B as customer
- validate the delivery

From company B
- validate the dropship

**Current behavior:**
the quantity delivered on the sale order line is 0 

**Expected behavior:**
it should be 1

**Cause of the issue:**
inside _compute_qty_delivered, we fetch the incoming 
and outgoing moves using _get_outgoing_incoming_moves()
https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L200
There, for the move of the dropship picking, inside the 
if condition, move._is_dropshipped_returned() will be True
https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L348-L354
That's because the move is going from transit to transit
https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/stock_account/models/stock_move.py#L186-L195
So it will not be added to the outgoing moves and 
qty_delivered will stay 0.

**fix**
is_dropshipped_returned should not prevent the move 
to be added to the outgoing moves if is_dropshipped() is 
aslo true (i.e. it's a transit to transit move)

opw-5023215

**Problem:**
When manually registering a payment using a Stripe SEPA Direct Debit token, the associated `account.payment` is immediately canceled, even though the Stripe transaction is in "Pending" status. Later, when Stripe confirms the transaction, the payment remains canceled, leading to subscription closures after 90 days of apparent non-payment.

**Steps to reproduce:**
1) Set a customer address to Belgium and add a SEPA Direct Debit payment token via Stripe.
2) Change the company currency to euro.
4) Create a manual invoice for that customer.
5) Pay the invoice using the pre-configured Stripe SEPA token.
6) Observe the `account.payment` is immediately canceled despite the transaction being "Pending".
7) When Stripe confirms the transaction, the payment stays canceled.

**Cause:**
In `account_payment.action_post()`, after sending the payment request, all payments whose transaction state was not `done` were canceled. For asynchronous payment methods like SEPA Direct Debit, the transaction starts in `pending` (not `done`), so the payment was wrongly canceled.

**Solution:**
- Only cancel payments whose transaction ended in a failure state (not in `done`, `pending`, or `authorized`), so pending/authorized payments stay in draft/in_process.

opw-5934381

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

Step to reproduce:
- install spreadsheet_dashboard_sale and pos_sale
- create a order in pos , invoice it too
- open sale dashboard

Observation:
- the order fulfilled in pos, does not reflect in dashboard

Cause:
- sale has 4 status i.e ["draft", "sent", "sale", "cancel"]
- when pos_sale is installed, new status oders are added i.e ['paid', 'invoiced', 'done']
- sale dashboard pivot relies on sale defined status only, which so not consider orders that have status in  ['paid', 'invoiced', 'done']

Fix:
- fix the domain of pivots such that, it will now accept other orders too

**Before:**

<img width="1058" height="277" alt="image" src="https://github.com/user-attachments/assets/e58c88fa-5ad3-4194-9f9c-ddf41f2f73de" />

<img width="1116" height="190" alt="image" src="https://github.com/user-attachments/assets/259e0347-5d5b-4d5c-9aeb-74102aa4becd" />
<br/>


**After**
<br/>

<img width="1137" height="232" alt="image" src="https://github.com/user-attachments/assets/406b71a5-1dd8-4164-9d4e-4f0bca34c9e8" />

<img width="1125" height="235" alt="image" src="https://github.com/user-attachments/assets/fded3203-7d72-45ea-b5aa-142ebcd52136" />


opw-5487654

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

Issue
-----
When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken regardless of setting.

Steps to reproduce
-----
- Enable GS1 nomenclature, lots & batches
- Go to Inventory > Configuration > Operation Types > Delivery Orders
    - Enable Lots/Serial Numbers > Create New
- Create a product
    - Barcode 23456789012344
    - Tracked by SN
    - 1 in stock (SN 1234)
- Create a delivery for the product and add it to a batch
- Open the batch in barcode
- Scan 012345678901234410BATCHSN1
- Confirm the delviery
- Go back to the picking and see the lines' details

> The line used the reserved SN

Cause
-----
The existing line gets matched in `_findLine`

https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1085

because none of the conditions before

https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1402

get matched. This is unexpected but necessary for batches, as it ensures barcode correctly swaps to the correct picking in the batch. If the line was not matched we would be creating a new line in the same picking than the last scanned line, regardless of which picking the reservation is made in.

Because a line is matched, we have to force its' `lot_id` to `false` so that the new one gets created (`lot_name` is used for display but `lot_id` takes precedence).

-----
Ticket:
opw-5216921

Issue
-----
When receiving product after having billed it already, if:
- the product is valuated,
- the purchase is in a foreign currency,
- there is an underlying exchange diff between time of bill and reception
- the diff exchange rate is negative

then the exchange difference account move will occur in the regular exchange account.

Steps to reproduce
-----
- Enable automatic (anglo-saxon) accounting & dropshipping
- Enable the EUR currency and add 2 exchange rates
    - today with 2:1 (EUR:USD)
    - yesterday with 1:2 (EUR:USD)
- Create a new AVCO product category
    - costing method: AVCO
    - valuation: automatic
- Create a new product
    - type: storable
    - category: AVCO
    - purchase: 5€
    - set dropship route
- Create and confirm a SO
- Confirm PO and validate delivery
- Create bill for the PO
    - change bill date to before yesterday & confirm

> Journal entry created in "Exchange Difference" journal

Cause
-----
Thanks to commit 80ff2d2 the flow is well behaved if the new rate is higher (company currency worth more comparatively) because we use the credit aml

https://github.com/odoo/odoo/blob/b57bb1decd46dcbb1fe602bb72b6f8e5382e9b28/addons/account/models/account_move_line.py#L2214-L2215

whose move has a svl

https://github.com/odoo/odoo/blob/b57bb1decd46dcbb1fe602bb72b6f8e5382e9b28/addons/stock_account/models/account_move.py#L335

This is not the case for the debit aml, so we end up using the default currency exchange account.

-----
Ticket:
opw-4797287