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:
- send an image in a Discuss channel
- click the image to open the file viewer
- click the download button

=> Android shows "The Odoo Mobile Apps only supports file downloads
   using the HTTP protocol."

downloadFile()'s GET-by-URL case fetches the URL via XHR, then saves the Blob response by clicking a hidden <a download> anchor on a blob: URL. Android's DownloadManager only accepts http(s) URLs, so it rejects that blob: URL instead of downloading anything.

Patch downloadFile._download to hand the URL directly to a new mobile.methods.saveFile bridge method when available, the same way download._download already delegates to mobile.methods.downloadFile.

Blob/string content downloads aren't handled here — the only such call site (spreadsheet JSON export) is debug-mode only, so this is left as a console.warn for now.

Related to odoo/odoo@e83fd8c08c879f5e262d39f24edcb3f81238ea82

Code made by Claude
Changes supervised by HUVW

Forward-Port-Of: odoo/enterprise#128471
Forward-Port-Of: odoo/enterprise#127693

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