Steps to reproduce:
----------------------------------------
1. Install `industry_fsm_sale` and `base_automation` modules
2. Create a product with:
    * Type: Service
    * Create on order: Task
    * Project: Field Service
3. Create an automation rule with:
    * Model: Sales order
    * Trigger: Incoming message
4. Create and confirm a sale order with this product
5. Add another product to the SO via the catalog view:
    * Change the quantity to 2 or more

Observation:
----------------------------------------
Traceback occurs:
```
  File '/home/odoo/src/odoo/addons/base_automation/models/base_automation.py', line 871, in _message_post
    message_sudo = message.sudo().with_context(active_test=False)
AttributeError: 'bool' object has no attribute 'sudo'
```

Root Cause:
----------------------------------------
* Catalog qty change calls `set_fsm_quantity()` method
* Setting `fsm_quantity` triggers its inverse `_inverse_fsm_quantity()`, which writes the new qty to the SOL, but passes `fsm_no_message_post=True` in context to suppress chatter noise
https://github.com/odoo/enterprise/blob/ac5d670832a5e0db714c0bd056e1406b50bb4c17/industry_fsm_sale/models/product_product.py#L72-L83
* `sale.order.line.write()` detects a qty change on a confirmed order and calls `_update_line_quantity()`, which posts a message on the parent sale order
* FSM's `message_post` override sees the context flag and returns `False`
* When `base_automation` has an `on_message_received` rule on `sale.order`, it wraps `message_post` at registry load time. That wrapper calls `sudo()` on whatever `message_post` returns, Which was `False`

Solution:
----------------------------------------
Return `self.env['mail.message']` (empty recordset) instead of False, it's still falsy, but it's a proper ORM object that `sudo()` can be called on

opw-6276916

Forward-Port-Of: odoo/enterprise#119542

Issue
-----
When validating a delivery in a different company from the main one, the commercial invoice's number field is incorrect, which raises an error on DHL end.

`content/exportDeclaration/invoice/number: expected type: String, found: Boolean`

Steps to reproduce
-----
- Create a Belgian company
- Setup DHL
	- DHL Product D - Express Worldwide
	- Dutiable Material enabled
- Create an amrican customer
- Deliver a product to the american customer

> Validation Error

Cause
-----
The field is populated in

https://github.com/odoo/enterprise/blob/cf3c2fce8a6b7b2d7547d44a0e4423f887986d52/delivery_dhl_rest/models/dhl_request.py#L204

The problem is that `next_by_code` uses the company found in the env, whereas the sequence's company is the main one, so it is not found when doing

https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/odoo/addons/base/models/ir_sequence.py#L287

-----
Ticket:
opw-6171886

Forward-Port-Of: odoo/enterprise#118379

### Steps to reproduce:

- In the settings enable: "Storage Locations" and "Consignment"
- Create a storable product and put 1 unit in stock with a set owner
- Go to the barcode app > Operations > Delivery Orders > New
- Scan your product and validate
#### > The owner was not set on the stock move line so that a new quant was created and updated in stock rather than using the available unit.

### Cause of the issue:

The mechanism of prefilling an owner or a package in the barcode app is currently gate-kept behind the existence of a lot name: https://github.com/odoo/enterprise/blob/0be4f71de3420fb9b72fd4e70d48c6cbbbc0ecb4/stock_barcode/static/src/models/barcode_model.js#L1382-L1407
However, the option also make sense for none tracked products.

### Note:

Performing the flow form the backend and adding quantity will generate the move line by setting the owner if possible since the quantity of a move is set via the back end, move lines are generated by looking at the existing quant data's:
https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L2364 https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L2328-L2330
Setting the same owner on the new move line as on the quant we are going to reserve:
https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L2337 https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L1715

Additional subtelties appearing when prefilling for non tracked product:

1. Currently the available quantity is not taken into account to determine if the the value provided to the prefilled is actually
relevant, in particular if there is a quant with an available quantity of 0, it will be used as a valid value to prefill and it will parasit the prefill that could be done by other quants.

2. The location source used to determine the quants taken into account is not set on the first scan since the scan is performed without any existing line:
https://github.com/odoo/enterprise/blob/4f0d25f9fe4ca8ff1b0ecd7900899a2a246ba888/stock_barcode/static/src/models/barcode_model.js#L1387
> This was not problematic with respect to tracked product since the product needs to be scanned prior to the lot, hence there is always a current line when the the lot is scanned.

opw-6050657

Forward-Port-Of: odoo/enterprise#121996
Forward-Port-Of: odoo/enterprise#115021

### Steps to reproduce:
- Download 'Sales' and 'Timesheets' apps
- Create a service product invoiced on delivered quantities with timesheet tracking
- Create and confirm a SO for quantity 1
- Log 20h on timesheets
- Invoice the SO
- Create a credit note for 11 hours => only 9 hours are invoiced
- Log 5h more on timesheets
- Back to the SO > create invoice again
> All the 25hrs are to invoiced, although 9 of them were invoiced before

### Cause of Issue:
When generating the new invoice, `_recompute_qty_to_invoice` calls `_get_delivered_quantity_by_analytic` which retrieves the analytic values for the SO line.

The values retrieved are later used to determine the delivered quantity, which is later assigned to be `line.qty_to_invoice` without taking into account the already invoiced hours. https://github.com/odoo/odoo/blob/7a6518e39d34575a3977e7c4a0053a45223e203c/addons/sale_timesheet/models/sale_order_line.py#L176-L186

### Fix:
Ensures that hours that have already been completely invoiced are deducted from the quantity to invoice.

opw-6253650

Forward-Port-Of: odoo/odoo#273156
Forward-Port-Of: odoo/odoo#268025

On a mo that has byproducts, if you unreserve, it will also set the quantity of byproducts to 0

Steps to reproduce:
-------------------
* Create a Products main, component and byproduct
* Create a bom for main with component as component and byproduct as byproduct
* Create and confirm a mo for main
* Set qty_producing to quantity ot produce
* click on "Unreserve" (do_unreserve)
* click on "Check availability"  (action_assign)
* Produce All
-> the byproducts will not be produced.

 Observation:
-------------
When updating the qty_producing value it will also update the quantity of the byproducts moves:
https://github.com/odoo/odoo/blob/77b180e8251fb8019e0034e1c2f485fd2c34ea4e/addons/mrp/models/mrp_production.py#L892-L893
https://github.com/odoo/odoo/blob/77b180e8251fb8019e0034e1c2f485fd2c34ea4e/addons/mrp/models/mrp_production.py#L1350
https://github.com/odoo/odoo/blob/77b180e8251fb8019e0034e1c2f485fd2c34ea4e/addons/stock/models/stock_move.py#L2382
The quantity on the byproducts move has been updated.

When clicking on Unreserve it will call do_unreserve,
https://github.com/odoo/odoo/blob/aca2e226143487b421f79194d677bb48d5da1358/addons/mrp/models/mrp_production.py#L2297-L2298
It will filters the moves that do not need to be unreserved and select the others:
https://github.com/odoo/odoo/blob/aca2e226143487b421f79194d677bb48d5da1358/addons/stock/models/stock_move.py#L900
and it will unlink all the sml from the moves:
https://github.com/odoo/odoo/blob/aca2e226143487b421f79194d677bb48d5da1358/addons/stock/models/stock_move.py#L919
Which will set the quantity on the byproduct moves to 0.

When Producing all (button_mark_done) since the qty_producing has already been set, it will simply mark the byproduct move has picked.
https://github.com/odoo/odoo/blob/aca2e226143487b421f79194d677bb48d5da1358/addons/mrp/models/mrp_production.py#L1323-L1324

In our case, this means that the no byproducts will be created since, the quantity was previously set to 0

opw-6296562

Forward-Port-Of: odoo/odoo#272216

Currently when the user reverts an inventory adjustment move line with a package the package contains extra line showing negative quantity of the product.

## Steps to produce:
- Install Inventory without demo data
- Settings Enable 'Packages'
- Create a product:
   - Cheese burger
   - On hand > Create a new quant
   - Package: 'Burgerbox' and 'On Hand Quantity`: 1 and save
- Set the On Hand quantity to zero and save
- History > Revert the Inventory adjustment line from WH/stock to Inventory adjustment by selecting it and reverting via actions.
- Products > Packages > BurgerBox

## Observed Behaviour:
After reverting an inventory adjustment that set the product's physical quantity to 0, the package contains two lines for the same product with quantities 1 and -1.

This is inconsistent because a package should not contain a product with a negative quantity.

The package should be restored to its original state and contain only the expected positive quantity.

## Root cause:
When the user reverts the move line, `action_revert_inventory` is called. This method creates the revert move and then marks that move as done at [1].

Marking the move as done subsequently marks all related move lines as done at [2]. During this process, the system first unreserves the quantity from the virtual location / inventory adjustment and then removes the quantity from that location (resulting in a -1 quantity move line at that location). This is performed through `_synchronize_quant`, which is responsible for synchronizing the physical inventory with the move line at [3].

The `_synchronize_quant` method uses the move line's `package_id` when updating the corresponding quant at [4]. As a result, `_update_available_quantity` creates a new quant with the following values at [5]:
```
{
    'product_id': 1,
    'location_id': 14,
    'lot_id': stock.lot(),
    'package_id': 1,
    'owner_id': res.partner(),
    'in_date': datetime.datetime(2026, 6, 22, 12, 42, 11),
    'quantity': -1.0,
}
```
This creates a quant with a negative quantity that is linked to the package because `package_id` is set on the newly created quant. Consequently, the move line with the negative quantity becomes associated with the package.

[1]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move_line.py#L1016-L1035 
[2]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move.py#L1956 [3]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move_line.py#L662-L666 
[4]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move_line.py#L678-L687 
[5]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_quant.py#L1130-L1143
## Solution:
Remove the source `package_id` when creating revert moves for inventory adjustment locations.

When an inventory adjustment sets a product's quantity to 0, the adjustment is completed without a destination package, meaning the product is effectively removed from the package. Therefore, the corresponding revert move should not retain the package as its source. Keeping the package as the source is inconsistent because package information should not exist on a virtual inventory adjustment location, and the original inventory adjustment removes the product from the package (there is no destination package).

By removing the source `package_id` from the revert move, the system avoids creating negative quants associated with the package during quant synchronization. This also ensures that, after the inventory adjustment is reverted, the quantities of products inside the package are restored correctly and match their state prior to the adjustment.

opw-6285739

Forward-Port-Of: odoo/odoo#273632
Forward-Port-Of: odoo/odoo#271440

**Steps to reproduce:**

- Make a product with a category
- In the category, make the inventory valuation to automated
- Set the income and expense account
- Set a cost for the product
- Make a fiscal position and set it as default for the PoS
- In the Account Mapping tab, map the income and expense to two other accounts
- Go to the PoS
- Make a sale for that product, without invoice
- Close the session and in the backend check the session
- Check the journal entries
- The income account has been mapped to the fiscal position's
- The outcome account stayed the same as in the category's

**Why the fix:**

When we invoice an order, the income and expense accounts are immediately updated, in a different place than if it has not been invoiced.

At the session's closure, we update the accounts for every order that hasn't been invoiced. In this flow, the account mapping defined on the fiscal position was not applied, so we took the one defined on the product's category.
The income account was already mapped as we need to do it earlier than the session closure, so it had already been set as the right one before our flow. For the expense account, we only need it at this specific time, so we can map it as the session's closure.

We now map the account depending on the fiscal position if we are able to find one, otherwise, we use the category's default as we did before.

opw-6171677

Forward-Port-Of: odoo/odoo#266700

Backport of : https://github.com/odoo/odoo/pull/269057 to  V18 
When an international customer selects an in-store pickup location, the
order's fiscal position changes to the fiscal position matching the pickup
warehouse. However, the order-line taxes and checkout summary are not
recomputed immediately.


**Steps to reproduce:**

1. Configure a French company and website.
2. Configure a product priced at 100  ( just an example , any price will do ) EUR excluding 20% French VAT.
3. Configure an export fiscal position removing VAT for Japan.
4. Configure an international delivery method.
5. Configure an in-store pickup method with a warehouse located in France.
6. Checkout using a Japanese delivery address.
7. Select the international delivery method.
8. Switch to pickup in store.

**Current behavior:**

- The order fiscal position changes to the French fiscal position.
- Product-line taxes and the checkout summary remain based on the export
  fiscal position.
- French VAT only appears later on the payment step.
- Switching back to international delivery can similarly leave stale totals.

**Expected behavior:**

- Selecting the French pickup location immediately applies French VAT.
- Switching back to international delivery immediately removes French VAT.
- Totals displayed during delivery selection match the payment-step totals.

**Cause:**

The Click & Collect flow explicitly recomputes `fiscal_position_id` when
selecting or leaving an in-store pickup location, but it does not recompute
the order-line taxes and prices.

Additionally, the pickup-location route does not return updated order-summary
values, so the checkout page cannot refresh its displayed totals.

**Solution:**

- Recompute taxes and prices when the in-store fiscal position changes.
- Restrict the recomputation to draft website orders.
- Return the updated order summary after selecting a pickup location.
- Refresh the checkout summary using the returned values.

**Tests cover:**

- Japanese delivery with export fiscal position and no VAT.
- Switching to a French pickup location immediately applying 20% VAT.
- Switching back to international delivery removing VAT.
- Delivery-step totals matching payment-step recomputation.
- Pickup-location route returning updated summary values.

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

Forward-Port-Of: odoo/odoo#269086