### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/b9d68c1fc8 [REL] 19.2.26 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/7fdd5324de [FIX] inputs: explicitly define border-style [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/e7a0ae142b [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/8de418d0aa [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/13723bb889 [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/07de2a90c3 [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>

Steps to reproduce:
-------------------
1. Install `stock` module.
1. Enable the "Storage Locations" from setting.
2. Create an internal location and enable `replenish_location` on it and set warehouse(WH) as Parent.
3. Create a storable product track by quantity with no on-hand quantity.
4. Create an internal transfer from the warehouse stock location to the new internal location.
5. Confirm the transfer.
6. Open the Replenishment report.

Issue:
------
No manual reordering rule is created for the product at the source location, although 
the confirmed transfer makes its forecasted quantity negative.

If `replenish_location` is disabled on the destination, the expected reordering rule is created.

Cause:
------

When both the source and destination have `replenish_location=True`, Odoo considers both locations 
inside the same replenishment area. Therefore, the internal transfer is not counted as either
incoming or outgoing, and no replenishment is created for the source location.

Code Flow: 

Opening the Replenishment report calls
`stock.warehouse.orderpoint.action_open_orderpoints()`, which delegates the report preparation to `_get_orderpoint_action()`:

https://github.com/odoo/odoo/blob/12a66c6931d81e1cce18f676836aca0b32090d16/addons/stock/models/stock_orderpoint.py#L324-L326

`_get_orderpoint_action()` first obtains every location that must be monitored for replenishment through `_get_orderpoint_locations()`:

https://github.com/odoo/odoo/blob/12a66c6931d81e1cce18f676836aca0b32090d16/addons/stock/models/stock_orderpoint.py#L520

`_get_orderpoint_locations()` returns all locations whose `replenish_location` field is enabled:

https://github.com/odoo/odoo/blob/12a66c6931d81e1cce18f676836aca0b32090d16/addons/stock/models/stock_orderpoint.py#L799-L800

All these locations are passed together to
`product.product._get_domain_locations_new()`:

https://github.com/odoo/odoo/blob/12a66c6931d81e1cce18f676836aca0b32090d16/addons/stock/models/product.py#L396-L464

This method treats the provided locations and their descendants as a set. Its move domains are equivalent to:

- incoming: destination is inside the set and source is outside;
- outgoing: source is inside the set and destination is outside.

Consider the following sibling locations:

    WH
    ├── Stock
    └── Replenish Location

and the transfer:

    Stock -- 3 units --> Replenish Location

When `replenish_location` is disabled on the destination, the considered location set contains only `Stock`:

    considered location set = {Stock}

The source is inside the set and the destination is outside:

    source inside       = True
    destination outside = True

The transfer therefore matches the outgoing domain:

    source inside AND destination outside
    True          AND True
    = True

It is included in `moves_out`, and the preliminary forecast for `Stock` becomes:

    0 on hand + 0 incoming - 3 outgoing = -3

https://github.com/odoo/odoo/blob/12a66c6931d81e1cce18f676836aca0b32090d16/addons/stock/models/stock_orderpoint.py#L552

The negative quantity is detected and a manual orderpoint is created.

When `replenish_location` is enabled on the destination, both sibling locations belong to the considered location set:

    considered location set = {Stock, Replenish Location}

Both ends of the transfer are now inside:

    source inside       = True
    destination inside  = True
    destination outside = False
    source outside      = False

The transfer matches neither aggregate domain:

    incoming:
    destination inside AND source outside
    True               AND False
    = False

    outgoing:
    source inside AND destination outside
    True          AND False
    = False

The transfer is considered internal to the considered location set and is therefore absent from both `moves_in` and `moves_out`:

https://github.com/odoo/odoo/blob/12a66c6931d81e1cce18f676836aca0b32090d16/addons/stock/models/stock_orderpoint.py#L530-L540

This aggregate treatment conflicts with the next step, where `_get_orderpoint_action()` computes the quantity separately for each replenishment location:

https://github.com/odoo/odoo/blob/12a66c6931d81e1cce18f676836aca0b32090d16/addons/stock/models/stock_orderpoint.py#L549-L552

When `Stock` is evaluated separately, the internal transfer has already been discarded. Its calculated outgoing quantity is consequently zero:

    0 on hand + 0 incoming - 0 outgoing = 0

As the quantity is not negative, the product is not scheduled for the final `virtual_available` computation and no manual orderpoint is created.

Fix:
----
Also retrieve moves whose source and destination are both inside the aggregate replenishment-location set.

Include these internal moves in both the incoming and outgoing grouped queries. The existing per-location path filtering then assigns each side correctly:

- the source replenishment location counts the move as outgoing;
- the destination replenishment location counts it as incoming.

For the reported transfer, this produces:

    Stock:
    0 on hand + 0 incoming - 3 outgoing = -3

    Replenish Location:
    0 on hand + 3 incoming - 0 outgoing = 3

This is correct because the report creates replenishment propositions per location, even though the initial move query is performed for all replenishment locations together.

---

opw-6462608


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

Forward-Port-Of: odoo/odoo#282168

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

Forward-Port-Of: odoo/enterprise#128741
Forward-Port-Of: odoo/enterprise#122310