Currently, an error occurs when generating the `IRAS Audit File` for 
a `Singapore` company

**Steps to reproduce:**
- Install the `l10n_sg_reports` and `accountant` modules (without demo data).
- Create a new company with Singapore as the `country` and set `UEN` and `GST No.`, 
  then switch to this company.
- Navigate to Accounting > Reporting > Singapore > IRAS Audit File.
- Fill in the required details and click `Generate`.

**Error:**
`TypeError: 'account.account' object is not callable`

**Root cause:**
After the refactoring in PR [1], the code at [2] mistakenly calls `browse()` 
without arguments and then attempts to call the returned recordset with 
`line_account_ids`. Since `browse()` already returns a recordset, this results 
in calling an `account.account` recordset as a `function`, causing an `error`.

**Fix:**
This commit prevents an error during IRAS Audit File generation by correcting 
the `browse()` call to pass `line_account_ids` directly as its argument.

[1]:
https://github.com/odoo/enterprise/pull/72675

[2]:
https://github.com/odoo/enterprise/blob/444f120fbd4e7158b83c609ededf1b2598fc990f/l10n_sg_reports/models/iras_audit_file.py#L210

opw-5877947

*= account_bank_statement_import_csv

An exception is currently triggered when a user attempts to import a bank
transaction file containing more than 80 transaction lines (see ref file [1]).

Steps to produce an error:
- Install `Accounting (accountant)` module
- Go to `Accounting` > Click on `Bank` > Click `Upload`
- Upload  ref file [1] and click `Test/Import` >>> Error occurs

Error: `psycopg2.errors.SerializationFailure: could not serialize access
due to concurrent update`

Error from 19.0: `InvalidSavepointSpecification : savepoint "ef05b579-df3f
-11f0-bc75-74563c5c983f" does not exist`

The issue occurs because, in `model.py` code line [2] creates a `savepoint`.
Before this `savepoint` is closed, code line [3] is triggered during the
creation of the bank statement line [4] and attempts to commit the
cursor using `self.env.cr.commit()`. Because a commit is executed while
the savepoint is still active, the system fails when trying to close the
previously created savepoint.

This commit fixes the issue by avoiding cursor commits during the import
process. The `import_file=True` flag is added to the context when
`_cron_try_auto_reconcile_statement_lines` is called from `execute_import`,
allowing the method to safely skip commit/rollback logic when
`import_file` is present in the context.

[1]: https://docs.google.com/spreadsheets/d/19hKnR8pGB27xkbEHgYYXIkBaPXV8RZZE/edit?usp=sharing&ouid=111844484867458262929&rtpof=true&sd=true
[2]: https://github.com/odoo/odoo/blob/11c469086cb4d08453a70cd7bd30d7391f635ae3/odoo/orm/models.py#L971-L973
[3]: https://github.com/odoo/enterprise/blob/2683b77cd6688877c308d0733bccfc5ad84530c1/account_accountant/models/account_bank_statement.py#L218
[4]: https://github.com/odoo/enterprise/blob/2683b77cd6688877c308d0733bccfc5ad84530c1/account_accountant/models/account_bank_statement.py#L1780

sentry-6974536471
opw-5359810

Forward-Port-Of: odoo/enterprise#102760

Refactored the logic to generate the Kardex report based on `stock.valuation.layer`, for the following reasons:

1. **Landed costs**: These must be considered in the report. Odoo already creates valuation layers for landed costs, and the report must use the date when the landed cost was recorded, not the original stock move date.
2. **Price adjustments**: Product price adjustments generate valuation layers without stock moves. These layers are now included in the report.

Additional fixes and improvements:

- Correctly map columns 18 to 26 in Report 13.1:
  - 18–20: Incoming movements
  - 21–23: Outgoing movements
  - 24–26: Final balance
- Ensure `cost_in` and `cost_out` values are always positive. The sign now depends on the movement quantity, not the unit cost.
- Replace the product list with a dictionary to track accumulated quantities and values per product for accurate balance calculation.
- Extend test coverage to include cases where the report includes opening balances due to past transactions.
- **MRP movements**: MRP processes don’t generate pickings, but their stock moves are linked to operation types. The report now uses codes `19` for incoming and `27` for outgoing MRP-related movements.
- **Reversal of pickings**: Since Odoo copies the original picking and skips reassignment logic, we now override the reversal wizard to set the correct PE operation type:
  - `25` for incoming reversals
  - `24` for outgoing reversals
- Force operation type `99` for all `A1` lines, as required by the report.
- Ensure report dates are processed in the user's timezone for consistency with the layer view in Odoo.

Forward-Port-Of: odoo/enterprise#88592

Behavior before:
When generating tax returns, accounting entries linked to tax group accounts were included in the calculation even if they were in draft or cancelled state. As a result, tax returns displayed incorrect amounts.

Behavior after:
Tax return amounts now correctly match the values shown in the corresponding reports. Entries in draft or cancelled state are excluded, eliminating discrepancies in tax return calculations.

Root cause:
The domain used in the _add_line method did not filter entries based on their parent_state. This caused all related accounting entries—regardless of their posting status—to be included in the calculation.

Steps to reproduce:

1. Create accounting entries using an account that is part of a tax group.

2. Set the entries to draft or cancelled state.

3. Generate a tax return for the current period.

4. Observe that amounts from draft or cancelled entries are included in the tax return.

OPW: 5417293

Forward-Port-Of: odoo/enterprise#106101

## Issue
When changing the *Target Frequency* of a commission plan, previously created periods are not removed.

## Steps to reproduce
1. Install *Sale Commission* (`sale_commission`)
2. Create a *Commission Plan*. The default *Target Frequency* (`periodicity`) should be *Quarterly*. In the *Periods* tab, 4 periods (`targets`) are present.
3. Change the *Target Frequency* to *Monthly*
4. **New monthly periods are added, but the quarter periods are not removed**

This behavior leads to a second issue:

5. Following the previous steps, set the current user as a Salesperson the *Sales People* tab
6. Approve the Commission Plan
7. Create an invoice
    - Any customer
    - Add a product with a price of $100
    - Confirm the invoice
8. Go to Sales > Commissions > My Commissions
9. **The invoice impacted multiple commission targets, because the current period is covered multiple times (by the monthly and the quarterly frequencies)**

## Cause
This issue was introduced by https://github.com/odoo/enterprise/commit/e7693f3c61044f689da87218235cd985e26f75d5. The commit aimed to preserve periods when updating the *Effective Period* of a commission plan. In fact, in some cases, it is unnecessary to delete all periods because some of them belong to both the previous and the updated effective period.

https://github.com/odoo/enterprise/blob/2dd98eed0559b6217ef8467f1d56c171d546b85b/sale_commission/model/commission_plan.py#L106-L108

When updating the *Target Frequency* of a commission plan, the *Effective Period* is unaffected, making the `target_changes` list empty. This leads to none of the periods being deleted, eventhough they don't respect the new periodicity.

## Fix
The condition to add periods to the `target_changes` list needs to updated, as it needs to also take in account the periodicity of the commission plan. The `expected_target_duration` needs to be a range, as it depends on the (variable) length of the months that are concerned. These ranges were chosen by looking at the sizes of each period. A margin of one day is added for the "year" case to handle leap years.

<img width="687" height="367" alt="5877405" src="https://github.com/user-attachments/assets/065b0d21-0860-4435-9f9b-55feef789da6" />

## Test
The test `test_commission_target_constraint` was using the fact that the periods were not deleted when updating the periodicity to test against the creation of overlaps between periods. As this is no longer possible, the test was updated.

opw-5877405

Forward-Port-Of: odoo/enterprise#105813

The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request [83499](https://github.com/odoo/enterprise/pull/83499) added rounding precision for these PACs.

Now, the remaining PAC (Solution Factible) appears to the same requirement. This commit ensures that the previous bug fix is applied to all PACs.

[opw-5165200](https://www.odoo.com/odoo/project.task/5165200)

## Steps to reproduce:

[Setup](https://drive.google.com/file/d/1BUkNG-Ezk-I47yvbNolOmlj0ne1iqDto/view?usp=sharing)
1. Navigate to Apps and install l10n_mx_edi.
2. Switch to any of the Mexican companies that appear.
3. Navigate to Accounting > Configuration > Currencies.
4. Click into the USD currency.
5. Change the current rate to be 20.101796407186 MXN per USD. (inverse_company_rate field).
6. Navigate to Accounting > Configuration > Settings, and set the PAC to Solution Factible.

[Workflow](https://drive.google.com/file/d/11TFZ78QGDYdnD9R3CoJDAuFI-1_0dNyG/view?usp=sharing)
1. Navigate to Accounting > Customers > Invoices.
2. Select New to create a new invoice.
3. Add a mexican customer (such as XENON INDUSTRIAL ARTICLES).
4. Add the 45 day Payment terms. This should change the payment policy to PPD.
5. Change the currency to USD.
6. Add the product FURN_8220 (or any with the unspsc_code_id set).
7. Set the unit price of the product to 58968.29.
8. Confirm the invoice.
9. Select Send & Print, then ensure that the CFDI option is selected before clicking Send & Print again.
10. Select Register Payment, then Confirm Payment.
11. Select the Update Payments smart button.
12. Navigate to the CFDI tab; there will be a "Payment Send in Error" line.

Forward-Port-Of: odoo/enterprise#105412
Forward-Port-Of: odoo/enterprise#102557