When manually changing the tax amount of a vendor bill in the html input field (input above total price), if there is a price difference account move line created, the manual tax inputted will be ignored. This is due to the price difference and associated correcting account move lines having tax_ids. As such, both lines are considered taxable when they should not be and every time we create a price difference line, all taxes are recomputed and manually set tax lines are ignored. This is not the intended behavior because tax for price difference is already accounted for in the tax lines (computed before confirmation of bill) and the price difference lines themselves are just for account balancing and should not be considered taxable.

Steps to reproduce bug on empty DB:
1) Install account and purchase_stock
2) Turn on automatic accounting in settings
3) Create a product category. Set inventory valuation to automated and create and set a price difference account.
4) Create a product. Set the price, set to product category to the created one, and enable track inventory.
5) Create a vendor bill with the product and set a bill date. 
6) Change the price of the product in the bill lines to anything but the original price.
7) Change the tax by clicking on the input field with the pencil icon above amount total to anything but the original tax.
8) Confirm the vendor bill and notice the manually changed tax value revert back to the original value.

Behavior after bug fix:
Upon completing step 8, the manually changed tax value should stay and not be recomputed.

opw-4854669




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

…lues landed cost sbc

**Problem:**
account move line created from a landed cost on a  subcontracted 
receipt do not take into account already out quantity.

**Steps to reproduce:**
- create a tracked product with avco auto category
- create a subcontracted bom for this product with no comp
- create and confirm a PO for 10 unit of this product 
with the same partner as the subcontractor of the bom
- validate the receipt
- create and validate a delivery for 4 unit of your product
- navigate to inventory/operations/adjustments/landed costs
- create a new landed cost
- select the receipt from the PO
- add a landed cost of 10$ and validate
- select the valuation smart button
- a 6$ svl was created (which is correct because 6 out 10 products
of the receipt are still in stock)
- click on the book widget to open the account move view

**Current behavior:**
Only two account move lines were created both with a value 
of 10
One crediting sotck interim received
On debiting stock valuation

**Expected behavior:**
4 extra account move lines (all with a value of 4) should have been 
created to compensate the out quantity like it is the case for 
non subcontracted product.
One debiting stock interim delivered
One crediting stock valuation 
One debiting expenses
One crediting stock interim delivered

**Cause of the issue:**
_is_in() will return false for the move of a subcontracted receipt
https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/stock_landed_costs/models/stock_landed_cost.py#L185
This is wanted and happens because _should_be_valued()
will return true when called on the subcontracted location
https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/stock_account/models/stock_move.py#L129

As a consequence, qty_out stays 0
https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/stock_landed_costs/models/stock_landed_cost.py#L185-L186
and we do not append the values for the extra amls 
inside _create_account_move_line()
https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/stock_landed_costs/models/stock_landed_cost.py#L465-L466

**fix:**
if we make sure the the adjustment line is linked to the move 
of the MO instead of the move of the receipt, this problem does 
not happen because _is_in() returns true for the move of the MO. 
Also in this case we don't need _get_stock_valuation_layer_ids()
which was introduced by this PR https://github.com/odoo/odoo/pull/166107
to solve the same issue. 
That is because the move used in button_validate is the move linked
to the adjustment line, which will, after this fix, be the one of 
the MO, so we can directly take its stock valuation layers.

opw-5723126

Issue Before This Commit:
=======================
In the `batch transfer report`, move lines are ordered by the `picking's batch sequence` (picking_id.batch_sequence). When operators use the document to pick items, they have to scan through the report to find all lines for the same product. As a result, operators `lose time scanning the document` and `risk of missing lines`.

Steps to Reproduce:
=======================
- Install the `stock_picking_batch` module.
- Create `multiple deliveries` with several `common products`.
- Add these deliveries to a batch transfer and print the batch transfer report.
- Observe that product lines are ordered by location and then by picking.

Cause of the issue:
=======================
The batch transfer report currently sorts move lines by picking in the report `(picking_id.batch_sequence)`. When the same product exists in another picking, This causes lines for the same product to be scattered across the report instead of being grouped together, causing the product to appear in multiple places in the document.

After This Commit:
=======================
In the report, move line sorting by picking (picking_id.batch_sequence) has been replaced with sorting by product `(product_id.id)`. Move lines are now ordered by product, so similar products are displayed together in the document. This helps operators find products more quickly, reduces scanning effort, and makes the process more reliable.

TaskID-5379367

# Steps to reproduce:
- Open the company, change the language to Arabic
- Go to POS, open the shop
- Buy anything and click on receipt

# Problem:
When clicking on the receipt, you would find the phone number is written right to left, although it should be printed left to right.

# Cause:
Normally when another language is selected, this line will adapt to it, and translate the whole block "Tel: `props.data.company.phone`" to arabic (right to left)
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml#L12

# Fix:
We need to specify the direction of the phone number to be Left to right.
```
<div>Tel:<span dir="ltr"><t t-esc="props.data.company.phone" /></span></div>
```
**Result:**
<img width="167" height="86" alt="HATEF" src="https://github.com/user-attachments/assets/4fe0bdd0-fe77-430f-9136-cd7086c4d5d9" />

There is also alternative fixes:
# First alternative fix:
Replace the '+' with '00' (there is no difference when trying to copy), and make a function in js that preserve the whole thing in a string variable.
```
    get phoneText() {
        return _t("Tel:") + " " + this.props.data.company.phone.replace("+", "00");
    }
```
**Result:**
<img width="215" height="148" alt="hatef2" src="https://github.com/user-attachments/assets/e9cb4415-baad-4d66-a04b-ecdb308e3e72" />

**Drawback:**
- The inconsistency between how the number is stored and how we view it.

# Second alternative fix:
**File:** `/home/odoo/codebase/odoo/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.js`
```diff
import { _t } from "@web/core/l10n/translation";
import { Component } from "@odoo/owl";
+ import { localization } from "@web/core/l10n/localization";
```
```diff
+    get direction() {
+        return localization.direction;
+    }
```

**File:** `/home/odoo/codebase/odoo/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml`
```diff
                <t t-if="props.data.company.phone">
-                    <div>Tel:<t t-esc="props.data.company.phone" /></div>
+                    <t t-if="direction == 'ltr'">
+                        <div>Tel:<t t-esc="props.data.company.phone" /></div>
+                   </t>
+                    <t t-elif="direction == 'rtl'">
+                       <div><t t-esc="props.data.company.phone" />Tel:</div>
                    </t>
                </t>
```

**Drawback:**
- Too much code for a small issue that probably won't bother the client.
- The need to change in multiple translation files for all RTL languages in odoo.
- Readability


opw-5881503

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

**Issue**:
Validating a receipt with intercompany move, can lead to access right issue

**Steps to reproduce**:
- Create two different companies A and B
- Create an inter company route with two 'pull from' action defined:
	- One from Virtual Locations/Inter-company transit to A/Stock with operation type A: Receipts
	- One from B/stock to Virtual Locations/Inter-company transit with operation type B: Delivery Orders
- Create a product P accessible from both company
- Create a MO (while both company activated with company A selected) for a product that consumes 1 unit P as component and confirm it
- Go to the receipt while only company B activated
- Select a quantity of 1 and validate it 
-> A traceback is displayed

**Cause**:
While confirming the receipt (calling `button_validate`): https://github.com/odoo/odoo/blob/e9a8b81d4a972a57a8f46377864874190b04af2c/addons/stock/models/stock_picking.py#L1403 this will eventually runs:
https://github.com/odoo/odoo/blob/e9a8b81d4a972a57a8f46377864874190b04af2c/addons/stock/models/stock_move.py#L2091 https://github.com/odoo/odoo/blob/e9a8b81d4a972a57a8f46377864874190b04af2c/addons/stock/models/stock_move.py#L2036-L2039 Since self.move_dest_ids belongs to another company, accessing the associated location_id triggers an AccessError.

opw-5177369