Before this commit, waitFor, waitForNone and waitUntil gave the DOM 200 milliseconds, which the loop turns into 12 animation frames, while contains() and expect.waitForSteps sitting in the same tests give 10 seconds. 430 call sites in addons reach these three helpers and 29 pass an explicit timeout, so 12 frames is what the other 401 get.

The problem is that 12 frames is less than what the client needs on a loaded machine. Measured on "should remove file from html editor if removed from attachment list", on the wait that follows the Full composer button:

- 5 to 7 frames on an idle machine;
- 11 to 18 frames over 8 runs with the machine at load 10 to 20, 5 of the 8 above the 12 frames the default allows.

Those 5 are failing runs, and the same test at load 13 to 29 fails 6 runs out of 6 with the 200 milliseconds, 0 out of 6 with 10 seconds.

Note that a longer timeout costs nothing on a green build: the wait ends on the frame the DOM matches, so it only delays the report of a test that was going to fail anyway. Hoot fails the test itself after 5 seconds, 15 in test_js.py, which keeps bounding a wait that never resolves.

This commit raises the default to 10 seconds, the delay a tour step already gets in macro.js and the one contains() and expect.waitForSteps already have.

https://runbot.odoo.com/odoo/error/946094

### Current behavior:
Cash basis tax amounts correctly appear on the Thai Tax Report in the payment month, but missing in the exported Sales Tax Report (xlsx)

### Expected behavior:
Sales Tax Report (xlsx) and Purchase Tax Report (xlsx) should include the same cash basis tax entries as the tax report for the selected period
Cash basis tax amounts should appear the same both on the Thai Tax Return Report as well as in the exported Sales Tax Report (xlsx)

### Steps to reproduce:
1. Install Thai localization and l10n_th_reports, enable Cash Basis
2. Set Output VAT 7% exigibility to Based on Payment
3. Create a customer invoice in June, register/reconcile payment in July
4. Open Tax Report (TH) for July and confirm cash basis amounts appear
5. Export Sales Tax Report (xlsx) (inside the wrench icon)
6. Observe that the cash basis VAT is missing from the Excel file

### Cause of the issue:
When cash basis is enabled, select tax-tagged move lines using the
generic tax report's strict period domain and group Cash Basis Entry lines
under their origin move. Reapply the existing sale, purchase, and reversal
filters and compute move-line amounts only for on-payment taxes. Preserve
the existing accrual behavior.

### Fix:
When cash basis is enabled, include original invoices paid in the selected period via their Cash Basis Entries.
This PR is backporting the fix from https://github.com/odoo/enterprise/pull/75645.
Update should only be from 18.0 to 18.4 

opw-6369332

**Steps to reproduce:**
- Install Accounting, Sales and l10n_pe_edi
- Switch to a Peruvian company (e.g. PE Company)

- Create a SO:
  * Customer: [a Peruvian customer]
  * Order Lines:
    | Product | Quantity | Unit Price |  Taxes  | 
    | ------- | -------- | ---------- | ------- |
    |   any   |   3.00   |   123.50   | VAT 18% |
    |   any   |   2.00   |  27.544216 |  0% Ina |
    |   any   |   1.00   |  43.490867 |  0% Exo |

- Confirm the SO
- Create a 40% down payment
- Confirm the down payment
- Process it to sent it to Peru UBL 2.1

**Issue:**
The following error message is returned by the OSE:
`3272|La base imponible a nivel de línea difiere de lainformación consignada en el comprobante - Detalle: xxx.xxx.xxx ticket : 20260000000000221633458 error: Error en la Linea Nro. :1. : 3272 (nodo: "cac:TaxSubtotal/cbc:TaxableAmount" valor: "148.20")`

**Cause:**
In the XML, one line has 148.19 for "cbc:LineExtensionAmount", but 148.20 for "cac:TaxSubtotal/cbc:TaxableAmount".
The issue is coming from the fact that "base_amount_currency" is used instead of "total_excluded_currency" for the computation of "cac:TaxSubtotal/cbc:TaxableAmount".

**Issue 2:**
When a tax is impacting the base amount of a following tax, its tax amount is not taken into account in "total_excluded_currency".

opw-6235909

Issue:

- DATEV does not support multiple foreign currencies on a single journal line.
- This can occur when reconciling a bank transaction where:
  - the payer uses one currency (C1),
  - the bank journal is held in another currency (C2),
  - the company uses a third currency (C3).
- The existing export logic could not represent the bank liquidity and
  foreign AR/AP currencies separately in such cases.

Fix:

- Detect 3-currency cases from bank statement transactions and their
  liquidity line.
- Use the DATEV clearing account (1360 SKR03 / 1460 SKR04) to split the
  transaction into two logical legs:
  - Bank → Clearing (bank journal currency)
  - AR/AP → Clearing (payer currency)
- Emit the liquidity leg only once when multiple foreign AR/AP lines are
  reconciled against the same bank transaction.
- Keep regular 1- and 2-currency transactions on the existing export path.

Impact:

- Correctly represents 3-currency bank settlements in DATEV.
- Keeps each exported line in a single foreign currency.
- Leaves manual entries and payment transactions outside this specific
  handling, as the scenario is specific to the bank liquidity line.

taskID-5457547

Forward-Port-Of: odoo/enterprise#109010

**Steps to reproduce:**
 - Install l10n_din5008 and accountant.
 - Enable Snailmail from Accounting → Settings.
 - Create a German customer (Fiscal Country: Germany).
 - Create and post a customer invoice using the DIN5008 report layout.
 - Select Send by Post.
 - Enable Developer Mode and navigate to `Settings → Technical → Email → Snailmail Letters`.
- Open the generated letter and send it.

**Current behavior:**
The letter fails to be sent to Pingen with the following error: An error occurred when sending the document by post.
Error: ` The attachment of the letter could not be sent. Please check its content and contact the support if the problem persists.`

**Cause:**
For Snailmail documents, Pingen validates that the recipient address is located within the DIN5008 address window. The current l10n_din5008 report renders additional document information instead of the address in the address area, preventing the compliance validation to fail.

**Fix:**
When rendering the report for Snailmail, ensure that only the recipient address is displayed in the DIN5008 address window while suppressing the additional information that would otherwise occupy this area. This preserves the standard DIN5008 layout for regular reports while generating a Snailmail-compliant PDF that passes Pingen’s validation.

**Reference:** [Pignen Recipient Address Validation Rule](https://help.pingen.com/en/fix-and-enhance-letters/issue-with-recipient-address#040201)

Ticket [link](https://www.odoo.com/odoo/project.task/6387869)
opw-6387869