The module behaves in an unexpected way:

- Tax is based on a customer's home address,
- To calculate tax a customer must be selected,
- Tax is calculated as if shipped from the warehouse selected on pos_warehouse_id

This could be useful in very obscure scenarios (B2B sales, traveling salesmen), but for those cases customers can already use our Avatax integration on sale orders.

We want this module to be useful for normal B2C POS sales. Taxes they charge are the same regardless of where the customer may live. This commit makes many changes:

- Stop requiring a customer to be selected,
- Always calculate local sales (from company location to company location) if the Avatax option is enabled on pos.config,
- Fix a bug where price_subtotal is not multiplied by quantity,
- Removes copy/pasted code from sale.order that serves no purpose,

This makes the module useful for companies that don't want to manually figure out what taxes to charge. This could be especially useful for companies with many shops in different locations.

A tour test was added to make sure the module keeps working. The test added before [1] was removed because it was redundant and less complete than the one included here.

This is deliberately not backported to Odoo 18 [2]. We keep the current behavior there.

[1] https://github.com/odoo/odoo/commit/3e94fe90ded58d498f0098cd9ed8679cbe500b8f

Closes odoo/enterprise#82779

task-4710463

Forward-Port-Of: odoo/enterprise#124778
Forward-Port-Of: odoo/enterprise#123190

**Steps to reproduce:**
- create storable avco product
- set the cost to 10 
- set an onhand quantity of 100 in WH/stock
- create another warehouse (if you don't already 
have another one)
- create an internal transfer from WH/Stock 
to WH2
- open the 'stock' view 
- click on inventory at date 
- confirm

**Current behavior:**
the total value is 11.000

**Expected behavior:**
total value should be 10.000

**Cause of the issue:**
To compute the total_value of the product, 
_compute_value calls _run_average_batch
https://github.com/odoo/odoo/blob/68f258e99f42693131a5309b3606c3b95f93d824/addons/stock_account/models/product.py#L260
Inside run_average_batch we need the qty_available 
at the time of last manual value (which is when 
we set the cost to 10 manually) in order to value 
all this quantity at the value of the manual value.
https://github.com/odoo/odoo/blob/68f258e99f42693131a5309b3606c3b95f93d824/addons/stock_account/models/product.py#L435

This qty should be 0 cause we had no onhand quantity 
when we set the cost to 10. 
But it's actually going to be 10, here is why : 

Inside _compute_quantities_dict, because we're 
asking for a quantity in the past, the computation is 
current quantity - quantities that went in between 
the date in the past and now + quantities that went 
out between the date in the past and now. 
https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/product.py#L255
So we should have : 100 - 100 (moves_in_res_past) + 0 
(moves_out_res_past) = 0
because we have 100 now and between the date 
we're asking for (the time of the manual value) and 
now there is one move in (when we set a quantity of 100) 
and no move out.

But moves_out_res_past will actually be 10 for our product
instead of 0. 
That's because in the read_group, our internal move 
will be considered as a move out and be taken into account 
https://github.com/odoo/odoo/blob/60cf607d7148ebe389cc8513aa3b82e156cd4400/addons/stock/models/product.py#L233-L234

That's because: 
When we called _run_average_batch from 
_compute_value, we called it on 'products_to_value', 
which is based on 'products', which was computed 
calling with_valuation_context() 
https://github.com/odoo/odoo/blob/60cf607d7148ebe389cc8513aa3b82e156cd4400/addons/stock_account/models/product.py#L206
which passes the valued internal location in the context
https://github.com/odoo/odoo/blob/60cf607d7148ebe389cc8513aa3b82e156cd4400/addons/stock_account/models/product.py#L366-L370
As wh2 is not internal (it's a view) it's not included in the locations 
from the context.
strict is also set to True

Therefore at the beginning of compute_quantities_dict, 
when we call _get_domain_location to compute 
domain_move_out_loc (on which domain_move_out_done 
will be based),
https://github.com/odoo/odoo/blob/60cf607d7148ebe389cc8513aa3b82e156cd4400/addons/stock/models/product.py#L165
inside _get_domain_location, because a location is 
given in the context that's the one we're going to use. 
https://github.com/odoo/odoo/blob/60cf607d7148ebe389cc8513aa3b82e156cd4400/addons/stock/models/product.py#L365
and because strict is in the context, dest_location_domain_out
will be "location_dest_id not in [the list of valued location 
which does not include wh2]".
https://github.com/odoo/odoo/blob/7e95d32d669a7ee7c50b5e665697cb577be0af93/addons/stock/models/product.py#L402-L405
And back in compute_quantities_dict(), 
domain_move_out_loc will be "location_id in [the list 
of valued location] and location_dest_id not in 
[the list of valued location]".
Our internal move will therefore be considered 
as an out move and taken into account in the computation
mentioned above.

Which explains why quantity will be 10 inside 
run_average_batch and why the computation 
of total_value is wrong

**fix:**
in 19.0 the fix is in the xml to take less risk 
with regards to stable policy, however starting 
from 19.1 the fix will be in python
opw-6321636

Forward-Port-Of: odoo/odoo#275384
Forward-Port-Of: odoo/odoo#273388

Backport of b667cacb (odoo/odoo#276156), currently on master.

The guards of mark as read were only evaluated when requesting it, while the RPC itself goes through a sequential queue. A mark as read requested while another one was still in flight was thus executed later without any re-validation.

Under CI load, the bus sync of a previous mark as read can lag enough for a focus-triggered mark as read to legitimately pass its guards on stale state and be queued. When the user then clicked "Mark as Unread", the queued mark as read executed right after and reverted that explicit action on the server, and through the resulting bus push, on the client as well. In the meeting view tour, the unread badge of the Chat action then never showed "1":

    FAILED: [17/24] Tour discuss.meeting_view_public_tour
    Step .o-mail-Meeting [title='Chat']:has(.badge:contains(1))

The state guards are now re-validated when the queued call actually executes: the member must still exist, the messages must not have been read in the meantime, and the channel must not have been marked as unread since the call was requested. The newest persistent message is still captured at request time as it is the payload of the intent: messages that arrived later have not been validated as read by the caller, their own triggers request another mark as read when appropriate.

https://runbot.odoo.com/odoo/error/941491

Forward-Port-Of: odoo/odoo#276664
Forward-Port-Of: odoo/odoo#276555

Steps to reproduce:
-------------------
- Install `mrp` and `sale_management` modules
- Enable Units of Measure from settings
- Create a storable product configured as a Kit:
  - Set UoM to Units
  - Add component and it's UoM in Kg in Product form.
- Create and confirm a Sales Order with the kit product
- Validate the generated delivery order
- Print the delivery slip

Issue:
------
The delivery slip correctly displays component quantities in Kg,
but also shows an additional converted quantity in Units (e.g., 1000 Units),
which is incorrect and misleading.

Cause:
------
During sale order confirmation, the following flow is executed:
`action_confirm → _action_confirm → _action_launch_stock_rule → _prepare_procurement_values`

In `_prepare_procurement_values`, the `packaging_uom_id` is set from the
sale order line UoM (Units) and propagated to the generated stock move:
https://github.com/odoo/odoo/blob/647febbf46160c000bf11af8325cc80d0916eb67/addons/sale_stock/models/sale_order_line.py#L296

When the delivery (picking) is created, kit components generate stock moves where:
- `product_uom` is defined in the component’s UoM (e.g., Kg)
- `packaging_uom_id` remains in Units (inherited from the sale order line)

While generating the delivery slip, `_get_aggregated_product_quantities`
computes `packaging_quantity` using `packaging_uom_id`:
https://github.com/odoo/odoo/blob/647febbf46160c000bf11af8325cc80d0916eb67/addons/stock/models/stock_move_line.py#L888

In Mrp this calls the template:
`stock_report_delivery_aggregated_move_lines`
https://github.com/odoo/odoo/blob/647febbf46160c000bf11af8325cc80d0916eb67/addons/mrp/report/report_deliveryslip.xml#L60


In this template, a condition renders packaging quantities when
`packaging_uom_id` differs from `product_uom`. As a result, quantities are
converted from the component UoM (Kg) into the packaging UoM (Units).

https://github.com/odoo/odoo/blob/647febbf46160c000bf11af8325cc80d0916eb67/addons/stock/report/report_deliveryslip.xml#L261

For kit components, this conversion is not meaningful and leads to incorrect
values (e.g., Kg → Units resulting in 1000 Units), causing misleading output
in the delivery slip.

Fix:
----

Add a `_compute_packaging_uom_id` override in `sale_mrp` and
`purchase_mrp` that resets `packaging_uom_id` back to
the component's own `product_uom` whenever the move originates from a
phantom BoM line, without touching `sale_line_id`/`purchase_line_id`
themselves.

<details>
  <summary>Click here to see the results:</summary>

  <p><strong>Before:</strong></p>
  <div class="image-row">
    <img src="https://github.com/user-attachments/assets/5d8b2154-d794-4ce4-90a6-1a0aeaca8604" />
  </div>

  <p><strong>After:</strong></p>
  <div class="image-row">
    <img src="https://github.com/user-attachments/assets/79d708de-19e3-452d-9033-322a297c38e9" />
  </div>
</details>

---

opw-6136928

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

Forward-Port-Of: odoo/odoo#277015
Forward-Port-Of: odoo/odoo#262705