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

Forward-Port-Of: odoo/enterprise#94494

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

Forward-Port-Of: odoo/odoo#226594

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#95141
Forward-Port-Of: odoo/enterprise#94729

- 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#225346
Forward-Port-Of: odoo/odoo#223187

### 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#95134
Forward-Port-Of: odoo/enterprise#94947

**Steps to reproduce:**
1. Install `l10n_mx` and `l10n_mx_edi`.
2. Create an invoice with:
   * Enable *CFDI to Public*.
   * Confirm, then send to SAT.
3. Create a credit note with:
   * *Usage* = `Returns, discounts or bonuses` (G02).
4. Download the generated XML for the credit note.

**Observed behavior:**
- The `<UsoCFDI>` tag in the XML shows `S01` (No fiscal effects).

**Expected behavior:**
- The `<UsoCFDI>` tag should show `G02` for credit notes under regime 616 when explicitly selected.

**Root cause:**
- For regime 616 (`Público en general`), the code always defaults to `S01`.
- The condition only allowed `G02` when refunding a global invoice (`is_refund_gi`), not for normal credit notes.

**Solution:**
- Allow `G02` usage to be preserved for credit notes (tipo_de_comprobante = 'E') even when `CFDI to public` is active, as this is now permitted by SAT regulations for fiscal regime 616.

**ref:**
http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/catCFDI_V_4_20250820.xls

opw-5012917

Forward-Port-Of: odoo/enterprise#93071

Description of the issue/feature this PR addresses:
This PR addresses a KeyError that occurs when attempting to generate a PDF quotation for multiple sales orders at once in Odoo. The issue arises when one or more selected orders do not have a valid PDF stream (e.g., due to missing data like order lines or incorrect templates). The error occurs because the system tries to access result[order.id]['stream'] for a sales order that doesn't have the stream generated, causing the server to fail.

Current behavior before PR:
Before this PR, when attempting to print the quotation for multiple sales orders, the system will throw a KeyError if any of the selected orders do not have a valid PDF stream generated. This can happen if a sales order is missing data (such as products or a client) or has an incomplete quotation template. The error prevents users from generating quotations for a group of sales orders, even if only one order is missing the necessary data.

Desired behavior after PR is merged:
After merging this PR, the system will check if the PDF stream exists before attempting to access it. If a sales order does not have a valid stream (due to missing data or other issues), it will be skipped without causing a server error. This allows users to print multiple quotations at once without the system failing due to one incomplete order. The feature will improve robustness when handling orders with missing or incomplete data and prevent unexpected crashes.



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

Forward-Port-Of: odoo/odoo#227517
Forward-Port-Of: odoo/odoo#227347

currently an error occur when user proceed except expired delivery.

Steps to Reproduce:

 - Install the `product_expiry` module.
 - Create a product with the configuration:
   - In `Track Inventory`, select `By Lots`.
   - In the `Inventory tab`, check `Expiration Date`.
 - In the newly created product, click `Lot/Serial Numbers` button, create a new `Lot/Serial Number`, and clear the `Removal Date` of that Lot/Serial Number.
 - Go back to the newly created product and update the `Quantity On Hand` of the linked `Lot/Serial Number` by clicking `Update`.
 - Now go to `deliveries` and create a new `delivery` and add the newly created product and `validate` > `Proceed except expired`.

`TypeError: '<' not supported between instances of 'bool' and 'datetime.datetime'`

This error occurs when user proceed except expired delivery, The removal_date of the move line is computed based on the lot's removal date and the move line's expiration date. If the lot does not have a removal date and the move line also does not have an expiration date, then removal_date on the move line is set to False [1], which raises the error here [2]

This commit ensures that it only compares with the move line removal_date if it is present.

[1]- https://github.com/odoo/odoo/blob/70a7babcc830f72bd069a5bb1504748363e4e848/addons/product_expiry/models/stock_move_line.py#L56

[2]-https://github.com/odoo/odoo/blob/70a7babcc830f72bd069a5bb1504748363e4e848/addons/product_expiry/wizard/confirm_expiry.py#L48

sentry-6864176071

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

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

Forward-Port-Of: odoo/odoo#226594

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#95141
Forward-Port-Of: odoo/enterprise#94729

**Steps to reproduce:**
1. Install `l10n_mx` and `l10n_mx_edi`.
2. Create an invoice with:
   * Enable *CFDI to Public*.
   * Confirm, then send to SAT.
3. Create a credit note with:
   * *Usage* = `Returns, discounts or bonuses` (G02).
4. Download the generated XML for the credit note.

**Observed behavior:**
- The `<UsoCFDI>` tag in the XML shows `S01` (No fiscal effects).

**Expected behavior:**
- The `<UsoCFDI>` tag should show `G02` for credit notes under regime 616 when explicitly selected.

**Root cause:**
- For regime 616 (`Público en general`), the code always defaults to `S01`.
- The condition only allowed `G02` when refunding a global invoice (`is_refund_gi`), not for normal credit notes.

**Solution:**
- Allow `G02` usage to be preserved for credit notes (tipo_de_comprobante = 'E') even when `CFDI to public` is active, as this is now permitted by SAT regulations for fiscal regime 616.

**ref:**
http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/catCFDI_V_4_20250820.xls

opw-5012917

Forward-Port-Of: odoo/enterprise#93071

### 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#95134
Forward-Port-Of: odoo/enterprise#94947

…ay change

**Steps to reproduce**
- Create a public holiday without a calendar during a work day.
- Create a leave for an employee overlapping the public holiday
for a time off type generating Timesheets. Validate it.
- Expected: on the day of the public holiday, no timesheet is
generated for the `hr.leave` to avoid duplication.
- Either delete the public holiday, or set a calendar on it
different than the one defined on the employee.

- Issue: the public holiday timesheet has been deleted, but its
deletion should've lead to the creation of the `hr.leave` timesheet
that we didn't create at the time the public holiday existed.

- Second issue: after that, change the calendar of the public holiday
to the same as the employee's. Still a missing timesheet.

**Solution**
We can use `_reevaluate_leaves` to find the leaves affected by changes
in public holidays.
`_generate_timesheets` then re-generates the timesheets as if the leave
was just validated (the call to `list_work_time_per_day` ignores the
already present resource.calendar.leave).
We also check missing public holidays timesheets to fix the second issue.

opw-4819697

Forward-Port-Of: odoo/odoo#225066
Forward-Port-Of: odoo/odoo#216901

- 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#225346
Forward-Port-Of: odoo/odoo#223187

Description of the issue/feature this PR addresses:
This PR addresses a KeyError that occurs when attempting to generate a PDF quotation for multiple sales orders at once in Odoo. The issue arises when one or more selected orders do not have a valid PDF stream (e.g., due to missing data like order lines or incorrect templates). The error occurs because the system tries to access result[order.id]['stream'] for a sales order that doesn't have the stream generated, causing the server to fail.

Current behavior before PR:
Before this PR, when attempting to print the quotation for multiple sales orders, the system will throw a KeyError if any of the selected orders do not have a valid PDF stream generated. This can happen if a sales order is missing data (such as products or a client) or has an incomplete quotation template. The error prevents users from generating quotations for a group of sales orders, even if only one order is missing the necessary data.

Desired behavior after PR is merged:
After merging this PR, the system will check if the PDF stream exists before attempting to access it. If a sales order does not have a valid stream (due to missing data or other issues), it will be skipped without causing a server error. This allows users to print multiple quotations at once without the system failing due to one incomplete order. The feature will improve robustness when handling orders with missing or incomplete data and prevent unexpected crashes.



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

Forward-Port-Of: odoo/odoo#227517
Forward-Port-Of: odoo/odoo#227347

Currently, an error is raised when generating an invoice for multiple POS orders created for the same customer in a Mexican location.

**Steps to reproduce:**
- Install `l10n_mx_edi_pos` module.
- Switch the company to a **Mexican** company.
- Create two POS orders for the same customer (ensure Invoice is disabled on the payment screen).
- Without closing the POS session, go to the backend and navigate to Orders.
- Select both orders and click **"Create Invoice"**.

**Error:**
`ValueError - Expected singleton: pos.order(5, 4)`

**Cause:**
The method `_prepare_invoice_vals()` accesses fields on `self`, assuming a single record. However, during batch invoicing, `self` can be multiple `pos.order` records. - [1]

[1] - https://github.com/odoo/enterprise/blob/6e0396b078e7c6ffc98eef5a0d21a7df80651c19/l10n_mx_edi_pos/models/pos_order.py#L130-L135

**Fix:**
Ensure the method only accesses fields on the first record, which prevents the singleton error during multi-record processing.

sentry-6563854524

**Steps to reproduce:**
1. Install `l10n_mx` and `l10n_mx_edi`.
2. Create an invoice with:
   * Enable *CFDI to Public*.
   * Confirm, then send to SAT.
3. Create a credit note with:
   * *Usage* = `Returns, discounts or bonuses` (G02).
4. Download the generated XML for the credit note.

**Observed behavior:**
- The `<UsoCFDI>` tag in the XML shows `S01` (No fiscal effects).

**Expected behavior:**
- The `<UsoCFDI>` tag should show `G02` for credit notes under regime 616 when explicitly selected.

**Root cause:**
- For regime 616 (`Público en general`), the code always defaults to `S01`.
- The condition only allowed `G02` when refunding a global invoice (`is_refund_gi`), not for normal credit notes.

**Solution:**
- Allow `G02` usage to be preserved for credit notes (tipo_de_comprobante = 'E') even when `CFDI to public` is active, as this is now permitted by SAT regulations for fiscal regime 616.

**ref:**
http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/catCFDI_V_4_20250820.xls

opw-5012917

Forward-Port-Of: odoo/enterprise#93071

### 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#95134
Forward-Port-Of: odoo/enterprise#94947

**Issue**
When posting a closing entry in September on a tax return report for the month of August, the generated report (PDF/XML) incorrectly shows September instead of August.

**Steps to Reproduce**
1. Install Belgian localization.
2. Go to Accounting > Reporting > Tax Return.
3. Select August as the reporting period.
4. Post the Closing Entry.
5. The report shows September as the month instead of August.

**Root Cause**
The logic in `_init_options_date` was changed in PR #89290 mutating the `options['date']['filter']` by replacing `"tax_period"` with a resolved period type (e.g., `"month"`).
As a result, the `"month"` branch was triggered later in the code, recomputing `date_from` and `date_to` based on the current date instead of the selected tax period boundaries.

**Fix**
Keep the `options['date']['filter']` unchanged (e.g., `"custom_tax_period"`). Use `period_type` field to indicate whether the tax period represents a month, quarter, or year.

Opw-5073081

Forward-Port-Of: odoo/enterprise#94322

Global Issue
-----

Each time a save point is created inside a transaction, it creates a
substransaction with its own subxid. As said in the documentation
"The more subtransactions each transaction keeps open (not rolled back or released),
the greater the transaction management overhead. Up to 64 open subxids are cached in shared memory for each backend;
after that point, the storage I/O overhead increases significantly due to additional lookups of subxid entries in pg_subtrans."

https://www.postgresql.org/docs/current/subxacts.html

When the 64 is reach, it causes a huge I/O overhead (waiting for subtrans LRU) on every
transaction and lead to a complete freeze until the transaction that
create that many savepoints is killed.

Problem 1
---------

This amount of save point is reach during an import that eventually
failed. It retries with one savepoint per record. After 10 errors, the
import stops but if those error happen after few hundred correct line.
Hundreds of save point are created with their respective sub transaction
id.

Solution: We only create one savepoint when the import retries for
every record and rollback each time the import face an error.

As consequence, if record depends on previous one imported before the
rollback, some phantom error will appear and if some record sould be in
error due to previous record (unique constraint for ie.) some error can
be missed. Anyway the first error will remain correct.

In addition, in this PR we want to monitor the number of savepoint per
transaction and fire a warning with the stack info when the limit of 60 savepoint per
transaction is reached.

In order to monitor properly all the savepoint, we need to convert the
last cr.execute("SAVEPOINT") to the context manager

Problem 2
---------

Increase rank is call during _post once per partner.
Since https://github.com/odoo/odoo/commit/f12ce318020169b1355538066a8f81f78ecbf007
_do_action_change_account trigger the increase the rank of many partner
in one transaction.

By grouping the call of increase rank by count it reduce drastically the
amount of call to increase_rank and thus the number of savepoint

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

Forward-Port-Of: odoo/enterprise#94494

### 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#95134
Forward-Port-Of: odoo/enterprise#94947

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#95229
Forward-Port-Of: odoo/enterprise#94729

**Steps to reproduce:**
1. Install `l10n_mx` and `l10n_mx_edi`.
2. Create an invoice with:
   * Enable *CFDI to Public*.
   * Confirm, then send to SAT.
3. Create a credit note with:
   * *Usage* = `Returns, discounts or bonuses` (G02).
4. Download the generated XML for the credit note.

**Observed behavior:**
- The `<UsoCFDI>` tag in the XML shows `S01` (No fiscal effects).

**Expected behavior:**
- The `<UsoCFDI>` tag should show `G02` for credit notes under regime 616 when explicitly selected.

**Root cause:**
- For regime 616 (`Público en general`), the code always defaults to `S01`.
- The condition only allowed `G02` when refunding a global invoice (`is_refund_gi`), not for normal credit notes.

**Solution:**
- Allow `G02` usage to be preserved for credit notes (tipo_de_comprobante = 'E') even when `CFDI to public` is active, as this is now permitted by SAT regulations for fiscal regime 616.

**ref:**
http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/catCFDI_V_4_20250820.xls

opw-5012917

Forward-Port-Of: odoo/enterprise#95246
Forward-Port-Of: odoo/enterprise#93071

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

Forward-Port-Of: odoo/enterprise#94494

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

Forward-Port-Of: odoo/odoo#226594

The way the score bars were animated was a bit confusing. We simplify the
animation by:
- Showing the score accumulated so far without the question
- Animating the score bar towards the accumulated score with the question
- Animating the numerical score on the left towards the accumulated score with the question while fading the numerical score increment on the bar ("+ x p")
- (reordering participants)

We also fix the size of the leaderboard as it was too small to display the score correctly.

How to reproduce
- Create a scored survey with time reward
- Add a question to get the name and toggle the nickname option
- Add a question with an answer that grants n points
- Start a live session
- After a user has completed the question
- Display the leaderboard

The score animation is confusion as it was going through:
- Showing the score accumulated so far without the question
- Animating towards 0: showing a minimal bar due to the minimum size of the score bar
- Animating towards the score question (on top of the minimal bar)
- And finally adding the score accumulated so far without the question

Task-4893763

Forward-Port-Of: odoo/odoo#224996

- 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#225346
Forward-Port-Of: odoo/odoo#223187

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#95141
Forward-Port-Of: odoo/enterprise#94729

### 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#95134
Forward-Port-Of: odoo/enterprise#94947

Description of the issue/feature this PR addresses:
This PR addresses a KeyError that occurs when attempting to generate a PDF quotation for multiple sales orders at once in Odoo. The issue arises when one or more selected orders do not have a valid PDF stream (e.g., due to missing data like order lines or incorrect templates). The error occurs because the system tries to access result[order.id]['stream'] for a sales order that doesn't have the stream generated, causing the server to fail.

Current behavior before PR:
Before this PR, when attempting to print the quotation for multiple sales orders, the system will throw a KeyError if any of the selected orders do not have a valid PDF stream generated. This can happen if a sales order is missing data (such as products or a client) or has an incomplete quotation template. The error prevents users from generating quotations for a group of sales orders, even if only one order is missing the necessary data.

Desired behavior after PR is merged:
After merging this PR, the system will check if the PDF stream exists before attempting to access it. If a sales order does not have a valid stream (due to missing data or other issues), it will be skipped without causing a server error. This allows users to print multiple quotations at once without the system failing due to one incomplete order. The feature will improve robustness when handling orders with missing or incomplete data and prevent unexpected crashes.



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

Forward-Port-Of: odoo/odoo#227517
Forward-Port-Of: odoo/odoo#227347

This commit fixes two bugs related to the "Sign in" in button of the registration form.

First bug:
------------
If there is more ordered seats than available seats, an error modal is displayed with a "Sign In" button. This button shouldn't be present. On click, a 500 error is triggered. Now, the button does not appeared on this modal.

Reproduce:
Check "Mandatory" for "Sign in/up at checkout" in the settings. In the event form, add a limit of 1 available seat and add two tickets with each one 1 seat. With a public user, on the website page of the event, click on "Register" to open the registration modal. In the tickets form, select the maximum number of registrations for each tickets. The error modal with the "Sign In" button should appear. Clicking on this button trigger the 500 error.

Second bug:
----------------
The "Sign in" button is displayed even if the tickets have no price. So the label of the button is wrong because public users are not redirected to the checkout. Now, the "Confirm Registration" button is displayed in this case.

Reproduce:
With the same settings as for the first bug, create an event without tickets. Order a registration with an public user. Click on the "Sign In" button of the attendee details form. The confirmation page appears instead of the sign in page.

task-4797022

Forward-Port-Of: odoo/odoo#215585

**Steps to reproduce:**
1. Install `l10n_mx` and `l10n_mx_edi`.
2. Create an invoice with:
   * Enable *CFDI to Public*.
   * Confirm, then send to SAT.
3. Create a credit note with:
   * *Usage* = `Returns, discounts or bonuses` (G02).
4. Download the generated XML for the credit note.

**Observed behavior:**
- The `<UsoCFDI>` tag in the XML shows `S01` (No fiscal effects).

**Expected behavior:**
- The `<UsoCFDI>` tag should show `G02` for credit notes under regime 616 when explicitly selected.

**Root cause:**
- For regime 616 (`Público en general`), the code always defaults to `S01`.
- The condition only allowed `G02` when refunding a global invoice (`is_refund_gi`), not for normal credit notes.

**Solution:**
- Allow `G02` usage to be preserved for credit notes (tipo_de_comprobante = 'E') even when `CFDI to public` is active, as this is now permitted by SAT regulations for fiscal regime 616.

**ref:**
http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/catCFDI_V_4_20250820.xls

opw-5012917

Currently, An error occurs when the user print and send invoices  and 'Invoice report' is disabled in reports 'report_invoice_with_payments'.

Step to produce:

- Install the `account` module.
- Go to Settings / Technical / Actions / Reports, Search 'report_invoice_with_payments', and disable the 'Invoice report'.
- Go to Invoicing / Customers / Invoices, Create one invoice add a customer and invoice line, and Confirm it back to the list view of the invoice
- Select this invoice and click on Print & Send.
- After Opening a wizard, click the 'Print & Send' button.

The issue occurs when the user tries to generate and send invoices and the system checks that 'is_invoice_report' is enabled for invoices at [1].

Link [1]: https://github.com/odoo/odoo/blob/658711aa1e1809b267006149ed6a547e548c1f90/addons/account/models/account_move_send.py#L658

To resolve this, we have to remove this comparison [1] as the user can disable 'is_invoice_report' from 'report_invoice_with_payments'.

Sentry-6185986435

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

Currently, a traceback is occurring when the user tries to send a 
customer invoice with the sending method as `By Post`.

To reproduce this issue:
1) Install Accounting and Unistall `snailmail`
3) Create a posted `Customer Invoice` with a customer having no Invoice Sending
   (Remove the value in customer's accounting page if he has the value)
4) Click the `Send` button and select the sending method as `To Post` 
5) Click the `Send` button in wizard

Error:-
```
ValueError: Wrong value for res.partner.invoice_sending_method: 'snailmail'
```

The selection value  `snailmail` for `invoice_sending_method` is defined in `snailmail_acount`.
But it will be uninstalled when the `snailmail` module installed.
https://github.com/odoo/odoo/blob/636d76d6dcbbe472b9d57cbe403d0758d94ad81d/addons/snailmail_account/models/res_partner.py#L7-L9

But in the `account.move.send.wizard`, the sending_method values 
are getting from the computed method `_compute_sending_method_checkboxes`.

https://github.com/odoo/odoo/blob/636d76d6dcbbe472b9d57cbe403d0758d94ad81d/addons/account/wizard/account_move_send_wizard.py#L130

We get all the selection values(including the inactive) for the field `invoice_sending_method`. 

When the user selects the `snailmail` checkbox (By Post)to send the invoice,
the value of `invoice_sending_method` for res.partner will be assigned from the below line.

https://github.com/odoo/odoo/blob/636d76d6dcbbe472b9d57cbe403d0758d94ad81d/addons/account/wizard/account_move_send_wizard.py#L269

This will lead to the above traceback as the `snailmail` value for the selection field `invoice_sending_method` in the partner is not valid.

We can resolve this issue by accessing only the active selection values for the field `invoice_sending_method`. So only the user can select the valid value for sending_method.

sentry-6091298443

Issue
-----
When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons.

Steps to reproduce
-----
- Set an Indian company up (with valid address and some dummy mail & phone)
- Create a customer "IN Cust" (with valid address and some dummy mail & phone)
- Create a product "IN Prod"
	- Sale price: 1000 INR
	- Weight: 100g
	- Set some reference, eg "INPROD"
- Create a Shiprocket delivery method
	- Payment Method: COD
	- Set some "Shiprocket Channel"
	- Enable Debug requests
- In settings, enable "Promotions, Loyalty & Gift Card"
- Go to Sales > Products > Discount & Loyalty
- Create a new program
	- Name: 50% off
	- Program Type: Coupons
	- Change the existing reward to 50% discount on order
	- Generate some coupon
	- Copy the code to the generated coupon
- Create a SO our product and customer
- Use the coupon code & apply the 50% discount
- Add shipping
	- Shiprocket COD
	- Get rate
- Confirm the SO
- Go to the picking & validate it
- Open logs (Settings/Technical/Database Structure/Logging)
- Open the "shiprocket_request_external/shipments/create/forward-shipment" log

--> total_discount is 0

Cause
-----
The problem comes from

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L301

There are 2 issues here.

The first and most important one is how we find the discount lines.

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L320

Discounts from coupons don't use the `sale_discount_product_id`, we'll have to define a new function to override in `sale_loyalty` for this.

The second issue is that we use the untaxed discount amount.

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L321

This leads to an incoherent total amount, since the tax is computed on the products' full prices. We should instead be forwarding the total discount value (with tax included to offset the taxes applied on the full product price).

-----
Enterprise PR:
https://github.com/odoo/enterprise/pull/92310
Ticket:
opw-4755357

Forward-Port-Of: odoo/odoo#223517

Issue
-----
When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons.

Steps to reproduce
-----
- Set an Indian company up (with valid address and some dummy mail & phone)
- Create a customer "IN Cust" (with valid address and some dummy mail & phone)
- Create a product "IN Prod"
	- Sale price: 1000 INR
	- Weight: 100g
	- Set some reference, eg "INPROD"
- Create a Shiprocket delivery method
	- Payment Method: COD
	- Set some "Shiprocket Channel"
	- Enable Debug requests
- In settings, enable "Promotions, Loyalty & Gift Card"
- Go to Sales > Products > Discount & Loyalty
- Create a new program
	- Name: 50% off
	- Program Type: Coupons
	- Change the existing reward to 50% discount on order
	- Generate some coupon
	- Copy the code of the generated coupon
- Create a SO our product and customer
- Use the coupon code & apply the 50% discount
- Add shipping
	- Shiprocket COD
	- Get rate
- Confirm the SO
- Go to the picking & validate it
- Open logs (Settings/Technical/Database Structure/Logging)
- Open the "shiprocket_request_external/shipments/create/forward-shipment" log

--> total_discount is 0

Cause
-----
The problem comes from

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L301

There are 2 issues here.

The first and most important one is how we find the discount lines.

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L320

Discounts from coupons don't use the `sale_discount_product_id`. We can use the `_can_be_invoiced_alone` function to find both regular and loyalty discounts

https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale/models/sale_order_line.py#L1033-L1041
 
    def _can_be_invoiced_alone(self):
        """ Whether a given line is meaningful to invoice alone.

        It is generally meaningless/confusing or even wrong to invoice some specific SOlines
        (delivery, discounts, rewards, ...) without others, unless they are the only left to invoice
        in the SO.
        """
        self.ensure_one()
        return self.product_id.id != self.company_id.sale_discount_product_id.id

https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale_loyalty/models/sale_order_line.py#L50-L51

    def _can_be_invoiced_alone(self):
        return super()._can_be_invoiced_alone() and not self.is_reward_line

We just have to be careful not to accidentally include delivery fees because of

https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/delivery/models/sale_order_line.py#L18-L19

    def _can_be_invoiced_alone(self):
        return super()._can_be_invoiced_alone() and not self.is_delivery

The second issue is that we use the untaxed discount amount.

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L321

This leads to an incoherent total amount, since the tax is computed on the products' full prices. We should instead be forwarding the total discount value (with tax included to offset the taxes applied on the full product price).

-----
Community PR:
https://github.com/odoo/odoo/pull/223517
Ticket:
opw-4755357

Forward-Port-Of: odoo/enterprise#92310

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

Forward-Port-Of: odoo/enterprise#92507

**Issue**
When both a Purchase Order and a Vendor Bill are created using the same individual contact linked to a company, Bill Matching fails with a traceback.

**Steps to Reproduce**
1. Create an individual contact and link it to a company.
2. Create a Purchase Order with the individual as a vendor.
3. Create a Vendor Bill with the same individual as the vendor.
4. Try to perform Bill Matching.
5. A `ValueError: Expected singleton: res.partner(...)` is raised.

Video for reference:
https://drive.google.com/file/d/1qVnPLpk8jyMTKz-6AVLSaN2nVVeWiF4y/view

**Root Cause**
Purchase Orders store the partner exactly as selected (the individual contact), while Vendor Bills are normalized internally to the parent company (`commercial_partner_id`). This creates a mismatch in the Bill Matching logic, where records reference both the individual and the company, leading to an invalid recordset and the singleton error.

**Fix**
Always normalize vendors to their `commercial_partner_id` during Bill Matching. This ensures that both Purchase Orders and Vendor Bills consistently reference the same partner, avoiding mismatches between individual contacts and their parent company.

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

### Steps to reproduce:

- In the settings enable: "Batch, Wave & Cluster Transfers"
- Create 2 deliveries
- Barcode > operations > Delivery orders > Batches > New
- Add your two deliveries and confirm
- Scan WH-Stock
#### > The scan fails considering you scanned each letter independently.

### Cause of the issue:

When the barcode is scanned a call of the split barcode will be launched to split the barcode in multiple barcodes according to the `barcode_separator_regex` present in the config:
https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/static/src/models/barcode_model.js#L613-L632 The issue lies in the fact that even thought the is `barcode_separator_regex` was conrrectly populated at the onWillStart of the mainComponent:
https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/static/src/components/main.js#L209-L213 https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/controllers/stock_barcode.py#L97 https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/static/src/components/main.js#L229 https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/static/src/models/barcode_picking_model.js#L36-L38 It was reset by the batch confirmation here:
https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L123-L135 because this part of the config is not meant to be returned by the private method `_get_barcode_data` but rather by public complete version `get_barcode_data`:
https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/controllers/stock_barcode.py#L91-L98 Now, since no `barcode_separator_regex` was provided to our new config, each character will be considered to be considered as an independent barcodes and the `WH-Stock` barcode will not match any location.

opw-5062331

The issue occurs when the system tries to convert different types of date or date objects into proper python datetime.datetime object but 'date_start' is False in vals at [1]. It might be write when `_plan_workorders` is executed and mrp workorder has not 'leave_id' [2].

The issue occurs when the system attempts to convert various date or date-related objects into a valid Python datetime.datetime object. However, at [1], 'date_start' in 'vals' is False [1]. This may be write when the '_plan_workorders' method is executed and the mrp workorder does not have a 'leave_id' [2].

Link [1]: https://github.com/odoo/odoo/blob/a848c3854c94b5c2b752edddbcf49337acf9d6ea/addons/mrp/models/mrp_production.py#L875

Link [2]: https://github.com/odoo/odoo/blob/a848c3854c94b5c2b752edddbcf49337acf9d6ea/addons/mrp/models/mrp_production.py#L1533-L1536

To resolve this, provide a default date as today if start date is not available

Sentry-6255515427



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