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

Steps to reproduce:
- Go to Website
- Upload an image in the company logo (navbar)
- Open the website editor and click on the logo
- Open the image info panel

Current behavior:

When clicking on the website logo in the editor, the size shown is always a constant number ~5.9kB, regardless of the actual size of the uploaded logo. The correct size is visible in the browser DOM. This gives users the wrong impression that their image is being heavily compressed or losing quality when it isn't.

Reason:

When clicking the logo, the editor tries to find the original, unprocessed version of the image so it can support cropping and other edits. It does this by asking the server to match the image's URL to a stored attachment.

The website logo is served through a dynamic link
(`/web/image/website/<id>/logo/<name>`) that isn't tied to a regular attachment record the way normal content images are, since it isn't uploaded through the usual media picker. Because of this, the server can't find a matching original, and the editor is left without a valid image source to work with.

As a fallback, the editor tries to load a placeholder path instead of a real image. This request fails and silently resolves to Odoo's generic "image not found" placeholder. All further processing (and the size calculation) then happens on this small placeholder image instead of the actual logo, which is why the size shown never changes.

Fix:

When `get_image_info` does not return a usable `original`, `loadImageInfo` now falls back to using the image's own current src as `originalSrc`, instead of leaving it unset. This ensures `loadImage` always receives a valid, resolvable URL, so image processing (and the size shown) reflects the actual logo.

opw-6260496

Forward-Port-Of: odoo/odoo#276733
Forward-Port-Of: odoo/odoo#273542

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#276555

## Problem

When generating an export CFE (e-Factura Exportación) in the Uruguayan EDI module, invoices that include a discount line equal to the subtotal — resulting in a **total of 0.00** — were not handled correctly by the XML/CFE generation
logic.

This use case is valid and required by exporters who need to reflect the declared value of goods/services while invoicing at zero (e.g. to comply with customs or incoterm requirements such as FCA). In Uruware's validation portal, the "Descuentos y Recargos" (discounts & surcharges) section of the subtotal block must be correctly populated for the CFE to be accepted.

**Example:** An invoice with a line of 648.00 UYU and a global discount of −648.00 UYU → Total: 0.00. The export value is still declared, taxes are zero, but the CFE must reflect the discount amount explicitly.

<img width="592" height="679" alt="example_expo_invoice_discount" src="https://github.com/user-attachments/assets/aa83c158-e342-4da5-a251-fc209bbed5c4" />

## Root Cause

The CFE template (`cfe_template.xml`) and the move computation logic (`account_move.py`) did not account for the case where export invoices carry line-level or global discounts that zero out the total. The discount amount was
either omitted from the XML nodes or computed incorrectly, causing Uruware validation to fail or the discount block to not render.

## Fix

- **`l10n_uy_edi/models/account_move.py`** — Updated the export invoice computation to correctly include discount amounts in the CFE data dict, ensuring the `ValorDR` is filled with the value of the discount per line.
- **`l10n_uy_edi/views/cfe_template.xml`** — Adjusted the template condition so `MntExpoyAsim` node accepts 0 as value.

## Steps to Reproduce (before fix)

1. Create an export invoice (e-Factura Exportación) for a foreign partner.
2. Add a product line with a unit price, e.g. 216.00 × 3 = 648.00 UYU.
3. Add a global discount of 648.00 (same amount) so the total is 0.00.
4. Confirm and send to Uruware — the CFE is rejected / discount block is missing.

## Verification

After the fix, the same invoice generates a valid CFE accepted by Uruware with the discount correctly reflected in the `DscRcgGlobal` node and the discount line visible on the printed document.

Forward-Port-Of: odoo/enterprise#120130

Steps to reproduce:
---------------------------------------
1. Install Subscription Module
2. Create and Confirm SO with no recurring plan and a non-recurring product
3. Add a recurring product > Save SO > Observe the User Error
4. Now add the same recurring product through Catalog View

Observation:
---------------------------------------
No User Error raised stating
'You cannot save a sale order with recurring product and no subscription plan.'

Issue:
---------------------------------------
When you manually add a line and click 'Save', the constraint (`_constraint_subscription_plan`) is triggered and raised `UserError` https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/sale_subscription/models/sale_order.py#L176-L177

When you add a product via the catalog view, it calls `_update_order_line_info` which directly creates/updates order lines, Which do not trigger the python constraint.
https://github.com/odoo/odoo/blob/ef9772bba1515bdaf5410c3af5a3e395f562d513/addons/sale/models/sale_order.py#L1926-L1933

Solution:
---------------------------------------
Two private helpers are introduced:
* `_is_exempt_from_subscription_plan_check`: single source of truth for all exempt states (draft, cancelled, upsell, and legacy upgrade orders).
* `_check_recurring_plan_mismatch`: raises a `UserError` when the order has or will have a recurring product but no subscription plan, reusing the exemption helper so both call sites stay in sync.

`_constraint_subscription_plan` is refactored to delegate to these helpers, and `_update_order_line_info` is overridden to call `_check_recurring_plan_mismatch` before the catalog update is applied, ensuring consistent validation across both entry points.

opw-6194865

Forward-Port-Of: odoo/enterprise#123216
Forward-Port-Of: odoo/enterprise#117879

### 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#124017
Forward-Port-Of: odoo/enterprise#115021

Before this commit, _compute_l10n_be_computed_seniority looped over cp200_versions but still read self.employee_id and self.l10n_be_scale_seniority, so when Odoo batched multiple CP200 versions together, the whole recordset was passed to _get_first_version_date(), crashing with a singleton error.

After this commit, the loop correctly uses version.employee_id and version.l10n_be_scale_seniority instead.

Traceback (important part):

```py
    File "/home/odoo/src/enterprise/l10n_be_hr_payroll/models/hr_version.py", line 1508, 
  in _compute_l10n_be_computed_seniority                                                 
      company_seniority = relativedelta(fields.Date.today(),                             
  self.employee_id._get_first_version_date()).years                                      
                                                                                         
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                                             
    File "/home/odoo/src/odoo/addons/hr/models/hr_employee.py", line 621, in             
  _get_first_version_date                                                                
      versions = self._get_last_consecutive_versions(date_limit)                         
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                         
    File "/home/odoo/src/odoo/addons/hr/models/hr_employee.py", line 595, in             
  _get_last_consecutive_versions                                                         
      self.ensure_one()                                                                  
    File "/home/odoo/src/odoo/odoo/orm/models.py", line 5406, in ensure_one              
      raise ValueError("Expected singleton: %s" % self)                                  
  ValueError: Expected singleton: hr.employee(30, 1)           
  ```

task-6377630

Forward-Port-Of: odoo/enterprise#123753

## Context

When generating a CFE (Comprobante Fiscal Electrónico) that contains both a configured addenda (e.g. bank account details stored in `l10n_uy_edi_addenda_ids`) and terms & conditions from the invoice's `narration` field, the resulting addenda string could end up with unnecessary blank lines between the two sections, causing the addenda to be rendered on a separate page even when the logical content fits within the 6-line threshold.

## Root Cause

`_l10n_uy_edi_get_addenda` joins both parts without stripping whitespace from either of them first, and adds two lines between addendas and terms and conditions:

         addenda = addenda + "\n\n" + term_and_conditions if addenda else term_and_conditions

Two sources independently introduce extra newlines around the separator:

1. **Addenda content** — `_get_legends` returns the raw `content`  field value of each addenda record. These fields commonly end  with a trailing `\n`, so the addenda string already ends with a newline before the `"\n"` separator is concatenated.
2. **`html2plaintext`** — the `narration` field is stored as HTML. When converted to plain text, `html2plaintext` typically wraps paragraph content in leading/trailing newlines.

The combination of the trailing `\n` from the addenda, the explicit `"\n\n"` separator, and the leading/trailing `\n` from `html2plaintext` produces 2–3 consecutive newlines, which `splitlines()` counts as blank lines. 
A realistic 4-line addenda + 1-line narration thus produces **7 lines** instead of the expected 5, crossing the 6-line threshold in `_get_report_params` and triggering `adenda=true` — which forces the addenda onto a separate page unnecessarily.

## Steps to Reproduce

1. Configure a `l10n_uy_edi.addenda` record of type `addenda` with multi-line content (4 lines)
2. Create and confirm an invoice with `narration` set to a short  single-line term 
3. Generate the CFE PDF via Uruware.
4. Observe that the addenda is rendered on a separate page despite the logical content being only 5 lines.

<img width="1042" height="448" alt="image" src="https://github.com/user-attachments/assets/b538211c-5f37-4648-979d-99cd75cf31c2" />


## Fix

Strip leading and trailing whitespace (including newlines) from both parts before joining them. The ternary is also replaced with an explicit `if/else` for clarity:

    def _l10n_uy_edi_get_addenda(self):
        addenda = self.l10n_uy_edi_document_id._get_legends("addenda", self)
        if self.narration:
            term_and_conditions = html2plaintext(self.narration).strip()
            if addenda:
                addenda = addenda.strip() + "\n" + term_and_conditions
            else:
                addenda = term_and_conditions
        return self._l10n_uy_edi_clean_non_ascii_chars(addenda)

This guarantees exactly one `\n` separator between sections regardless of how the content fields were stored or how `html2plaintext` formatted the narration.

The threshold logic in `_get_report_params` is unchanged: addendas that genuinely exceed 6 lines (after wrapping at 140 chars) continue to be printed on a dedicated page.

Result
<img width="1117" height="456" alt="image" src="https://github.com/user-attachments/assets/3a2d942c-8c37-40f6-bc25-470c0bd25b08" />

Forward-Port-Of: odoo/enterprise#119283

To reproduce the issue:

1) Create a company in Belgium
2) Instantiate its returns and review, submit and pay one of the VAT returns 3) Change the states_worklfow of the VAT return so that it only accepts "review" and "submit" stages, not "paid" anymore 4) Go to the list of returns, remove the TODO filter => traceback

The problem is here that the existing returns don't recompute their state when the workflow of the type is modified. In some cases, this is fine, but it others, it's annoying. In our example, the terminal state changed, so all the returns in that terminal stage should change their state to the new terminal one. "paid" is not an accepted value anymore, it should become "submitted".

Moreover, when the workflow is changed, the selection field actually containing the state must also change. As it is, it seems to work because "state" of account.return is stored, but the value it's based on (the workflow field) won't be consistent with it. It's not annoying now, but those inconsistencies could become a big source of trouble in the future (we know that from experience ... I'm looking at you, version 8 ! è-é).

This issue typically happens at upgrade. We had cases in FR and AE already. We solve that by a generic override of the write to sort things out when such change needs to happen. An upgrade PR will also be done to adapt the script so that we eventually solve the inconsistencies on dbs that have already migrated to 19.0.