The following commit resets qty_invoiced to zero on sale order lines paid by a POS order when that order is refunded.
https://github.com/odoo/odoo/commit/ac39aa4f68dfc77011c39e468e3f60e0338a3c69

However, it does not handle the sale order line created for a refunded POS down payment. That line keeps `qty_invoiced` = -1, which causes the refunded amount to be included again when settling or invoicing the sale order.

Steps to reproduce:
- Create a sale order.
- Pay a down payment through the POS.
- Refund the down payment order from the POS.
- Settle the remaining amount from the POS or invoice the sale order from the backend.

Result:
- The generated invoice includes the sale order total plus the refunded down payment.
- Sale order `amount_invoiced` will be the down payment amount.

Fix:
- Delete the refunded downpayment to match the sale flow.
- Include refunded down payments in the amount_invoiced computation.

opw-6378891

Forward-Port-Of: odoo/odoo#283308
Forward-Port-Of: odoo/odoo#278011

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/d34d0e73d9 [REL] 19.1.32 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/b34d534e9d [FIX] inputs: explicitly define border-style [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/4396cc1cbe [FIX] filter_menu: take number of headers into account when sorting [Task: 6471792](https://www.odoo.com/odoo/2328/tasks/6471792)
https://github.com/odoo/o-spreadsheet/commit/ea70823de1 [IMP] claude: add gitignore for claude local settings [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/cb6ac6156b [FIX] toLocaleString : new helper to use the locale's decimal separator [Task: 6232818](https://www.odoo.com/odoo/2328/tasks/6232818)
https://github.com/odoo/o-spreadsheet/commit/0792c4f799 [FIX] toLocaleString : new helper to use the locale's decimal separator [Task: 6232818](https://www.odoo.com/odoo/2328/tasks/6232818)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

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