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