**Step to reproduce :**

1. Create Product A and enable lot tracking for it.
2. Create a Kit product and add Product A as one of its components.
3. Go to PoS and create orders using:
  - Product A
  - The Kit product
  - A combination of Product A and the Kit product
4. Create three different orders with these combinations.
5. Try to close the PoS session.

**Issue :**

An error occurs when attempting to close the PoS session.

The issue is in the pos_mrp module, specifically in the _get_lot_line_qty method. When accessing the following line:

`lines_data[move.bom_line_id.bom_id.product_tmpl_id.product_variant_id.id]['order_lines'].qty`

we expect order_lines to contain a single record. However, in this scenario, multiple order lines can be returned for the same product. As a result, accessing .qty directly on order_lines raises a singleton error.

**Solution :**

With this fix, we first retrieve the quantity from each order line and thensum the quantities together.

This ensures that multiple matching order lines are handled correctly and prevents the singleton error when closing the PoS session.

opw-6442765

## **Steps to reproduce:**
1. Install the Inventory and Purchase module and enable Multi-Step Routes.
2. Open the Buy route and set Company A as its company.
3. Create a user who has access only to Company B.
4. Log in as this user and navigate to Products.
5. Click New to create a product.
6. An AccessError is raised because the Buy route belongs to Company A, which is not accessible to the user.

## **Issue:**

The buy route returned by `env.ref` is not necessarily applicable to the current company. Returning `buy_route.ids` directly can therefore cause issues when creating a product in a multi-company environment.

When the user has access to multiple companies, the buy route belonging to another company can be selected during product creation. When the user does not have access to the company of the buy route, this can instead result in an AccessError.

The previous implementation performed an ORM search on `stock.route`, which implicitly filtered the route according to the current environment. However, that query was removed as part of this pr https://github.com/odoo/odoo/pull/276554.

## **Solution:**

Filter the route returned by env.ref against the companies available in the current environment before returning its ID.

Use sudo() while filtering so that the route's company_id can be read even when the route belongs to a company inaccessible to the current user. The route is still explicitly checked against env.companies, so sudo() does not allow an inaccessible company's route to be returned.

opw-6448497

Runbot Video : [Video](https://drive.google.com/file/d/1qQyJrPNwXuHtu6GXyC_78dtd_A24khFR/view?usp=sharing)

### Issue before this commit:
When applying a discount to a down payment invoice, the discount is not reflected on the corresponding down payment line in the Sale Order. This missing information leads to an incorrect tax computation when generating the final regular invoice.

### Steps to reproduce the issue:
1. Download Sales
2. Go to settings and check discounts
3. Create a 0% tax
4. Create a new quotation with a product, set for example 1000 as unit price and a tax of 15% and confirm it
5. From the SO click 'Create invoice' and create a downpayment with a fixed amount of price 500, 0% tax and 2.5% discount
6. Go back to the SO and see that the discount is not reported also here in the sale order view
7. Than click 'Create invoice' again and select regular invoice to complete the payment
8. See that the tax amount is incorrect

### Cause of the issue:
The system does not synchronize the discount applied on the posted down payment invoice line (account.move.line) back to the originating down payment line on the Sale Order (sale.order.line). Since the Sale Order line lacks this discount data, subsequent computations rely on incomplete values.

### Reason to introduce the fix:
To ensure accurate tax computations and complete financial consistency between the Sale Order and the related invoices. By correctly retrieving and assigning the discount from the posted invoice line to the down payment line, the final regular invoice can accurately calculate the remaining amounts and applicable taxes.

opw-6334838

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

Currently, debit notes are incorrectly reported to the Egyptian Tax
Authority (ETA) as standard invoices with document type `i`.

**Steps to reproduce:**
- Install the `l10n_eg_edi_eta` and `account_debit_note` modules and 
  switch to the EG company.
- Configure the `Egyptian ETA settings` for the sales journal.
- Create and confirm an invoice for an Egyptian customer.
- Click the gear icon > `Debit Note` and create a debit note.
- Add invoice lines to the debit note and confirm it.
 (Click `Process Now` if needed).
- Open the `EDI Documents` tab and click `Download`.

**Observation:**
The generated XML payload contains `documentType` set to `i`.

**Expected behaviour:**
According to the Egyptian Tax Authority (ETA) eInvoicing SDK, debit notes
must be identified with document type `d`.
(reference: https://sdk.invoicing.eta.gov.eg/documents/debit-note-v1-0/)

**Root Cause:**
At [1], the `documentType` logic does not handle debit notes, causing them 
to be reported as standard invoices (`i`).

opw-6471998