When computing taxes for invoice lines, the system should use the `invoice_label` field instead of the default `name` field to display tax information. This allows invoices to show more appropriate tax labels that may differ from the internal tax name.

Technical details:
- Added `is_invoice` context when calling `tax_ids.compute_all()` in `account.move.line._compute_all_tax()` method
- Modified `account.tax.compute_all()` to check for `is_invoice` context and select appropriate field name (`invoice_label` for invoices, `name` for other documents)
- The selected field name is used when building the tax values dictionary
  returned by `compute_all()`

This change ensures that invoice tax lines display the correct label as defined in the tax's `invoice_label` field, which is particularly useful for localized tax reporting requirements where the invoice label may differ from the internal tax name.


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

Problem: If a customer ends up returning their subcontracted products and then creates a second return to receive the products again the received quantity on the purchase order line updates correctly. However, if they return the second receipt, then it increases the received quantity on the purchase order line instead of decreasing it.

Purpose: This will allow a customer to process a chain of returns for subcontracted products while keeping the received quantity correct.

I have removed the check for origin_returned_move_id because of the
return for an exchange workflow in Odoo 18.0. This field does not get
set because the exchange moves should be independent of their origin moves.

Steps to Reproduce on Runbot:
1. Create a purchase order for a subcontracted product.
2. Validate the receipt on the purchase order.
3. Return the receipt and validate it.
4. Create a return of the previous return and receive the products again.
5. Create a return of the return from the previous step and validate it.
6. Observe the received quantity on the purchase order line increased instead of decreasing after step 5.

opw-4839366

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

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/ae6422403 [REL] 17.0.84 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/eb07d192c [IMP] xlsx: export clip [Task: 5368130](https://www.odoo.com/odoo/2328/tasks/5368130)
https://github.com/odoo/o-spreadsheet/commit/3afa12f85 [IMP] export: export align left when the cell content is a number; [Task: 5368130](https://www.odoo.com/odoo/2328/tasks/5368130)

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>

this PR is a backport of https://github.com/odoo/odoo/pull/226809

**Problem:**
When we do a downpayment on an invoice then pay the rest and do
a credit note, the credit note does not reverse the cogs

**Steps to reproduce:**
- create a storable product invoiced on ordered quantity
- set the category of the product as avco and "inventory valuation"
of the category as automated
- set an onhand quantity and a positive cost
- create a SO for 1 quantity of this product and confirm
- click on create invoice, select downpayment percentage and 25%
- click on create draft and confirm it
- click on create invoice, select regular, create draft
- confirm and select credit note
- write something in the reason field and click on reserve
- confirm it

**Current behavior:**
if you open the "Journal Items" page of the credit note you'll
see that there is no line revresing the cogs (there would be if
 we didn't do a downpayment but invoiced all at once)

**Expected behavior:**
There should be:
- A line crediting "600000 Expenses" (or the account that was
debited for the cogs on the original invoice) with the amount
being the cost of your product.
- A line debiting "110300 stock interim (delivered)"(or the
account that was credited for the cogs on the original invoice)
with the amount being the cost of your product.

**Cause of the issue:**
Since this commit https://github.com/odoo/odoo/pull/163251/commits/d7b0510908d341c205461ca18b1730c93b88e445
(slightly modfified for efficieny reasons by this commit https://github.com/odoo/odoo/pull/186486/commits/b819ee9570faa17ea143a1b924bce995ded89f6f),
when _stock_account_prepare_anglo_saxon_out_lines_vals is called
on the account move (the credit note) it calls _get_anglo_saxon_price_ctx.
https://github.com/odoo/odoo/blob/20d96c54b795b8d617776afe9877fb5c6632c666/addons/stock_account/models/account_move.py#L116
One of the invoice lines of the account move is linked via
sale_line_ids attribute to a sale order line that is a downpayment.
As a consequence, inside _get_anglo_saxon_price_ctx,
move_is_downpayment will be populated with this line.
https://github.com/odoo/odoo/blob/20d96c54b795b8d617776afe9877fb5c6632c666/addons/sale_stock/models/account_move.py#L136-L139
Then _stock_account_prepare_anglo_saxon_out_lines_vals
calls _stock_account_get_anglo_saxon_price_unit.
https://github.com/odoo/odoo/blob/20d96c54b795b8d617776afe9877fb5c6632c666/addons/stock_account/models/account_move.py#L133

Inside this method, because move_is_downpayment is populated,
is_line_reversing will stay false
https://github.com/odoo/odoo/blob/20d96c54b795b8d617776afe9877fb5c6632c666/addons/sale_stock/models/account_move.py#L173-L174

As a consequence,
- qty_to_invoice will become - qty_to_invoice
- account_move will be populated
- therefore posted_cogs will be populated
https://github.com/odoo/odoo/blob/20d96c54b795b8d617776afe9877fb5c6632c666/addons/sale_stock/models/account_move.py#L176-L184
So _compute average price will be called with a qty_invoiced
of 1 instead of 0 and a qty_to_invoice of -1 instead of 1.
So it will return 0 instead of the cost of the product because
"missing" will be negative.
https://github.com/odoo/odoo/blob/20d96c54b795b8d617776afe9877fb5c6632c666/addons/stock_account/models/product.py#L842

**fix**
The use case of this commit https://github.com/odoo/odoo/pull/163251/commits/d7b0510908d341c205461ca18b1730c93b88e445 is this one :
- SO for qty of 10 (product invoiced on delivered qty).
- 100% downpayment.
- deliver 6.
- invoice.
In that case the invoice is actually a credit note but
it still has to include the cogs (not reversed),
so move_is_downpayment needs to be populated

However in our use case the cogs has to be reversed
(so move_is_downpayment has to be None).
One difference between those two use case is that in
our use case the account move has a reversed_entry_id.

opw-5423517

Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that:
```javascript
return childLocation.parent_path.includes(parentLocation.parent_path);
```
The issue with that is, if locations' id are aligned, they can match even if they are not related.

For example, imagine tested child location has ID 127 and the parent location has ID 7, we then check their `parent_path` (for example, '4/127/' for the child location and '7/' for the parent location), it can happen the child parent path can include the parent's parent path (in our example, '4/127/' includes '7/'.)

To fix that, this commit replaces `includes` with `indexOf`, the result of the `indexOf` should always be 0 if the child location is indeed a sublocation of the parent location.

Because of this issue, the second run of the tour `test_put_in_pack_new_lines` could sometime fail when the locations IDs are aligned.

runbot build error: [233292](https://runbot.odoo.com/odoo/runbot.build.error/233292)

Forward-Port-Of: odoo/enterprise#104350