Purpose:
This module links the `point_of_sale` module with the `l10n_gt_edi` module. It is required in Guatemala to comply with Guatemalan Point of Sale legislation.

Before this commit:
- POS orders had no default customer.
- Invoices generated for unidentified customers exceeding the legal threshold, leading to SAT rejections after submission.
- GT Phrases configured on company were missing on the invoices generated through POS causing the electronic document to be rejected by SAT.

After this commit:
- Consumidor Final is set as the default customer on POS orders.
- POS invoices cannot be generated for unidentified customers when the total exceeds the legal threshold (currently Q2500).
- GT phrases configured on the company are now applied to POS invoices, ensuring valid electronic document submission to SAT.

Technical Details:
- Added a configurable legal threshold field on POS configuration.
- Added validation to block invoicing when an unidentified customer exceeds the configured threshold.
- Added a missing `super()` call in `l10n_mx_edi_pos` to ensure proper method chaining when multiple POS localizations are installed.

related PR https://github.com/odoo/odoo/pull/242985

task-4393614

Forward-Port-Of: odoo/enterprise#103767

We had a bug when selling event tickets in POS where tickets with seats_max set to 0 (which should mean unlimited) appeared as sold out when the event had seats_limited enabled.

Steps to reproduce:
-------------------
* Create an event with seats_limited=True and seats_max > 0
* Create a ticket for that event with seats_max=0 (unlimited)
* Open POS and view the event product

> Observation:
Ticket appears as "Sold out" instead of showing available seats

Why the fix:
------------
The frontend logic only treated tickets with seats_max=0 as unlimited when the event itself was not limited (!event.seats_limited). However, according to the backend logic, seats_max=0 means the ticket is unlimited regardless of the event's limitation status. When the event is limited, unlimited tickets should still respect the event's seats_available limit, not show as sold out.

We now check for seats_max=0 independently of event limitation. If the event is not limited, tickets with seats_max=0 are fully unlimited. If the event is limited, we use the event's seats_available value (since the ticket doesn't constrain availability but the event does), ensuring correct display of availability status.

opw-5475803

Forward-Port-Of: odoo/odoo#246102

**Issue**:
The computation of cogs value, in AVCO (or FIFO) setup with kit of several component leads to traceback

**Steps to reproduce**:
- Create a kit product with 2 components: 
    - Inventory tracking enabled 
    - Use a category configured with AVCO and Perpetual (at invoicing) valuation
- Create a SO for the kit product and confirm it
- Go to the associated delivery and validate it
- Create and post the invoice on the so -> A traceback occurs

**Cause**:
In `_get_cogs_price_unit`, the code accesses `self.product_id.cost_method` assuming a singleton: https://github.com/odoo/odoo/blob/5d2e4b0f3fa8cdf2a977db05c7c2565b06ca2513/addons/stock_account/models/stock_move.py#L245 but `self.product_id` can be a multi-recordset when the sale line corresponds to a kit with multiple components https://github.com/odoo/odoo/blob/5d2e4b0f3fa8cdf2a977db05c7c2565b06ca2513/addons/stock_account/models/account_move_line.py#L67-L68 https://github.com/odoo/odoo/blob/5d2e4b0f3fa8cdf2a977db05c7c2565b06ca2513/addons/sale_stock/models/account_move.py#L155-L156

which causes the traceback.

**solution**
The solution has been inspired by this:
https://github.com/odoo/odoo/blob/008e69e8215fecc1f3fe45a36189592577cdc593/addons/stock_account/models/stock_move.py#L225-L228

opw-5880383

Forward-Port-Of: odoo/odoo#247775

[FIX] website: enable custom javascript on website
Steps to reproduce the problem:
- Go to the "HTML/ CSS Editor".
- Go to the JS tab.
- Uncomment the example and save.

-> Problem: the confirmation dialog does not appear.

The problem is that since [1], `/* @odoo-module */` has been removed
from the file as since [2], js files in `/static/src` and
`/static/tests` are considered as odoo module without the need of the
annotation `odoo-module`. In order to understand the problem, here is a
summary of what happens when a custom js code is saved;
- An attachment is created with the custom js code.
- An asset is created to replace the user custom rules of
`user_custom_javascript.js` by the one of the newly created attachment.

Because the url of the newly created attachment looks like
`/_custom/web.assets_frontend_lazy/website/static/src/js/user_custom_javascript.js`,
the transpiler does not recognize it as an odoo module.

task-5925607

[1]: https://github.com/odoo/odoo/commit/6d2fda172ec9cc7642abe9625ca486c7769e8297
[2]: https://github.com/odoo/odoo/commit/5f2c505836002ac7851c29c28d612f721d467bc4

Forward-Port-Of: odoo/odoo#247959

## Issue
When using the *Default GS1 Nomenclature*, it is possible to create multiple lots/serial numbers with a same name if that name matches a barcode rule pattern.

## Steps to reproduce
1. Install *Inventory* (`stock`)
2. In Settings, enable *Lots & Serial Numbers* and set *Barcode Nomenclature* to *"Default GS1 Nomenclature"*
3. Create a product tracked *By Unique Serial Number* or *By Lots*
4. In Inventory > Products > Lots / Serial Numbers, create a lot/serial number named *"101"* and set the product to the one created in the previous step
    - The name *"101"* matches the pattern of the rule *"Batch or lot number"* (`(10)([!"%-/0-9:-?A-Z_a-z]{0,20})`)
5. Create a second lot/serial number with the same name and the same product
6. **The second lot/serial number is succesfully created**

## Cause
When comparing a (new) `stock_lot.name` to existing `stock_lot`s, the potential rules at the start of the name are removed by the `gs1_decompose_extended` method [here](https://github.com/odoo-dev/odoo/blob/e06282df3a7482cc327d3124e6c2b1c8bc55c2f0/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L116-L125). This results in comparing **the end** of the new lot/serial number with **the entire** name of existings serials.

## Solution
Commit https://github.com/odoo/odoo/commit/3513b189a225ca52fc9fae94693f00f43ded71aa introduced the `skip_preprocess_gs1` context flag. This flag allows to skip the step that removes the start of the new lot/serial number before comparing it to existing serials.

## Test
The test for this commit is added in `stock_barcode` by [this PR](https://github.com/odoo/enterprise/pull/104720)

opw-5477003

Forward-Port-Of: odoo/odoo#244427

**Steps to reproduce:**
- Install Accounting
- Install a localization using PEPPOL (e.g. l10n_be)
- Switch to a Belgian company
- In Accounting settings, activate PEPPOL and Audit Trail

- Create an invoice:
  * Customer: [a Belgian customer with VAT]
  * Invoice Lines: [a line with a tax]
- Confirm the invoice
- Send the invoice via PEPPOL

**Issue:**
A UserError is raised:
"You cannot remove parts of the audit trail.".

**Cause:**
The audit trail prevent modifying an attachment.
When sending an invoice to PEPPOL, a message is logged in the chatter with both the invoice PDF and XML as attachment.
During the process, "res_model" and "res_id" fields of the attachments are set to the message record.
Before doing it, "res_id" is removed in SQL to prevent raising the audit trail error.
However, it fails because the value is still in cache.

**Solution:**
Invalidate these fields as it is done when sending the invoice without PEPPOL.
https://github.com/odoo/odoo/commit/e0229d5c7fa89d32f67151d307161482c300ff20

opw-5916696




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

Forward-Port-Of: odoo/odoo#248220
Forward-Port-Of: odoo/odoo#247949

Steps to reproduce:
1. Create a storable product with tracking set to 'By Quantity'.
2. Update the Quantity on Hand (e.g., 100 units).
3. Change the product tracking to 'By Serial Number'.
4. Create a Repair Order for this product.
5. Add a line, select a specific Serial Number, and click Save.
6. Observe that the serial number disappears.

Cause:
When reserving stock that was originally created as 'Generic' (no serial), the `_prepare_move_line_vals` method returns `lot_id=False`. The repair view uses `_compute_lot_ids` to display selected lots, which filters out any move lines where `lot_id` is False. This causes the new line to be effectively invisible to the UI immediately after creation.

Solution:
In the `_set_lot_ids` inverse method, explicitly force the `lot_id` into the create values dictionary (`move_line_vals`). This ensures that even if Odoo reserves generic stock, the resulting move line is born with the correct Serial Number identity, keeping it visible and valid.

opw-5156267

Forward-Port-Of: odoo/odoo#248094
Forward-Port-Of: odoo/odoo#247150

Configuration:
-------------------------
- Restaurant Mode
- Self-Order Mode: “QR + Ordering”
- Service At: Table (Online Payment)

--------------------------------------------------------------------------------
Issue 1: Extra Order word print in KOT
---------------------

Steps to Reproduce:
1. Make an order using Self Order (QR).
2. Configure and enable the Kitchen Printer.
3. Check the KOT print it shows “Order Self-Order T2”.

Cause:
- The QWeb template always prefixed “Order” regardless of order type.

Fix:
- Added a condition to skip the “Order” label for self-order references:

--------------------------------------------------------------------------------

Issue 2: “Send To Kitchen” Button Visible even order in kitchen
---------------
Steps to Reproduce:
1. Open the Restaurant
2. Place a order from mobile menu and select a table.
3. In the Restaurant UI:
   - Open that table. The "Send To Kitchen" button is still visible even
     though the order was already sent to the kitchen and printed.

Cause:
- In self-order mode  the order is not automatically synced after being sent to
  the kitchen and print.
- As a result, the system still treats it as unsent, leaving the Order button
  visible.

Fix:
- Synced the order state after sending it to the kitchen.
----------------------------------------------------

Task-5106704

Forward-Port-Of: odoo/odoo#246867
Forward-Port-Of: odoo/odoo#231005

**Steps to reproduce:**
* Install the `stock_barcode`, `quality_control` modules.
* Go to *Inventory > Configuration > Settings* and enable **Packages**.
* Create a product with **By Lot** tracking enabled and set a barcode reference.
* Create a quality control point for this product with following configuration:
  * Operation: *Receipts*
  * Control per: *Quantity*
  * Control Frequency: *All*
  * Product: the previously created lot-tracked product.
* Create a receipt for this product with a quantity of 6 and `mark as todo`.
* Open the *Barcode* app and process the receipt.
* Scan the product barcode.
* Scan some quantity of the product with lot *LOT01* and put those units into a 
package(Put-In-Pack).
* Scan the remaining quantity with lot *LOT02* and put those units into a
 different package(Put-In-Pack).
* Click on **Quality Checks**.

**Observed behavior:**
* Only one quality check is created, even though the receipt contains two different
lots that should each generate a quality check.

**Cause:**
* In `_inverse_qty_done`, move lines are marked as *picked* when `qty_done` is
equal to quantity(Demand).
* During the `write` operation, quality checks are created only for move lines
that are not picked, which prevents creating a quality check for each lot.
* Relevant code: https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/quality_control/models/stock_move_line.py#L39 https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/stock_barcode/models/stock_move_line.py#L67-L71

**Fix:**
* Ensure that quality check points are generated correctly when validating
products through the Barcode app using the Put in Pack option.

---

opw-5405221

Forward-Port-Of: odoo/enterprise#105930
Forward-Port-Of: odoo/enterprise#102714

Steps to Reproduce:
1- Auto-plan a task starting on 25 November 2025 with 40 allocated hours. 2- The computed end date becomes 26 November, instead of extending into early December. => As a result, the allocated period is shorter than the required hours.

Source:
When selecting 25/11/2025 as the start date, the system tries to schedule the task within the remaining days of November (25–28).
However, these four days are not enough to cover 40 hours.

The system then searches for available intervals in the next month. But the intervals from November are still kept in the list, so when the algorithm iterates again, it reuses the previously consumed intervals (25 and 26). This causes the scheduler to allocate the remaining hours to those same days, leading to an incorrect result where the task spans only 25–26 November, instead of continuing from 1 December.

Solution:
Remove already-used intervals before recomputing the schedule.

opw-5364327

Forward-Port-Of: odoo/enterprise#107043
Forward-Port-Of: odoo/enterprise#101262

## Issue

When using the *Default GS1 Nomenclature*, it is possible to create multiple lot/serial numbers with a same name if the name matches a barcode rule pattern.

## Fix
The fix related to this commit is introduced by [this PR](https://github.com/odoo/odoo/pull/244427).

## Problematic flow
The problematic flow starts in the `StockLot._check_unique_lot` method when calling `self._read_group`. At that point, the domain is still correct: it contains the product_id and the (correct) name for the lot we try to create.

https://github.com/odoo/odoo/blob/b51c80a4368b99e55073856061113244b16b23f9/addons/stock/models/stock_lot.py#L104-L111

In the `BaseModel._read_group` method, the query is defined by the `self._search` method. At that point, the domain is the same as in the previous step, so it is still correct.

https://github.com/odoo/odoo/blob/b51c80a4368b99e55073856061113244b16b23f9/odoo/orm/models.py#L1902-L1904

Now the flow differs depending on whether the `stock_barcode` app is installed or not. If it is, the `stock_barcode/StockLot._search` method is called:

https://github.com/odoo/enterprise/blob/24fea3814b95144953fb809d10bf6a62906c06fd/stock_barcode/models/stock_lot.py#L11-L15

This is the method that calls the `BarcodeNomenclature._preprocess_gs1_search_args` which uses the `skip_preprocess_gs1` context flag:

https://github.com/odoo/odoo/blob/b51c80a4368b99e55073856061113244b16b23f9/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L149-L151

**This flow makes the query returned by `self._search(domain)` erroneous, as the start of the name of the lot is removed further down the execution of the `preprocess_gs1_search_args` method.**

### If stock_barcode is not installed

The `self._search` method called in the BaseModel will not call `stock_barcode/StockLot._search`, but instead it calls `BaseModel._search`. This totally skips the problematic gs1 flow.

opw-5477003

Forward-Port-Of: odoo/enterprise#104720

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Audit Trail"

- Go to "Accounting / Accounting / Management / Assets"
- Create an asset:
  * Original Value: [any]
  * Acquisition Date: [in the past] (e.g. 01/01/2025)
  * Duration: [at least until today] (e.g. 36 Months)
  * Depreciation Account: [any]
  * Expense Account: [any]
- Confirm the asset

- Modify Depreciation:
  * Action: Dispose
  * Date: [in the past] (e.g. 30/10/2025)
  * Loss Account: [any]
- Dispose

- Go to "Accounting / Reporting / Management / Depreciation Schedule"
- Filter on a period after the disposal date

**Issue:**
The asset appears in the selected period even if it has already been disposed.

**Cause:**
There are posted depreciation moves that have a date after the disposal date.
These moves should be deleted but the Audit Trail feature prevents it. These moves are cancelled instead.
However, the disposal date computed on the asset is taking the max date from all the depreciation moves.
Even the cancelled ones ; leading to a disposal date different than the one entered.

opw-5225749

Forward-Port-Of: odoo/enterprise#107028

**Steps to reproduce:**
- Install Accounting
- Install a localization using PEPPOL (e.g. l10n_be)
- Switch to a Belgian company
- In Accounting settings, activate PEPPOL and Audit Trail

- Create an invoice:
  * Customer: [a Belgian customer with VAT]
  * Invoice Lines: [a line with a tax]
- Confirm the invoice
- Send the invoice via PEPPOL

**Issue:**
A UserError is raised:
"You cannot remove parts of the audit trail.".

**Cause:**
The audit trail prevent modifying an attachment.
When sending an invoice to PEPPOL, a message is logged in the chatter with both the invoice PDF and XML as attachment.
During the process, "res_model" and "res_id" fields of the attachments are set to the message record.
Before doing it, "res_id" is removed in SQL to prevent raising the audit trail error.
However, it fails because the value is still in cache.

**Solution:**
Invalidate these fields as it is done when sending the invoice without PEPPOL.
https://github.com/odoo/odoo/commit/e0229d5c7fa89d32f67151d307161482c300ff20

opw-5916696




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

Forward-Port-Of: odoo/odoo#248220
Forward-Port-Of: odoo/odoo#247949

Step to reproduce:
- have a trusted pos and a loyalty program which gives points per $ spent
- start pos and select order and a partner (he should already have some LPs)
- notice the loyalty points assgined
- save the order, you are redirected to new order
- switch back to original order

Observation:
- Notice, the loyalty points are reassigned for example :
- if initially partner's LP = 50,  product added is 100$ , LP = 50+100 = 150
- After saving, LP becomes 150 + 100 = 250

Cause:
- LP's are processed after every `sync_from_ui` call from `_postProcessLoyalty` which updates the customer's lp, even before the order is fullfilled or when order is still in `draft` state

Fix:
- Issue is fixed in https://github.com/odoo/odoo/commit/a4b37ec474656c7af23d0134251d589e9a6a61ca
- This commit adds related test for the fix
    

opw-5609964

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

Forward-Port-Of: odoo/odoo#248077
Forward-Port-Of: odoo/odoo#245400

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Audit Trail"

- Go to "Accounting / Accounting / Management / Assets"
- Create an asset:
  * Original Value: [any]
  * Acquisition Date: [in the past] (e.g. 01/01/2025)
  * Duration: [at least until today] (e.g. 36 Months)
  * Depreciation Account: [any]
  * Expense Account: [any]
- Confirm the asset

- Modify Depreciation:
  * Action: Dispose
  * Date: [in the past] (e.g. 30/10/2025)
  * Loss Account: [any]
- Dispose

- Go to "Accounting / Reporting / Management / Depreciation Schedule"
- Filter on a period after the disposal date

**Issue:**
The asset appears in the selected period even if it has already been disposed.

**Cause:**
There are posted depreciation moves that have a date after the disposal date.
These moves should be deleted but the Audit Trail feature prevents it. These moves are cancelled instead.
However, the disposal date computed on the asset is taking the max date from all the depreciation moves.
Even the cancelled ones ; leading to a disposal date different than the one entered.

opw-5225749

Forward-Port-Of: odoo/enterprise#107028

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Audit Trail"

- Go to "Accounting / Accounting / Management / Assets"
- Create an asset:
  * Original Value: [any]
  * Acquisition Date: [in the past] (e.g. 01/01/2025)
  * Duration: [at least until today] (e.g. 36 Months)
  * Depreciation Account: [any]
  * Expense Account: [any]
- Confirm the asset

- Modify Depreciation:
  * Action: Dispose
  * Date: [in the past] (e.g. 30/10/2025)
  * Loss Account: [any]
- Dispose

- Go to "Accounting / Reporting / Management / Depreciation Schedule"
- Filter on a period after the disposal date

**Issue:**
The asset appears in the selected period even if it has already been disposed.

**Cause:**
There are posted depreciation moves that have a date after the disposal date.
These moves should be deleted but the Audit Trail feature prevents it. These moves are cancelled instead.
However, the disposal date computed on the asset is taking the max date from all the depreciation moves.
Even the cancelled ones ; leading to a disposal date different than the one entered.

opw-5225749

Forward-Port-Of: odoo/enterprise#107028

Currently, an `incorrect warning` message is shown when sending an invoice to 
`DIAN` or `Carvajal`, if the invoice date is 6 days before today, even though this 
date should be considered valid.

**Steps to reproduce:**
- Install the `l10n_co_dian` module and switch to the `CO company`.
- Go to `Invoicing` and create a new invoice with `taxes`.
- Set the `Invoice Date` to 6 days before today.
- Click `Confirm` > `Send`, ensure `DIAN` is selected, and `send` the invoice.
- Observe the warning message.

**Observation:**
`The issue date can not be older than 5 days or more than 5 days in the future.`

**Root cause:**
At [1] and [2], the allowed invoice date range is incorrectly computed, using 
`5 days in the past` and `10 days in the future`. This does not match the Colombian 
regulations and triggers incorrect validation errors for valid invoice dates.

These checks are intentionally implemented in both modules because they apply
at different stages and for different providers:
1) `l10n_co_dian`
When `DIAN: Free service` is selected as the `Electronic Invoicing Provider`
from the `Invoicing Settings`, the date constraint is evaluated at `send time`.
After the invoice is created, the validation is performed when the user sends 
the invoice to `DIAN`, and a blocking error is raised as a `UserError` if the 
invoice date is outside the allowed range.

2) `l10n_co_edi`
When `Carvajal` is selected as the `Electronic Invoicing Provider`, the same 
rule is checked `at the confirmation time` of the draft invoice. In this case, 
the validation results in a `chatter message`, not a blocking send-time error.

**Fix:**
This commit updates the date constraint logic to allow invoices dated up to 
`6 days before and 6 days after` the current date, in accordance with the 
DIAN specification described in Anexo Técnico – Documento Soporte No Obligados, 
page 59, at [2].

<img width="1089" height="120" alt="DIAN" src="https://github.com/user-attachments/assets/408c5ccc-5fed-4585-a81e-dce4ccb98b40" />

[1]:
https://github.com/odoo/enterprise/blob/2217827c0989fc5fc8d52a6a9b6f6c6d00b9773f/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L672-L679

[2]:
https://github.com/odoo/enterprise/blob/913e55abc4a9aa58509aa2a60d378fb552de554d/l10n_co_edi/models/account_edi_format.py#L574-L603

[3]:
https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Documento-Soporte-No-Obligados.pdf

opw-5482555

Forward-Port-Of: odoo/enterprise#105763

_* = helpdesk_sale_timesheet, sale_timesheet_enterprise

This commit adapts the community changes that centralized the reinvoicing flow
of analytic lines and renamed the field `timesheet_invoice_id` to `reinvoice_move_id`

The main technical change concerns how analytic lines to reinvoice are retrieved

Previously, analytic lines were always searched per invoice line. This was
needed in some situations, because for subscription timesheets the valid date
range can depend on the related sale order of each invoice line.

With this change, the specific per-invoice-line logic is now only used when all
of the following are true:
* No explicit `timesheet_start_date` or `timesheet_end_date` is provided in
  the context
* The invoice is linked to at least one sale order that:
  * is a subscription order
  * contains products delivered through timesheets.

Only in this case do we compute date ranges from the related sale orders and
search analytic lines separately per invoice line.

In all other cases, the standard aggregated search from the parent
implementation is used, which avoids unnecessary processing and speeds up
reinvoicing flow.

task-5490517

See Also:
- https://github.com/odoo/odoo/pull/245216
- https://github.com/odoo/upgrade/pull/9366

Currently, an error occurs when selecting a date on a rental product. 

**Steps to Reproduce:**
 - Install the `website_sale_stock_renting` module.
 - Go to `Products` and create a product with the following `configuration`:
   - Enable `Track Inventory` and set `Quantity On Hand` greater than zero.
   - Disable `Sell when Out-of-Stock` under the `eCommerce tab`.
   - Under the `Sales tab`, set `Periodicity to Days`, and set the same time for `Pickup and Return`.
 - Go to `Website > Shop`.
 - Open the product, select the same date for both `Start Date and End Date`, and `click anywhere`.

`ValueError: min() iterable argument is empty`

**Cause:**
 - This error occurs because when the start and end dates are the same, the method returns a set 
   of dates from here [1]. Since there is only a single date, the loop is not executed and it returns 
   an empty list of availabilities [2], which then raises the error [3].
 - The error happens due to the removal of this condition [4] in this [recent commit].
 - The warning message is now handled here [5].

**Fix:**
 - This commit ensures that when a user selects a start date that is greater than or equal to the 
   end date, a UserError is raised and the proper warning message is displayed.

[1]: https://github.com/odoo/enterprise/blob/f26da0d5285ff47bf7a4297141830db67f7103d1/sale_stock_renting/models/sale_order_line.py#L616

[2]: https://github.com/odoo/enterprise/blob/f26da0d5285ff47bf7a4297141830db67f7103d1/website_sale_stock_renting/models/product_product.py#L77

[3]: https://github.com/odoo/enterprise/blob/f26da0d5285ff47bf7a4297141830db67f7103d1/website_sale_stock_renting/models/website.py#L18-L22

[4]: https://github.com/odoo/enterprise/blob/66f144df6f2056212797547dfef5ed58232698cd/website_sale_renting/models/product_template.py#L175-L176

[5]: https://github.com/odoo/enterprise/blob/f26da0d5285ff47bf7a4297141830db67f7103d1/website_sale_renting/static/src/interactions/daterange_picker.js#L213

[recent commit]: https://github.com/odoo/enterprise/commit/4afdc272e5a7fc4284bbd9f97283b8ec0aa28c34

sentry-7243018656

Forward-Port-Of: odoo/enterprise#106602

**Steps to reproduce:**
* Install the `stock_barcode`, `quality_control` modules.
* Go to *Inventory > Configuration > Settings* and enable **Packages**.
* Create a product with **By Lot** tracking enabled and set a barcode reference.
* Create a quality control point for this product with following configuration:
  * Operation: *Receipts*
  * Control per: *Quantity*
  * Control Frequency: *All*
  * Product: the previously created lot-tracked product.
* Create a receipt for this product with a quantity of 6 and `mark as todo`.
* Open the *Barcode* app and process the receipt.
* Scan the product barcode.
* Scan some quantity of the product with lot *LOT01* and put those units into a 
package(Put-In-Pack).
* Scan the remaining quantity with lot *LOT02* and put those units into a
 different package(Put-In-Pack).
* Click on **Quality Checks**.

**Observed behavior:**
* Only one quality check is created, even though the receipt contains two different
lots that should each generate a quality check.

**Cause:**
* In `_inverse_qty_done`, move lines are marked as *picked* when `qty_done` is
equal to quantity(Demand).
* During the `write` operation, quality checks are created only for move lines
that are not picked, which prevents creating a quality check for each lot.
* Relevant code: https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/quality_control/models/stock_move_line.py#L39 https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/stock_barcode/models/stock_move_line.py#L67-L71

**Fix:**
* Ensure that quality check points are generated correctly when validating
products through the Barcode app using the Put in Pack option.

---

opw-5405221

Forward-Port-Of: odoo/enterprise#105930
Forward-Port-Of: odoo/enterprise#102714

## Issue

When using the *Default GS1 Nomenclature*, it is possible to create multiple lot/serial numbers with a same name if the name matches a barcode rule pattern.

## Fix
The fix related to this commit is introduced by [this PR](https://github.com/odoo/odoo/pull/244427).

## Problematic flow
The problematic flow starts in the `StockLot._check_unique_lot` method when calling `self._read_group`. At that point, the domain is still correct: it contains the product_id and the (correct) name for the lot we try to create.

https://github.com/odoo/odoo/blob/b51c80a4368b99e55073856061113244b16b23f9/addons/stock/models/stock_lot.py#L104-L111

In the `BaseModel._read_group` method, the query is defined by the `self._search` method. At that point, the domain is the same as in the previous step, so it is still correct.

https://github.com/odoo/odoo/blob/b51c80a4368b99e55073856061113244b16b23f9/odoo/orm/models.py#L1902-L1904

Now the flow differs depending on whether the `stock_barcode` app is installed or not. If it is, the `stock_barcode/StockLot._search` method is called:

https://github.com/odoo/enterprise/blob/24fea3814b95144953fb809d10bf6a62906c06fd/stock_barcode/models/stock_lot.py#L11-L15

This is the method that calls the `BarcodeNomenclature._preprocess_gs1_search_args` which uses the `skip_preprocess_gs1` context flag:

https://github.com/odoo/odoo/blob/b51c80a4368b99e55073856061113244b16b23f9/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L149-L151

**This flow makes the query returned by `self._search(domain)` erroneous, as the start of the name of the lot is removed further down the execution of the `preprocess_gs1_search_args` method.**

### If stock_barcode is not installed

The `self._search` method called in the BaseModel will not call `stock_barcode/StockLot._search`, but instead it calls `BaseModel._search`. This totally skips the problematic gs1 flow.

opw-5477003

Forward-Port-Of: odoo/enterprise#104720

Why this commit
---

When adding a rental accessory product from the cart page suggested products, the [add_to_cart](https://github.com/odoo/enterprise/blob/19.0/website_sale_renting/controllers/cart.py#L52-L58) was triggered without the rental start and end dates(None was taken by default). As a result, the system uses [default rental duration](https://github.com/odoo/enterprise/blob/19.0/website_sale_renting/models/sale_order.py#L95-L99) for comparison and considers the accessory as having a different rental period then on the sale order and raised an error
 preventing it from being added to the cart.

This issue did not occur when adding the same product from its product page, as the rental context was correctly provided there.

After this Commit
---
The rental start and end dates from the current sale order are  passed when adding accessory products from the cart page suggested products. This ensures that rental period consistency checks succeed and the accessory can be added without raising an invalid operation error.

Steps to Reproduce
---
1. Create two rental products A and B.

2. Configure product B as an accessory of product A.

3. Add product A to the cart with any rental period(except default).

4. From the cart page, attempt to add product B from suggested products.

5.Observe the error about mixing different rental periods.

Here is the video demonstrating on how the error is reproduced :


https://github.com/user-attachments/assets/3d5e6f96-cebd-4221-8592-1bdb6ae40ec7



Expected Result

The accessory product is added to the cart using the same rental period as the existing cart's rental period.

OPW: 5823691

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Audit Trail"

- Go to "Accounting / Accounting / Management / Assets"
- Create an asset:
  * Original Value: [any]
  * Acquisition Date: [in the past] (e.g. 01/01/2025)
  * Duration: [at least until today] (e.g. 36 Months)
  * Depreciation Account: [any]
  * Expense Account: [any]
- Confirm the asset

- Modify Depreciation:
  * Action: Dispose
  * Date: [in the past] (e.g. 30/10/2025)
  * Loss Account: [any]
- Dispose

- Go to "Accounting / Reporting / Management / Depreciation Schedule"
- Filter on a period after the disposal date

**Issue:**
The asset appears in the selected period even if it has already been disposed.

**Cause:**
There are posted depreciation moves that have a date after the disposal date.
These moves should be deleted but the Audit Trail feature prevents it. These moves are cancelled instead.
However, the disposal date computed on the asset is taking the max date from all the depreciation moves.
Even the cancelled ones ; leading to a disposal date different than the one entered.

opw-5225749

Forward-Port-Of: odoo/enterprise#107028

[FIX] base, tools: fix the behaviour of inline translated elements
Steps to reproduce:

- Go to a website page (in "Edit" mode) > Add a "Title" snippet.

- Select the whole "title" > Set a highlight effect on it.

- With the same text selected, transform it to a link and save.

- Try to translate the title into another language in the editor > You
cannot update the text or remove it.

The code from [1] introduced a feature that allows forcing some specific
elements to be "translated inline" using the `o_translate_inline` class.

It was used mainly to handle specific cases where elements DOM is
handled in JS in a way that breaks the "Translate" editor (e.g., text
highlights).

By forcing the highlight `<span/>`s to be inline translated, the fix
from [1] only handled situations where a highlight effect has a non-
"inline-translated" element (e.g., a link) amongst its text content.

E.g. This DOM structure:

```
<span class="o_text_highlight o_text_highlight_wavy o_translate_inline">
    Go to the <a href="/contactus">Contact Us</a> page
</span>
```

Which caused the translation `<span/>` to be set inside the highlight
structure [A].

Now, as explained in the steps above, there are some cases like with
this DOM:

```
<span class="o_text_highlight o_text_highlight_wavy o_translate_inline">
    <a href="/contactus">Contact Us</a>
</span>
```

That will make the translation code check the inner non-"inline
translated" children even within a `o_translate_inline` parent (see:
`translate_xml_node()` > `hastext()` | `process()`), leading to the
same issue as [A].

The goal of this commit is to prevent any similar situation causing the
translation spans to be added inside elements forced to be translated
as a whole, by automatically considering all elements inside a
`o_translate_inline` parent as inline translated too.

This commit also adds a test for the explained behavior.

[1]: https://github.com/odoo/odoo/commit/e9659e55356e5e4de63f2324eb88a7b6f07cd835

opw-4243639

linked to: opw-3980975
linked to: opw-4089482
linked to: opw-4061566

Currently, an `incorrect warning` message is shown when sending an invoice to 
`DIAN` or `Carvajal`, if the invoice date is 6 days before today, even though this 
date should be considered valid.

**Steps to reproduce:**
- Install the `l10n_co_dian` module and switch to the `CO company`.
- Go to `Invoicing` and create a new invoice with `taxes`.
- Set the `Invoice Date` to 6 days before today.
- Click `Confirm` > `Send`, ensure `DIAN` is selected, and `send` the invoice.
- Observe the warning message.

**Observation:**
`The issue date can not be older than 5 days or more than 5 days in the future.`

**Root cause:**
At [1] and [2], the allowed invoice date range is incorrectly computed, using 
`5 days in the past` and `10 days in the future`. This does not match the Colombian 
regulations and triggers incorrect validation errors for valid invoice dates.

These checks are intentionally implemented in both modules because they apply
at different stages and for different providers:
1) `l10n_co_dian`
When `DIAN: Free service` is selected as the `Electronic Invoicing Provider`
from the `Invoicing Settings`, the date constraint is evaluated at `send time`.
After the invoice is created, the validation is performed when the user sends 
the invoice to `DIAN`, and a blocking error is raised as a `UserError` if the 
invoice date is outside the allowed range.

2) `l10n_co_edi`
When `Carvajal` is selected as the `Electronic Invoicing Provider`, the same 
rule is checked `at the confirmation time` of the draft invoice. In this case, 
the validation results in a `chatter message`, not a blocking send-time error.

**Fix:**
This commit updates the date constraint logic to allow invoices dated up to 
`6 days before and 6 days after` the current date, in accordance with the 
DIAN specification described in Anexo Técnico – Documento Soporte No Obligados, 
page 59, at [3].

<img width="1089" height="120" alt="DIAN" src="https://github.com/user-attachments/assets/408c5ccc-5fed-4585-a81e-dce4ccb98b40" />

[1]:
https://github.com/odoo/enterprise/blob/2217827c0989fc5fc8d52a6a9b6f6c6d00b9773f/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L672-L679

[2]:
https://github.com/odoo/enterprise/blob/913e55abc4a9aa58509aa2a60d378fb552de554d/l10n_co_edi/models/account_edi_format.py#L574-L603

[3]:
https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Documento-Soporte-No-Obligados.pdf

opw-5482555

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Audit Trail"

- Go to "Accounting / Accounting / Management / Assets"
- Create an asset:
  * Original Value: [any]
  * Acquisition Date: [in the past] (e.g. 01/01/2025)
  * Duration: [at least until today] (e.g. 36 Months)
  * Depreciation Account: [any]
  * Expense Account: [any]
- Confirm the asset

- Modify Depreciation:
  * Action: Dispose
  * Date: [in the past] (e.g. 30/10/2025)
  * Loss Account: [any]
- Dispose

- Go to "Accounting / Reporting / Management / Depreciation Schedule"
- Filter on a period after the disposal date

**Issue:**
The asset appears in the selected period even if it has already been disposed.

**Cause:**
There are posted depreciation moves that have a date after the disposal date.
These moves should be deleted but the Audit Trail feature prevents it. These moves are cancelled instead.
However, the disposal date computed on the asset is taking the max date from all the depreciation moves.
Even the cancelled ones ; leading to a disposal date different than the one entered.

opw-5225749

Forward-Port-Of: odoo/enterprise#107028