An error currently occurs when an user attempts to change the rental start date to a value later than the end date while a product is already in the cart.

**Steps to replicate:**
* Install `website_sale`, `stock` , `sale_renting` with demo data
* Rental > Products > Printer > Sales > Turn `Out of stock: continue selling` off
* Website > Shop > Printer > Select dates when printer is available
* Add printer to cart > Set start date greater than end date by typing

`ValueError: min() iterable argument is empty`

**Cause:**
This error occurs because [1] causes the `availabilities` list to be empty at [2] when retrieving combination information.

This issue occurs in version `18.4` and later because the date picker remains editable after the product is added to the cart. The changes in [3] remove the `disabled` attribute after the product is added, allowing users to modify the date.

**Solution:**
* Prevent users from editing dates after a product is added to the cart, as done in version `18.3`, since all products must share the same dates as the one already in the cart, as specified in [4].

[1]:
https://github.com/odoo/enterprise/blob/246a49ff3fd2baa636f3e7d80a75a01e77060ee1/website_sale_stock_renting/models/product_product.py#L79 
[2]:
https://github.com/odoo/enterprise/blob/246a49ff3fd2baa636f3e7d80a75a01e77060ee1/website_sale_stock_renting/models/website.py#L14-L19 
[3]:
https://github.com/odoo/odoo/commit/bbb2d98d9ab97ce729d59b9858b63daccf5434e2#diff-39e02d03a8b765b4e3afc68627aeb33f11b587163638fedfb92ed5657c3336e7R230 
[4]:
https://github.com/odoo/enterprise/blob/246a49ff3fd2baa636f3e7d80a75a01e77060ee1/website_sale_renting/views/templates.xml#L100

**Sentry-6803401968**

steps to reproduce:
-------------------
1. Install `l10n_sa_edi` and `l10n_latam_invoice_document`
2. Create and confirm an invoice.
3. Print the invoice PDF

issue:
------
The company logo is not printed on the invoice PDF.

cause of the issue:
-------------------
The `l10n_latam_invoice_document` hides the standard company logo if
`company_header` is set to true:
https://github.com/odoo/odoo/blob/0f6cb037e05db86e808682659a12442464b2cdd2/addons/l10n_latam_invoice_document/views/report_templates.xml#L6-L8

In the case of `l10n_sa`, the custom_header value is set because of this condition:
https://github.com/odoo/odoo/blob/0f6cb037e05db86e808682659a12442464b2cdd2/addons/l10n_sa/views/report_invoice.xml#L23

However, the condition in `l10n_latam_invoice_documnet` expects
a callable record instead of static XML data, which is incorrect:
https://github.com/odoo/odoo/blob/022fcbcf40a28afa56010f6130c26bb0503d5467/addons/l10n_latam_invoice_document/views/report_templates.xml#L9-L14

solution:
---------
Renaming the variable to `custom_header_sa` resolves the issue.

<details>
    <summary>Click here to see:</summary>
    Before:
    <img src="https://github.com/user-attachments/assets/f4606a44-10ce-4038-92a3-2c8ec2a69edf"/>

    After:
   <img src="https://github.com/user-attachments/assets/70055155-63f2-4fec-aaf6-3bf5587f5591"/>
</details>


opw-4977422

Forward-Port-Of: odoo/odoo#225476

*: test_import_export

### Steps to reproduce:

- Go to Sales/Prodcuts/Pricelists
- Create a new pricelist with a rule with a set Valid Period
- Export that record adding the Pricelist Rule/Start Date (item_ids/date_start) as XLSX format
- Delete the record and test the import the XLSX file
#### Uncaught Promise:
> Invalid props for component 'ImportDataColumnError' :'resultNames' is undefined (should be a array)

### Cause of the Issue:

The issue is raised by the error message:
https://github.com/odoo/odoo/blob/32bdff8bc603a03038d3f9e38463809883319305/addons/base_import/models/base_import.py#L1428-L1432
which is not properly handled by the `ImportDataColumnError` component. However, in the present situation, the issue is just that this error message itself should not be raised in the first place.

#### Details:

Since commit 630b2683d3aad203b0bbf7d2d63b88cd4d3bd9d7, date and datetime formatted cells in spreadsheets are no longer Char field. Instead, they are imported as date and datetime objects. This was intended to allow importing columns with mixed encodings (e.g., some values stored as strings, others as dates in the spreadsheet).

However, a side effect of this change is that if a char-type field contains values that a spreadsheet interprets as dates or datetimes, the import fails. For example, an account move name "21/12/2025" may be interpreted as a date. Attempting to perform a join on this string expected value causes a traceback here: https://github.com/odoo/odoo/blob/32bdff8bc603a03038d3f9e38463809883319305/addons/base_import/models/base_import.py#L1628-L1632

To address this discrepancy, commit 91dca74b3e395c8ee410db18784990ba3a6a7e6e introduced a check raising an error if the imported field type is not appropriate to carry a `date/datetime` value.

This fix has two major issues:

1) It still does not handle the above use case correctly—it remains impossible to import "21/12/2025" as a record name. 
2) (The present issue) It does not properly check the type of related fields. For example, a field like "company_id/partner_id/membership_start" is not considered as an allowed date field. The current check on allowed date fields being overly simplistic:
https://github.com/odoo/odoo/blob/32bdff8bc603a03038d3f9e38463809883319305/addons/base_import/models/base_import.py#L1416-L1421

### Fix:

We propose reverting commit 91dca74b3e395c8ee410db18784990ba3a6a7e6e. And instead of recursively computing the related model and the appropriate types of related fields (including property-type relational fields), we will simply stringify values when they are written into char-like fields (e.g., char or text).

Note: this may also require an adjustment in master for the html type.

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

Forward-Port-Of: odoo/odoo#226807

steps to reproduce:
-------------------
1. Install `l10n_sa_edi` and `l10n_latam_invoice_document`
2. Create and confirm an invoice.
3. Print the invoice PDF

issue:
------
The company logo is not printed on the invoice PDF.

cause of the issue:
-------------------
The `l10n_latam_invoice_document` hides the standard company logo if
`company_header` is set to true:
https://github.com/odoo/odoo/blob/0f6cb037e05db86e808682659a12442464b2cdd2/addons/l10n_latam_invoice_document/views/report_templates.xml#L6-L8

In the case of `l10n_sa`, the custom_header value is set because of this condition:
https://github.com/odoo/odoo/blob/0f6cb037e05db86e808682659a12442464b2cdd2/addons/l10n_sa/views/report_invoice.xml#L23

However, the condition in `l10n_latam_invoice_documnet` expects
a callable record instead of static XML data, which is incorrect:
https://github.com/odoo/odoo/blob/022fcbcf40a28afa56010f6130c26bb0503d5467/addons/l10n_latam_invoice_document/views/report_templates.xml#L9-L14

solution:
---------
Renaming the variable to `custom_header_sa` resolves the issue.

<details>
    <summary>Click here to see:</summary>
    Before:
    <img src="https://github.com/user-attachments/assets/f4606a44-10ce-4038-92a3-2c8ec2a69edf"/>

    After:
   <img src="https://github.com/user-attachments/assets/70055155-63f2-4fec-aaf6-3bf5587f5591"/>
</details>


opw-4977422

Forward-Port-Of: odoo/odoo#225476

In **`balance_pymes_line_32300`** (`CURRENT LIABILITIES > Current payables > Other current payables`), amounts are **doubled** because account **551** is included twice.

* **Formula using `account_codes`:**

  ```xml <field name="formula">-1034 - 1044 - 190 - 192 - 194 - 500 - 501 - 505 ...551 - 5566 - 5595 - 5598 - 560 - 561 - 569</field> ```

  → Explicitly includes account **551**.

* **Formula using `domain`:**

  ```xml <field name="formula" eval="['|', ('account_id.code','=like','550%'), '|', ('account_id.code','=like','551%'), '|', ('account_id.code','=like','554%'), ('account_id.code','=like','5525%')]"/> ```

  → Includes **all accounts starting with 551**, so **551** is also counted here.

This overlap causes the balance to be counted twice, inflating the reported value.

**steps to reproduce:**

1. With a Spanish company, go to **Accounting > Dashboard > Bank > Transaction > New**.
2. Select an account, search for **55100**, and add it.
3. Go to **Reporting > Balance Sheet > Other current payables**.
4. Notice that the reported amount is **double** the actual accounting data.

Overlapping formulas: specific account `551` and `5525` are counted in `account_codes`, while the `domain` formula already includes `551%`, leading to duplication.

**Fix**

Remove explicit account codes from `account_codes` if they are already covered by the `domain` prefixes to avoid double-counting. and also made sure to correct the same issue in the whole report.

opw-5075035

*: test_import_export

### Steps to reproduce:

- Go to Sales/Prodcuts/Pricelists
- Create a new pricelist with a rule with a set Valid Period
- Export that record adding the Pricelist Rule/Start Date (item_ids/date_start) as XLSX format
- Delete the record and test the import the XLSX file
#### Uncaught Promise:
> Invalid props for component 'ImportDataColumnError' :'resultNames' is undefined (should be a array)

### Cause of the Issue:

The issue is raised by the error message:
https://github.com/odoo/odoo/blob/32bdff8bc603a03038d3f9e38463809883319305/addons/base_import/models/base_import.py#L1428-L1432
which is not properly handled by the `ImportDataColumnError` component. However, in the present situation, the issue is just that this error message itself should not be raised in the first place.

#### Details:

Since commit 630b2683d3aad203b0bbf7d2d63b88cd4d3bd9d7, date and datetime formatted cells in spreadsheets are no longer Char field. Instead, they are imported as date and datetime objects. This was intended to allow importing columns with mixed encodings (e.g., some values stored as strings, others as dates in the spreadsheet).

However, a side effect of this change is that if a char-type field contains values that a spreadsheet interprets as dates or datetimes, the import fails. For example, an account move name "21/12/2025" may be interpreted as a date. Attempting to perform a join on this string expected value causes a traceback here: https://github.com/odoo/odoo/blob/32bdff8bc603a03038d3f9e38463809883319305/addons/base_import/models/base_import.py#L1628-L1632

To address this discrepancy, commit 91dca74b3e395c8ee410db18784990ba3a6a7e6e introduced a check raising an error if the imported field type is not appropriate to carry a `date/datetime` value.

This fix has two major issues:

1) It still does not handle the above use case correctly—it remains impossible to import "21/12/2025" as a record name. 
2) (The present issue) It does not properly check the type of related fields. For example, a field like "company_id/partner_id/membership_start" is not considered as an allowed date field. The current check on allowed date fields being overly simplistic:
https://github.com/odoo/odoo/blob/32bdff8bc603a03038d3f9e38463809883319305/addons/base_import/models/base_import.py#L1416-L1421

### Fix:

We propose reverting commit 91dca74b3e395c8ee410db18784990ba3a6a7e6e. And instead of recursively computing the related model and the appropriate types of related fields (including property-type relational fields), we will simply stringify values when they are written into char-like fields (e.g., char or text).

Note: this may also require an adjustment in master for the html type.

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

Forward-Port-Of: odoo/odoo#226807

If you have a company with a lock date set, and you connect a bank that has transactions dated to the day of the lock date, these transactions will be fetched, which do not make sense because nothing should be created in a period covered by a lock date.

As a result, these transactions would be created at a wrong date (if the current month is the first after the lock date or if the sequence has a monthly reset, then they would be appended to the current month, else if the sequence reset annually, then they would be created at the current date).

Additionally, the potential opening balance would be created at a wrong date too, since it would try to create it one day prior to the oldest transaction.

The date which the opening balance is created would not be the same as the transactions above, which adds a layer to the mess created.

To prevent this, at initialization, we set the last sync date one day after the lock date, not the same day.

As for the opening balance, we do not try to set it one day prior to the oldest transaction, but the same day. The `internal_index` computed will ensure it is displayed as the first transaction of that journal.

Finally, the test related to statement creation were adapted to this new behavior. Some ordering based on `date` in other tests were changed to `internal_index` to unify the test file with these changes.

opw-4890538

Forward-Port-Of: odoo/enterprise#94648
Forward-Port-Of: odoo/enterprise#93543

Steps to reproduce:
-----------------
1. Go to Timesheet → My Timesheet → List View → New OR Edit already filled time.
2. Change time in the Time Spent field.
3. Press Shift + Tab.

Observation:
-----------------
The focus changes, but the Time Spent field reverts to its old value instead of keeping the newly entered one.

Issue:
-----------------
- For new records, the component retrieves the value only from the state, which
is updated in the `onWillUpdateProps` lifecycle. This lifecycle triggers only on
saving or editing, not when simply changing focus.
https://github.com/odoo/enterprise/blob/e14b991927df14f41535e92dd01ea2ecac44a404/timesheet_grid/static/src/components/timesheet_display_timer/timesheet_display_timer.js#L123-L128

-  The same behavior occurs when editing existing records, leading to incorrect
value display.
https://github.com/odoo/enterprise/blob/e14b991927df14f41535e92dd01ea2ecac44a404/timesheet_grid/static/src/components/timesheet_display_timer/timesheet_display_timer.js#L31-L33

Solution:
-----------------
-  For new records, since the default value is 0, the fix makes the component
fall back to the updated record value if the state value is not yet available.

-  For existing records, if the timer is running, the timer’s value is
displayed. otherwise, the component falls back to the updated record value.


opw-4922847

Forward-Port-Of: odoo/enterprise#94729

### Issue:
Ecuadorian customer can download their invoice's XML from the SRI, but the file contains the invoice in a wrapper tag (`<![CDATA[ ... ]]>`) that prevent the extraction of the data to fill the vendor bill form view.

#### Steps to reproduce:
- Install "l10n_ec_edi" and switch to an Ecuadorian company
- Have a file downloaded from the SRI.
- Go to Accounting > Vendor > Bills
- Click "Upload" and select the file
- The generated move is not populated with the data

### Cause:
We are expecting the XML to not be in the tag `CDATA` and it gets ignored.

### Solution:
The change is in `_get_import_file_type` to detect the new type of file as `'l10n_ec.factura'`.

The CDATA content can be fetched by getting the content of the tag `comprobante`. We then try to convert the content of `comprobante` to XML. If it's possible, we have an XML on which we can do the same check as before to know if it's an Ecuadorian invoice. We then replace the `file_data['xml_tree']` by the content of `CDATA` to have the correct XML for the data extraction.

opw-5004636

Forward-Port-Of: odoo/enterprise#94184

steps to reproduce:
-------------------
1. Install `l10n_sa_edi` and `l10n_latam_invoice_document`
2. Create and confirm an invoice.
3. Print the invoice PDF

issue:
------
The company logo is not printed on the invoice PDF.

cause of the issue:
-------------------
The `l10n_latam_invoice_document` hides the standard company logo if
`company_header` is set to true:
https://github.com/odoo/odoo/blob/0f6cb037e05db86e808682659a12442464b2cdd2/addons/l10n_latam_invoice_document/views/report_templates.xml#L6-L8

In the case of `l10n_sa`, the custom_header value is set because of this condition:
https://github.com/odoo/odoo/blob/0f6cb037e05db86e808682659a12442464b2cdd2/addons/l10n_sa/views/report_invoice.xml#L23

However, the condition in `l10n_latam_invoice_documnet` expects
a callable record instead of static XML data, which is incorrect:
https://github.com/odoo/odoo/blob/022fcbcf40a28afa56010f6130c26bb0503d5467/addons/l10n_latam_invoice_document/views/report_templates.xml#L9-L14

solution:
---------
Renaming the variable to `custom_header_sa` resolves the issue.

<details>
    <summary>Click here to see:</summary>
    Before:
    <img src="https://github.com/user-attachments/assets/f4606a44-10ce-4038-92a3-2c8ec2a69edf"/>

    After:
   <img src="https://github.com/user-attachments/assets/70055155-63f2-4fec-aaf6-3bf5587f5591"/>
</details>


opw-4977422

Forward-Port-Of: odoo/odoo#225476

**Steps to reproduce**
- Automatically approved attendances.
- Create an attendance and save it.
- Note the "Extra hours" displayed.
- From the form view, change the check in or check out and save it.
- Issue: "Extra hours" are 0. Expected: they should be the same as "Worked extra hours", as the user has not manually modified the field.

**Cause**
Issue since cc81bb59f87540cf4dd8da65510417d8023ef65b The problem is that a 0 value for `overtime_hours` was computed for the `NewId` record used during edition in the interface. This meant `validated_overtime_hours` was also set to this value https://github.com/odoo/odoo/blob/cc81bb59f87540cf4dd8da65510417d8023ef65b/addons/hr_attendance/models/hr_attendance.py#L171 and sent on save, which meant the value was not further recomputed in `_update_overtime`.
https://github.com/odoo/odoo/blob/cc81bb59f87540cf4dd8da65510417d8023ef65b/addons/hr_attendance/models/hr_attendance.py#L408

**Change**
We avoid a recomputation of `validated_overtime_hours` in the interface (which wasn't useful anyway, it was set to 0) to avoid it being interpreted as a manual change by the user.

opw-5003488

Forward-Port-Of: odoo/odoo#226393
Forward-Port-Of: odoo/odoo#222689

When there is no warehouse and user clicks on the replenishment,
A traceback will appear.

Steps to reproduce the error:
- Install ``stock`` module
- Go to Inventory > Configuration > Settings > Enable Multi-Step Routes
- Create new product > Click on ``On Hand`` smart button > Add Negative On Hand Quantity (e.g. -10)
- Go to Inventory > Configuration > Rules > Delete all Rules
- Go to Inventory > Configuration > Warehouses > Delete Warehouse
- Go to Inventory > Operations > Replenishment

Traceback:
```
NotNullViolation: null value in column 'warehouse_id' of relation
'stock_warehouse_orderpoint' violates not-null constraint
```

https://github.com/odoo/odoo/blob/54204e664ed1924f512ba4626be010e39c2d17a3/addons/stock/models/stock_orderpoint.py#L538-L545
When there is no warehouse available, the ``warehouse_id`` is set to False.
when the method tries to create orderpoints using this ``False`` value for ``warehouse_id``.
So, It will raise the above traceback.

sentry-6682818532

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

When user clicks the plan button in the mo,
A traceback will appear.

Steps to reproduce the error:
- Create a new MO > Select any product > Add 2 workorders
- Confirm
- Set Real duration in any workorder
- Click on Plan button

Traceback:
```
File "/home/odoo/src/odoo/addons/mrp/models/mrp_production.py", line 1583, in _plan_workorders
    'date_start': min([workorder.leave_id.date_from for workorder in workorders]),
TypeError: '<' not supported between instances of 'datetime.datetime' and 'bool'
```

The error occurs due to changes introduced in the following commit: https://github.com/odoo/odoo/commit/e587fecca81081a1861b353b85f1d8ed68503973

After this commit, modifying the real duration of a work order sets its status to ``In Progress``.
As a result, the resource calendar leave is no longer created for that workorder. https://github.com/odoo/odoo/blob/3fb37cbc59adc2caace8efcdae418d2466a9b750/addons/mrp/models/mrp_workorder.py#L529-L530

So, here ``leave_id.date_from`` becomes False.
https://github.com/odoo/odoo/blob/3fb37cbc59adc2caace8efcdae418d2466a9b750/addons/mrp/models/mrp_production.py#L1575-L1576

So, It will lead to the above traceback.

sentry-6595147036

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

The variable `cert_sudo` was being used outside of the for loop 
If no certificate is present, the loop is skipped, and `cert_sudo` remains 
undefined, resulting in the UnboundLocalError.

**Steps to replicate**
Install the Sales,Accounting apps and l10n_co_dian module. 

* Go to Settings Open `Users and Companies` > `Companies` and create a New Company.
* Enter the name: YourCompany (Colombia) and in the `Country field`, select `Colombia`.
* Enter arbitrary values for the `Company ID` fields and save. 
* Switch to `YourCompany (Colombia)` from dashboard.
* Go to Settings>Accounting section>Colombian Electronic Invoicing section. 
* In Operation Modes, add a line.
* Set Software Mode to `DIAN 2.1: Electronic Invoices` and set `Software PIN` and `Testing ID` randomly and save.
* Go to Contacts app and search for `Deco Addict`.
* Open the Sales and Purchase page.
* In the `Obligaciones y Responsabilidades` field, select `0-47`. 
* Enter an arbitrary value for Company ID and save. 
* Go back to contacts and now search for `YourCompany (Colombia)`. 
* Enter arbitrary letters in the Identification field and select any option in the `City` field.
* Go to the Sales and Purchase page and Fill in `Obligaciones y Responsabilidades` and save. 
* Open Accounting and Select Configuration > Journals>Customer Invoices.
* Go to the Advanced Settings page.
* Fill all fields under the `Resolución DIAN section` with arbitrary values and save.
* Create a new Customer Invoice by pressing the New button under Customer Invoices from accounting dashboard.
* Set the customer to `Deco Addict`.
* Add a random product in the product lines then save and press confirm. 
* Press Send, then in the template preview, press Continue > Send. 

**Error:**
`UnboundLocalError: local variable 'cert_sudo' referenced before assignment`

**Solution:**
Added a check to ensure that certificates_sudo is not empty before entering the 
block where cert_sudo is used.

Sentry-6515616912

When creating a custom horizontal group in accounting module with multiple journals, query with wrong syntax will be fired from `_get_query_sums` method

**Steps to reproduce:**
Install accounting module
* `Configuration>Accounting>Horizontal Groups`
* Create new group and put arbitrary `group name`
* On `Reports` field add `Partner Ledger` then add a line and on `field` select `Journal` hit Save and close.
* Go to `Reporting>Partner Reports>Partner Ledger`
* Select `Horizontal Group > The name of the group you created`

**Error:**
`psycopg2.errors.SyntaxError: syntax error at or near 'WITH'
LINE 27:                 WITH partner_sums AS (`

**Solution:**
Modify the `WITH partner_sums AS( .....) `
with `SELECT * FROM ( WITH partner_sums AS(...) as sub` this prevents invalid syntax  of 
```sql  
WITH partner_sums AS (...)  
SELECT * FROM partner_sums
...
UNION ALL
WITH partner_sums AS (...)  
SELECT * FROM partner_sums
...

``` 
and now instead it does which is a valid syntax
```sql
SELECT * FROM (
    WITH partner_sums AS (...) SELECT * FROM partner_sums
) AS sub
UNION ALL
SELECT * FROM (
    WITH partner_sums AS (...) SELECT * FROM partner_sums
) AS sub
...
```
Sentry-6529855325

If you have a company with a lock date set, and you connect a bank that has transactions dated to the day of the lock date, these transactions will be fetched, which do not make sense because nothing should be created in a period covered by a lock date.

As a result, these transactions would be created at a wrong date (if the current month is the first after the lock date or if the sequence has a monthly reset, then they would be appended to the current month, else if the sequence reset annually, then they would be created at the current date).

Additionally, the potential opening balance would be created at a wrong date too, since it would try to create it one day prior to the oldest transaction.

The date which the opening balance is created would not be the same as the transactions above, which adds a layer to the mess created.

To prevent this, at initialization, we set the last sync date one day after the lock date, not the same day.

As for the opening balance, we do not try to set it one day prior to the oldest transaction, but the same day. The `internal_index` computed will ensure it is displayed as the first transaction of that journal.

Finally, the test related to statement creation were adapted to this new behavior. Some ordering based on `date` in other tests were changed to `internal_index` to unify the test file with these changes.

opw-4890538

Forward-Port-Of: odoo/enterprise#93543

Steps to reproduce:
-----------------
1. Go to Timesheet → My Timesheet → List View → New OR Edit already filled time.
2. Change time in the Time Spent field.
3. Press Shift + Tab.

Observation:
-----------------
The focus changes, but the Time Spent field reverts to its old value instead of keeping the newly entered one.

Issue:
-----------------
- For new records, the component retrieves the value only from the state, which
is updated in the `onWillUpdateProps` lifecycle. This lifecycle triggers only on
saving or editing, not when simply changing focus.
https://github.com/odoo/enterprise/blob/e14b991927df14f41535e92dd01ea2ecac44a404/timesheet_grid/static/src/components/timesheet_display_timer/timesheet_display_timer.js#L123-L128

-  The same behavior occurs when editing existing records, leading to incorrect
value display.
https://github.com/odoo/enterprise/blob/e14b991927df14f41535e92dd01ea2ecac44a404/timesheet_grid/static/src/components/timesheet_display_timer/timesheet_display_timer.js#L31-L33

Solution:
-----------------
-  For new records, since the default value is 0, the fix makes the component
fall back to the updated record value if the state value is not yet available.

-  For existing records, if the timer is running, the timer’s value is
displayed. otherwise, the component falls back to the updated record value.


opw-4922847

Currently, an error occurs when validating an online payment if the network is slow.

**Steps to Reproduce:**
1) Install POS (with demo data) and the Demo Payment module. 
2) Go to Payment Methods and create a new online payment method for any shop (e.g., a clothing shop). Set the Payment Provider to `Demo`.
3) Open a POS session for the clothing shop, select any product, and proceed to payment.
4) Open Inspect → Network tab, create a custom slow network profile(e.g., `set both download and upload speed to 1 KB/s`), and switch to that network.
5) Select the online payment method you just created and continuously click on Validate.

Error:
ValueError: Expected singleton: pos.order('p', 'o', 's', '.', 'o', 'r', 'd', 'e', 'r', '_', '4')

**Root Cause:**
When an online payment is validated, the `_isOrderValid` and `addNewPaymentLine` methods are called.
- With a slow network, the order ID is still temporary(e.g., e74a3369-7dcd-4234-b35e-04daa149ffe6) as the order is not synced completely, when the code at [1] is executed.
- Due to multiple clicks, `_isOrderValid` forces a call to `update_online_payments_data_with_server` at [2] before order is synced.
- This eventually passes the temporary ID to `get_and_set_online_payments_data` at [3], causing the issue.

**Fix:**
Prevent multiple clicks on Validate until the order is successfully synced.

[1]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/components/payment_screen/payment_screen.js#L11-L17

[2]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/components/payment_screen/payment_screen.js#L87

[3]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/models/pos_store.js#L18-L26

**sentry-6849786792**

This issue occurs due to changes introduced in commit [4ac2702](https://github.com/odoo/odoo/commit/4ac2702c31f0e95f33f9ad554e7350bef9dab8bd), 
which added the `copy_data` method. The technique allowed 
duplicating multiple POS configs at once.

When performing a `search_count` on `pos.config` to check for existing records 
with matching `payment_method_ids`, the domain was incorrectly using 
('id', '!=', self.id).
This works fine if self is a `singleton record`, but `fails` if self contains 
  `multiple records`.

**Steps to Produce:-**
- Install the `Point of sale`.
- `Point of sale > Configuration > Payment methods`.
- Select `Card` and `Customer Account`, and delete them.
- Now, go to `Dashboard` and then open the `list view` of `Point of Sale`.
- Select `Furniture Shop` and `Clothes Shop` and then try to duplicate them.

**Error:-**
`ValueError: Expected singleton: pos.config(6, 7)`

**Solution:-**
- This commit fixes the above issues by:-
    - Replacing `('id', '!=', self.id)` with `('id', 'not in', self.ids)` to 
      safely handle multi-record sets.
- Also found another issue, like when we duplicate pos in batch, then it assign 
  the same `cash payment method` to `multiple pos`.
    - This commit also fixes the above issue by overriding the `copy_data()` 
      method.
        - Assign a unique name to each duplicate (e.g., "Shop (copy)").
        - Assign an `unused cash payment method` to each config, or `create` one if 
          none are available.

**Sentry - 6673398556**

### Steps to reproduce:
	- Open Field Service module.
	- Create a new task. In the Customer field, select “Bloem GmbH”.
	- Open the task’s project.
	- In the Invoicing tab, create a new line for any employee and any service.
	- Return to the task and in the Timesheets tab, add a new timesheet.
	- Click the Mark as done button.
	- Click the Sales order button.

### Cause:
When creating the sale order out of the fsm task we use _get_tax_included_unit_price to get the price of the SO line but we are passing the order currency twice to this method so it doesn't convert the price as when it checks the currency and the product_currency it found they are the same so no need to convert

https://github.com/odoo/odoo/blob/6653355b8bc063ceadf08af17fbf2c4a250553e6/addons/account/models/product.py#L239-L240

### Fix:
We pass the product currency instead of the order currency in order to be able to convert the price according to the currencies

opw-5045071

Forward-Port-Of: odoo/enterprise#94947

The system will crash with error when user tries to enable barcode scanner in settings.

**Steps to produce: -**
- Install `Inventory` module.
- `Inventory > configuration > products > Barcode Nomenclatures`.
- Delete the `Default Nomenclature` record.
- Go to settings uncheck `Barcode Scanner` and save settings.
- Now, again `enable` that and save.

Error: -
```py
ValueError: External ID not found in the system: barcodes.default_barcode_nomenclature

ParseError: while parsing /home/odoo/src/enterprise/saas-18.4/stock_barcode/data/data.xml:40, somewhere inside <record id='scale_up_alias_1' model='barcode.rule'>
            <field name='name'>Scale Up Receipt</field>
            <field name='type'>alias</field>
            <field name='pattern'>WH-RECEIPTS</field>
            <field name='alias'>WHIN</field>
            <field name='barcode_nomenclature_id' ref='barcodes.default_barcode_nomenclature'/>
            <field name='sequence'>0</field>
        </record>
```

**Root cause: -**
- At [1], the records use the ref of `default_barcode_nomenclature` which is defined in barcode module. So, when the ref is deleted and we are trying to use it then it gives error.

**Solution: -**
- This commit resolves the error by prevent the deletion of `default nomenclature`.

[1]: https://github.com/odoo/enterprise/blob/400171c9cebc46ecdd907ada210c65f3bbd2dd66/stock_barcode/data/data.xml#L40-L71

**sentry-6823596992**

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

An error occurs when a user enters a `malformed domain` in a campaign and then creates a new activity, due to an unhandled `literal_eval` exception.

**In the following code:**
https://github.com/odoo/enterprise/blob/0a34ac7363b8270bb745a9e9bebba836af52d63f/marketing_automation/models/marketing_activity.py#L142-L143

**Steps to reproduce:**
* Install `marketing_automation` and turn on developer mode.
* `Marketing automation > New>Start from Scratch > Create Campaign`
* Add condition> paste [this domain](https://drive.google.com/file/d/1HKWlgsQt-oGN7SGdgtfghYOMGNslDSag/view?usp=sharing)  in the code editor.
* After `Created on` is added click on it and select the `Created on` field again from dropdown menu this will allow you to save.
* Press `Add new activity`.

`ValueError:malformed node or string on line 1:
 <ast.Call object at 0x7af0f19a1210>`

**Solution**
* Add `eval_domain` helper to handle errors from malformed domain strings.
* Trigger a validation error for invalid domains on the campaign page and during activity creation.

Sentry-6688190469

This error occurs in 18.2 when a user creates a course record for any attendee.

Steps to Reproduce:
 - Install the website_slide module.
 - Go to Reporting > Attendees.
 - Go to either the Graph or Pivot View and click on any count value.
 - Open any attendee record and click on New.

SyntaxError: syntax error at or near ")"
LINE 18:             WHERE SCP.id IN ()
                                      ^

This error occurs because when the user clicks on New to create the attendee's course record, the system triggers the compute method before saving the record. Since the record has not been saved yet, the self.id is empty, which causes the error.

In the list and kanban views, clicking on any attendee record does not open any form view. However, in the graph and pivot views, clicking on an attendee record opens a form view that does not exist, resulting in an error.

This commit ensures that if the form view is present, it will be included in the graph and pivot views. The list view is always included to display the records. The form view may contain computed methods, which can lead to errors if the view is not properly defined.

Sentry-6465821899

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

- Create an invoice with some products and post it
- Go to Accounting > Journal items and ser for the ones belonging to the invoice.
- Set the checkbox for the product sales one and set whatever tax grid (you'll have to reveal that column).
- Accept the changes.
- Now go back to the invoice.
- You'll see a new tracking message. Something like

Journal Item #1093 updated

- It contains a link and from that link you can go to the journal item form.
- In that form you can edit the *amount in currency* field.

Issue:

- If a user do so, it leaves inconsistent invoice amounts: totals aren't recomputed, analytic lines aren't recomputed either.

How it should behave:

- Amount in currency shouldn't be editable here. Mainly when the journal entry is already posted!

opw-4951629

A vídeo showing the issue:
📹️ https://www.loom.com/share/f7cd1d8f4138458f9b6c190233b0b9df?sid=eec77c17-a4a6-4698-8604-10aaa7e33f47

MT-10887 cc @moduon

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

Forward-Port-Of: odoo/odoo#223187

Steps to Reproduce:
------------------
- Open Helpdesk.
- Go to Configuration → Helpdesk Teams.
- Create a new team.
- Enable the Billing feature and assign a project to this team.
- Set the project’s Company field to Null.
- Create an employee for the current user in another company.
- Ensure the user has employees in both companies.
- Create a new ticket (or open an existing one) in the newly created team.
- Try creating a new timesheet → a Validation Error is raised.

Root Cause:
-----------------
When a user has employees associated with multiple companies and tries to log a timesheet with multi-company enabled, a validation error occurs.

**This happens because:**

- The default company is derived from the project linked to the Helpdesk team. Since the company_id field on the project is no longer required, it may be Null, leading to an error when fetching the correct [employee for the company](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216
).

- Additionally, the [company check](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82) is incorrect. The code is checking whether the `company_id` key exists in a `list of vals`, whereas it should be checked directly on the vals dict itself. 

Issue Faced:
-------------
In version 18.3, timesheets are created during migration [here](https://github.com/odoo/upgrade/blob/24f85bbc3408bf10b1cee93e4c395edf806beaa8/migrations/helpdesk_timesheet/saas~18.3.1.0/post-migrate.py#L44-L58 ). Even though the correct company_id is passed, it gets overridden during the process. and If the associated project does not have a company set, the company_id becomes False [here](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82),
 which results in a Validation Error because the [here](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216) unable to determine the correct employee linked to the company. 

OPW: 5004092