Version:
----------
- 18.0+


Steps to reproduce:
-------------------
1. Install *quality_control* module.
2. Go to *Settings* and enable *Storage Locations*.
3. Open Quality module go to the Quality control -> Quality points 
4. Create a *Quality Point* with:
  * *Product* set.
  * *Control per* set to *Quantity*.
  * *Operation* set to *Receipts*.
  * *Failure Location* set to *WH/Stock/Shelf1*.
5. Create a *Receipt* with demand of *2 units* for the product used in QP.
6. Mark the quality check as *To Do*.
7. Update the *Done Quantity* to *1*.
8. Open the quality check and click *Fail*.
9. Update the *Done Quantity* back to *2* and save.
10. Open the quality check again, click *Pass*, and validate the receipt.
11. Open the *Detailed Operations* to inspect move lines.

Issue:
------
* Both units (failed and passed) are moved to the *failure location*.

Cause:
------
When a user fails a move line via the QC wizard, the flow is:
  do_fail() → show_failure_message() → confirm_fail()
    → check._move_to_failure_location(failure_location_id, failed_qty)

Inside `_move_to_failure_location`, when `failed_qty == move_line.quantity`,
the condition:
 https://github.com/odoo/enterprise/blob/a33f580455a54a81d89a848f7b493d9dcc9ba2b2/quality_control/models/quality.py#L458
e.g. 1 == 1

was True even when `move.product_uom_qty = 2` (demand still 2). It only
compared the done quantities, ignoring that unfulfilled demand remained.
As a result, `move.location_dest_id` was set to the failure location.

Later, when the user increases the quantity from 1 to 2 on the move form,
the flow is:
_set_quantity → process_increase → _set_quantity_done → _prepare_move_line_vals
In `_prepare_move_line_vals` :
    'location_dest_id': self.location_dest_id.id,

https://github.com/odoo/odoo/blob/47bf284e1e9d8be0d4255418e0a3f67c74fa5114/addons/stock/models/stock_move.py#L1688

The new move line inherits `move.location_dest_id` directly, which at this
point is already the failure location. 

When the user then calls `do_pass()` on the second unit, `do_pass()` only
writes `quality_state = 'pass'` and never touches `location_dest_id`. So
the second (passed) move line silently retains the failure location.

Solution:
---------
Add the guard `move.product_uom_qty <= move_line.quantity` to the condition
so the entire move's destination is only redirected when there is genuinely
no remaining unfulfilled demand:

When demand > done qty, the else-branch runs instead: it reduces the
original move's demand and creates a new separate move pointing to the
failure location, leaving the original move's `location_dest_id` pointing
to stock. Any subsequent move lines created on the original move therefore
correctly inherit the stock destination.

---

opw-6080871

Forward-Port-Of: odoo/enterprise#120175
Forward-Port-Of: odoo/enterprise#112859

**Issue**
In the shop floor, floating-point values may display excessive decimals.

**Steps to reproduce**
- Create a BoM for a product, with a component tracked by lots
- Set the component to be consumed in a work order operation
- Create several lots for the component, per ex 2:
	- LOT01 with 16.528 units
	- LOT02 with 10,000.00 units
- Create an MO for 220.800 units of the finished product
- Click on the shopfloor icon
- Click to register the component consumption for the component.
- Choose the first lot
- Then choose the remaining units from the second lot -> This will display the quantity consumed as 220.79999999999998, even if the decimal accuracy is set to only 2 digits.

**Cause**
Since, there are 2 `moveLines`, one for each lot, the getter `quantityDone` add 2 floating point together: https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L63-L69 
inducing a floating-point precision error.
The result is rendered directly in the XML template: https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.xml#L8-L14 without rounding.

opw-6243804

Forward-Port-Of: odoo/enterprise#118976

Self-order showed one price on product cards / product page and another after adding to the order, when a preset fiscal position (e.g. take-out) changed taxes. The UI used template-only pricing and sometimes skipped fiscal position on tax computation.

Steps to reproduce:
-------------------
* Create a fiscal Position (e.g. takeout)
* Create a Taxe for that Fiscal Positions replacing the default Taxe (e.g. 0%)
* Create a pricelist with a formula increasing the price by the same % as default Taxe (e.g. 15%)
* Enable Self-Ordering for a Restaurant
* In the takeout Presets, set our Pricelist and Fiscal Positions
* Open the Mobile Menu of the Restaurant and add a product that has variants (e.g Pizza VG)

> Observation:
Price on product selection is different from price in cart

Why the fix:
------------
We now make self-order use the same rules as an actual order: default variant for template-only display, pricelist from pos.order first (what setPreset and the session already maintain), fiscal position from the order or the preset everywhere taxes are derived, and correct tax inputs on the product page (price, pricelist, fiscalPosition, variant).
Order line tax preparation now uses that same order-or-preset fiscal position, so remapped taxes apply to lines the same way they apply to the prices shown while browsing.

opw-6120097

Forward-Port-Of: odoo/odoo#261535

Currently when using a stripe terminal and the tips after payment feature the transaction is marked as cancelled while the transaction is marked as uncapured on stripe.

Steps to reproduce:
-------------------
* Set up terminal payment (using SIMULATOR works)
* Enable tips after payment feature
* Open restaurant
* Make an order
* Go to payment screen, select stripe
* Scan card (with simulator everything is automatic)
> Payment line is marked as cancelled

Why the fix:
------------
After this commit https://github.com/odoo/odoo/commit/c27deda808660dde89305d574b6d662157d99d16 if `captureAfterPayment` does not return true the status of the payment line will be set to `retry`.

However when pos_restaurant_stripe is also installed `captureAfterPayment` can return `undefined` when tips after payment is enabled. https://github.com/odoo/odoo/blob/324df67c099ab18c6fe7c8f77212cf809debf383/addons/pos_restaurant_stripe/static/src/overrides/models/payment_stripe.js#L5-L11

In this case we want to capture later and we expect the pethod to not return anything. In this case we don't want to change the status of the payment line.

opw-6223838

Forward-Port-Of: odoo/odoo#268802

# How to reproduce
- Activate Accounting & l10n_be modules with demo data
- Use "BE Company CoA"
- Go to Settings > Users & Companies > Companies > "BE Company CoA" > Branches
- Create new branch company
- Go to Settings and Enable PEPPOL, then save
- Still in Settings, click on "Activate Electronic Invoicing" > Activate Peppol (demo)
- Now use the branch company
- In Settings, click on "Activate Electronic Invoicing", select "Send from parent company" > Activate Peppol (demo)
- Go to Settings > Users & Companies > Users > any user (can be the current one)
- Remove the user's access to "BE Company CoA"
- Log in as that user if it is not the current one
- Create a partner that can receive PEPPOL invoices :
	- Country : Belgium
	- Invoice sending : by Peppol
	- eInvoice format : EU Standard (Peppol Bis 3.0)
	- VAT : BE0477472701
	- Peppol id : Belgian Company Registry
- Create an invoice for that partner
- Click on Confirm, then Send

# The problem
You cannot select the "by Peppol" sending method. It has the "(no access)" error attached to it.

# Cause
The sending method's enable state is computed by : https://github.com/odoo/odoo/blob/c7f05ae216de64d1f8e76e332bc6dd9cf11ce657/addons/account_peppol/wizard/account_move_send_wizard.py#L13

This method runs multiple check to see if the invoice can be send via peppol and one of them calls `_have_unauthorized_peppol_parent_company()` : https://github.com/odoo/odoo/blame/686a0cf67bb1e818baf43309fc94f3f0462097ed/addons/account_peppol/models/res_company.py#L136-L143

This checks that the current user has access to the parent company, which is our exact use case. This specific flow was indeed blocked by the task that introduced branch company PEPPOL invoicing : https://github.com/odoo/odoo/commit/6dd8bc34ba79c14408dc271c19ca7afb0f85fa44

The reason behind this block is in part explained by this comment : https://github.com/odoo/odoo/pull/216864#discussion_r2205047170

But after talking with the Peppol PO, this flow should be allowed

# Proposed solution
Entirely remove the `_have_unauthorized_peppol_parent_company()` check. 
After testing, it does not seem we have any access issues to worry about.

opw-6080867

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

Forward-Port-Of: odoo/odoo#262523

Currently when user adds adds quantity in barcode using lots it leads to incorrect sale order quantities.

## Steps to replicate:
- Install Sales and Barcode (no demo data).
- Enable Lots & Serial Numbers in settings.
- Create Test Product with Tracking by Lots.
- Go to Inventory > Products>Lots & Serial Numbers and create 3 lots for the product.
- Update each lot’s on-hand quantity to 10 from the product page.
- Create and confirm a Sales Order for the product (lines: qty 3 and 2 units).
- Open the delivery in the Barcode app:
   - Scan lot 2 > increase qty to 3 using +1 button
   - Scan lot 3 > increase qty to 2 using +1 button
- Validate and go to the sale order.

## Observed Behavior:
The sale order delivered quantities are flipped and a backorder is created even though the quantity for the product is satisfied.

## Root cause:
The issue occurs because when a sales order is confirmed, the system defaults to
 using lot 1 on the delivery receipt. When a user scans lot 2, the `_processBarcode` function is triggered, which calls `_findLine` at [1] to select the appropriate line on the receipt.

As the loop in `_findLine` iterates through `pageLines` with values like: 
```
[{display_name: "Test product", quantity: 3, lot_id: { name: 'lot1' }}, 
{display_name: "Test product", quantity: 2, lot_id: { name: 'lot1' }}]
```

During the first iteration, `foundLine` is set at [2] for the line with quantity 3 . Since the subsequent if condition is not satisfied, the loop hits the continue block at [3].
On the next iteration, the line with quantity 2 causes `foundLine` to be overwritten at [2], and the continue block is executed again at [3].

This results in the line with quantity 2 being selected as the line to update at the end of the function.

When the user manually increases the quantity to 3, the line that originally required quantity 2 is updated and fulfilled.
Later, when lot 3 is scanned, the line that required quantity 3 is selected for update, and manually increasing the quantity to 2 before validating the order leads to a backorder and causes the delivered quantities to be flipped.

[1]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1335-L1337 [2]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1690-L1699 [3]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1727-L1729

## Solution:
Avoid grouping lines from different moves unless using batch transfers. This ensures that backorders are not created when the barcode lines are fulfilled.

opw-5423943

Forward-Port-Of: odoo/enterprise#119164
Forward-Port-Of: odoo/enterprise#109032

[FIX] ai: scope AI_ADJUST_SEARCH bus event to originating session
The AI_ADJUST_SEARCH handler did not check aiSessionIdentifier, so any
browser tab subscribed to the bus would apply the AI's resulting search
to its current view. When the view's model lacked a field referenced in
the response (e.g. an "Active or Queue" filter on stage_id leaking from
a project.task chat into a timesheet view), the view raised a KeyError.
Align it with the four AI_OPEN_MENU_* handlers, which already drop events
from other sessions since https://github.com/odoo/enterprise/commit/d85e17d9ccf70f9cfd51c7d6b2a5b52510807484.

Steps to reproduce:
- Run Odoo with the crm and contacts modules installed
- Open two tabs:
    - Tab 1: navigate to CRM and ensure you are in List view
    - Tab 2: navigate to Contacts and ensure you are also in List view
- In Tab 1 (CRM), open the Ask AI chat and type "Switch to Kanban view"
- CRM switches to Kanban view as expected
- Bug: Tab 2 (Contacts) also switches to Kanban view along with Tab 1,
  even though you did not interact with it

Forward-Port-Of: odoo/enterprise#119325
Forward-Port-Of: odoo/enterprise#118237

**Steps to reproduce:**
* Install `l10n_co_edi` module with DEMO DIAN mode enabled.
* Go to Accounting > Vendor > Bills and create a new bill.
* Select any Colombian partner different from `Consumidor Final`.
* Set the invoice date to 6 days in the past.
* Select the DIAN Support Documents journal and a product with UNSPSC category.
* Confirm the bill and click `Send Support Document to DIAN` after 5 PM Colombia time.

**Observed behavior:**
* An error is raised stating the issue date cannot be older than 6 days or more than 6 days in the future, even though the invoice date is within the allowed window in Colombia local time.

**Cause:**
* The date window validation in `_check_move_configuration` used `fields.Datetime.now()` which returns UTC time. Since Colombia is UTC-5, after 5 PM local time the UTC clock has already rolled over to the next calendar day, making a 6-day-old invoice appear 7 days old and failing the validation incorrectly.

**Fix:**
* Convert the current UTC datetime to the `America/Bogota` timezone and extract its local date before computing the allowed date window.
* Compare directly against `move.invoice_date` (a `date` field) instead of using `fields.Datetime.to_datetime()`, keeping the comparison consistent as `date` vs `date`.

opw-6011502

Forward-Port-Of: odoo/enterprise#120216
Forward-Port-Of: odoo/enterprise#115256

Currently, the system restricts fiscal document types for both sales and 
purchases based on the company’s VAT affiliation, which prevents 
valid vendor bills from being recorded.

**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a `GT company`.
- Navigate to Accounting > Vendors > Bills.
- Create a vendor bill.
- Try to select a document type such as `FPEQ` or `FCAP`.

**Observation:**
The system hides valid vendor document types (e.g., `FPEQ`, `FCAP`) 
if they do not match the company’s VAT affiliation.

**Root Cause:**
At [1], the method `_compute_l10n_gt_edi_available_doc_types` 
filters document types using the company’s VAT affiliation 
(`l10n_gt_edi_vat_affiliation`) for all move types.

This logic is correct for sales (where the company is the issuer), 
but incorrect for purchases (where the vendor determines the document 
type). As a result, valid purchase document types are wrongly excluded.

**Fix:**
This commit updates the computation logic to:
- Apply affiliation-based filtering only for sales (`out_*`).
- Bypass the restriction for purchases (`in_*`), allowing all valid document types.

This ensures that vendor bills can include any legally valid document 
type regardless of the company’s affiliation, while preserving the 
existing restrictions for sales workflows.

[1]:
https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/l10n_gt_edi/models/account_move.py#L162-L166

opw-6099863

Forward-Port-Of: odoo/enterprise#120363
Forward-Port-Of: odoo/enterprise#113133