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

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

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

to reproduce:
=============
1. make helpdesk team billable and records timesheets
2. create a helpdesk ticket and link it to a sale order
3. log timesheets on the ticket
4. print the timesheet report **from the sale order** -> the task column will contain only the helpdesk team name, while it should contain "helpdesk team / ticket name"

Problem:
========
in helpdesk_timesheet we inherit `hr_timesheet.timesheet_table` to adapt it to helpdesk tickets, but we use `show_ticket` to display the ticket name, which is only set in `hr_timesheet.report_timesheet` and `hr_timesheet.timesheet_project_task_page` but not in `sale_timesheet.timesheet_sale_page` which is the one used when printing the report from the sale order.

Solution:
=========
`show_ticket` should be set with value `bool(lines.helpdesk_ticket_id)` which is equivalent to `line.helpdesk_ticket_id` in the t-if condition. so we can directly use `line.helpdesk_ticket_id` and remove the `show_ticket` variable.

opw-5002650

Forward-Port-Of: odoo/enterprise#95179

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

to reproduce:
=============
1. make helpdesk team billable and records timesheets
2. create a helpdesk ticket and link it to a sale order
3. log timesheets on the ticket
4. print the timesheet report **from the sale order** -> the task column will contain only the helpdesk team name, while it should contain "helpdesk team / ticket name"

Problem:
========
in helpdesk_timesheet we inherit `hr_timesheet.timesheet_table` to adapt it to helpdesk tickets, but we use `show_ticket` to display the ticket name, which is only set in `hr_timesheet.report_timesheet` and `hr_timesheet.timesheet_project_task_page` but not in `sale_timesheet.timesheet_sale_page` which is the one used when printing the report from the sale order.

Solution:
=========
`show_ticket` should be set with value `bool(lines.helpdesk_ticket_id)` which is equivalent to `line.helpdesk_ticket_id` in the t-if condition. so we can directly use `line.helpdesk_ticket_id` and remove the `show_ticket` variable.

opw-5002650

Forward-Port-Of: odoo/enterprise#95179

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

**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 a traceback occurrs from multiple places when there is no tz for employee and used in the `pytz.timezone` method.

https://github.com/odoo/enterprise/blob/517983ae9deec37795eb11522134a1f5ade31e9b/hr_payroll/wizard/hr_payroll_payslips_by_employees.py#L131

For instance, if there is no tz in resource_calendar_id, it leads to a traceback.

Error: 
```
AttributeError: 'bool' object has no attribute 'upper'
  File "odoo/http.py", line 2364, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1892, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1955, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 137, in retrying
    result = func()
  File "odoo/http.py", line 1922, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2169, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 329, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 727, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 35, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 517, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/web/models/models.py", line 70, in web_save
    self.write(vals)
  File "home/odoo/src/enterprise/18.0/hr_payroll/models/hr_contract.py", line 429, in write
    res = super().write(vals)
  File "addons/hr_work_entry_contract/models/hr_contract.py", line 453, in write
    contract._recompute_work_entries(date_from, date_to)
  File "home/odoo/src/enterprise/18.0/hr_payroll/models/hr_contract.py", line 441, in _recompute_work_entries
    self._recompute_payslips(date_from, date_to)
  File "home/odoo/src/enterprise/18.0/hr_payroll/models/hr_contract.py", line 453, in _recompute_payslips
    all_payslips.action_refresh_from_work_entries()
  File "home/odoo/src/enterprise/18.0/hr_payroll/models/hr_payslip.py", line 601, in action_refresh_from_work_entries
    payslips._compute_worked_days_line_ids()
  File "home/odoo/src/enterprise/18.0/hr_payroll/models/hr_payslip.py", line 1141, in _compute_worked_days_line_ids
    slip_tz = pytz.timezone(slip.contract_id.resource_calendar_id.tz)
  File "odoo/_monkeypatches/pytz.py", line 129, in timezone
    return original_pytz_timezone(name)
  File "__init__.py", line 183, in timezone
    if zone.upper() == 'UTC':
```

To resolve this issue we can give a default value of `UTC` is there is no name. which makes the code more robust.

sentry-6134147853, 6119911834

Currently, an error occurs when computing a display name for stock quant.

Step to produce:

- Install the `stock` module(without demo data).
- Go to inventory settings, enable Packages, Quality, Quality Worksheet, Reception Report, Variants, Units of Measure, Product Packagings, Lots & Serial Numbers, Display Lots & Serial Numbers on Delivery Slips, Expiration Dates, and Dropshipping.
- Disable the Barcode Scanner.
- After that, enable 'Display Lots & Serial Numbers on Invoices' in the Valuation section
- Create a product and enable the 'Track Inventory' option.
- In the product form view, click on On Hand in the breadcrumbs to navigate to the stock quantity list view
- Create a new record to update the quantity.
- Click on the 'View' button, remove the location, and try to come back to update quantity list view.

`TypeError: sequence item 0: expected str instance, bool found`

This error occurs because we compute the display name of stock quant and it is derived from location_id, lot_id, package_id, or owner_id. If none of these values are present in stock quant then the system tries to concate the False (bool) value with a string at [1] and an error occurs.

Link [1]: https://github.com/odoo/odoo/blob/be6b327c17435947fc3f10d30fc8c4730c182aed/addons/stock/models/stock_quant.py#L585-L592

To resolve this issue, Assign a default display name of stock quant if none of the values of fields (location_id, lot_id, package_id, owner_id) are available.

Sentry-6165002037


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

Currently, An error occurs when the user 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

When user edits mail template html and pastes an image tag with invalid encoding it throws an error.

**Steps to reproduce:**
* Install Email marketing and activate developer mode.
* Email marketing>New>Mail Body> Start From Scratch>click `</>` icon
* Paste any improper image element which doesn't have proper base64 encoding, for example: 
`<img src='data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU 5ErkJgg'/>`
* Enter any Subject name and save.

`binascii.Error: Invalid base64-encoded string: number of data characters (113) cannot be 1 more than a multiple of 4`

**Solution:**
* It would be better to let the user know about the error than to let them mass mail corrupted image element.
* This can be done and handled by a try and except statement when the image element  added is not proper.

Sentry-6495526846

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

Foreign key error occurs when a cron job deletes a `withhold (transient model)` 
still linked to a `withhold.line`. The error appears in the terminal, not the UI. 
To reproduce, ensure withhold records in `l10n_ec_wizard_account_withhold` are 
old enough to be removed by `Auto-vacuum`.

Refer to [this](https://github.com/odoo/odoo/blob/e062c9b5773ed0710503c13627e60f8233fcd0a5/odoo/models.py#L7493C1-L7493C87) to understand how transient models are cleaned by the `Auto-vacuum` process.


**Steps to reproduce:**
* Install `l10n_ec_edi` and `accountant`
* Change company to `EC company`
* `Accounting>Customers>Invoices>New`
* Confirm invoice with customer as `EC company` and `Payment method (SRI)` as 
  Credit card
* Add Withhold > Set document number to `001-001-123456789` > Add withhold lines
* `Create and Post`(error will occur when cron tries to delete transient model transient model after
  couple of hours.)

`psycopg2.errors.ForeignKeyViolation:update or delete on table 'l10n_ec_wizard_account_withhold' violates foreign key constraint 'l10n_ec_wizard_account_withhold_line_wizard_id_fkey' on table 'l10n_ec_wizard_account_withhold_line'`

**Solution:**
* Unlink withhold lines first and then let normal unlink take place.

**Sentry-6253783256**

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

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

Currently, a traceback is occurring when the user tries to open a The report contains a subformula in the report expression that does not match.

To reproduce this issue:

1) Install `Accounting`
2) Open the `Profit & Losses` report and open any `line` 
3) Add the subformula as `sum` for any `report expression`
4) Make sure the `Computation Engine` for expression as `Aggregate Other Formulas` 
5) Now open the above report from the `Accounting Reporting`

Error:-
```
AttributeError: 'NoneType' object has no attribute 'groupdict'
```

This error occurs when the user gives a subformula to the engine type `Aggregate Other Formulas`.

Because it tries to match and group the subformula as `currency_1`, `amount_1`, `criterium`.
To do this we need a valid subformula.

https://github.com/odoo/enterprise/blob/0611a56074616bd935b0a9e5e7db98b23d8184f0/account_reports/models/account_report.py#L3007-L3013

When the user gives an invalid subformula, the regex results as None. which leads to the above traceback.

We can resolve this issue by returning unbound_value if the regex is None.

sentry-6325843987