Currently, an error occurs when a user applies a discount code to the cart.

Steps to reproduce:

 - Install the `website_sale_loyalty` module.
 - Go to `Discount & Loyalty` and create a new program with `Program Type = Discount Code`.
 - Under the `Rules & Rewards` tab, add a rule with a `code (e.g., demo)`.
 - `Archive` the program record.
 - Repeat `steps 2 and 3`.
 - `Unarchive` the first record.
 - Go to `Website` > `Shop`, add a product to the cart, and go to the cart page.
-  Apply the code `demo`.

`ValueError: Expected singleton: loyalty.program(2, 3)`

This error occurs when a user creates a sale loyalty program and adds a loyalty rule with a code, then archives that record. If the user creates the same record again and later unarchive the first record, there will be two rules with the same code, resulting in two loyalty programs [1], which raises the error [2].

This commit ensures that the system also checks archived records when unarchiving and verifies that there are no two or 
more programs with the same code being unarchived, so that no conflicting rules are activated.

[1]- https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_loyalty/models/sale_order.py#L1351

[2]- https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_loyalty/models/sale_order.py#L1371

sentry-6871330244

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

Forward-Port-Of: odoo/odoo#239713
Forward-Port-Of: odoo/odoo#226801

Description of the issue/feature this PR addresses:
- The POS receipt shows CGST, SGST, and IGST together, even when IGST is applicable.
- This is incorrect because only CGST+SGST or IGST should be displayed, not all three.

Current behavior before PR:
- The receipt always displays CGST, SGST, and IGST columns at the same time.
<img width="250" height="400" alt="image" src="https://github.com/user-attachments/assets/5c8487c7-c497-4c82-ad80-8cf0e98fbf38" />

Desired behavior after PR is merged:
- The receipt shows only the correct tax columns based on the transaction:
  - Shows CGST and SGST when GST applies.
  - Shows IGST when IGST applies.
<img width="250" height="400" alt="image" src="https://github.com/user-attachments/assets/68d2fb58-9e15-4861-a71f-ccb2d978e544" />

Changes implemented in this commit:
- Added `t-if="l10n_in_hsn_summary.has_gst"` to CGST and SGST headers.
- Added the same condition to CGST and SGST values in the item rows.


task-5268935

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

Forward-Port-Of: odoo/odoo#236243

…f related line is complete

### Steps to reproduce:

- In the settings enable Lots & Serials and Batch transfers
- On the delivery operation types enable show reserved lots in the barcode tab
- Create a storable product tracked by lots and put 10 x lot1 in stock
- Create and confirm a delivery for 10 units
- Create a batch transfer with your delivery
- Process your transfer from the barcode app
- Scan one unit of LOT1 and put in pack
- Toggle sublines select the 0/9 subline without lots nor package
- Scan LOT1
#### > The 1/1 LOT1 line with a pack is updated to 2/1 rather than the 0/9

### Cause of the issue:

Since e45249c2f6883d743a4e7d19e736c622e26a3d58 and 27bfb985a29e9f0abe94dec8a76bf6d08560fbc9 an override of the `_findLine` method has been introduced in `BarcodePickingBatchModel` to ensure that scanning a lot referenced by an already existing line of the batch transfer triggers an update of that line rather than an override of the lot of an other line. However, these lines should not priorities a completed line when there is line without a set lot.

opw-5340865

Forward-Port-Of: odoo/enterprise#101908
Forward-Port-Of: odoo/enterprise#101611

This commit fixes three issues occurring when editing nested `s_card` snippets.

**Problem 1 - Incorrect cover image detection**

Issue: An `s_card` without a cover image displayed the cover image option if it contained a child `s_card` with a cover image.
Cause: The `querySelector` in `CardImageOption` could detect images inside child snippets.
Fix: Now the `querySelector` only searches among direct children of the snippet root element.

**Problem 2 - Ratio settings applied to all child cards**

Issue: Changing the cover image ratio on an `s_card` applied the setting to all nested cards.
Cause: The `we-select` in `s_card` options targeted `.o_card_img_wrapper`, causing the class to apply to all descendants.
Fix: The selector is now `>.o_card_img_wrapper`, so the option acts only on the current snippet.

**Problem 3 - Parent image positioning leaking to children**

Issue: Adjusting the cover image position on a parent `s_card` affected the rendering of all child card images.
Cause: CSS rules for `.o_card_img_horizontal` applied to all descendant elements matching `.o_card_img_wrapper`.
Fix: The rules now apply only to direct children of `.o_card_img_horizontal`. The same correction was applied to `.o_card_img_ratio_custom`.

task-5349540

Forward-Port-Of: odoo/odoo#239503
Forward-Port-Of: odoo/odoo#237587

**Steps to reproduce:**
* Install the **Italy – E-invoicing (l10n_it_edi)** module.
* Create a product with a non-zero cost price.
* Create a **vendor bill** for an Italian vendor using the **RC fiscal
  position**.
* Add the product with **unit price = 0**, apply **RC tax**, and set the
  **Origin Document Type**.
* Confirm the bill and click **Send to Tax Integration** to generate the
  XML in the chatter.
* Upload the generated XML through  
  **Accounting → Vendors → Bills → Upload**.

**Observed behavior:**
* The imported bill ignores the XML value **0.00** and uses the product's
  default price instead.

**Cause:**
* The XML’s `<PrezzoUnitario>` value is mandatory and may be **0**, but the
  code skipped it because `0.0` evaluates as falsy in the walrus
  assignment.

**Fix:**
* Always set the parsed `PrezzoUnitario` value (including **0.0**) on the
  invoice line.

ref: https://fex-app.com/FatturaElettronica/FatturaElettronicaBody/DatiBeniServizi/DettaglioLinee/PrezzoUnitario  

opw-5322187

Forward-Port-Of: odoo/odoo#239904
Forward-Port-Of: odoo/odoo#239419

**Issue**
When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is counted multiple times, once for each IIBB tax, leading to an inflated total.

**Steps to Reproduce**
1. Install the Accounting app and the Argentinian localization (l10n_ar)
2. Set the 21% VAT Purchase tax as Included in Price
3. Create a vendor bill applying the 21% VAT tax and at least two IIBB taxes
4. Open the VAT summary report for that bill

Expected Behaviour: The total in the VAT summary should match the total shown in the accounting form view, with each tax counted only once.

**Root Cause**
The VAT summary report in the Argentinian localization relies on an SQL query to aggregate tax information for each `account.move`. The query joins `account_move_line` with `account_tax`, `account_tax_group`, and the many-to-many relation table `account_move_line_account_tax_rel`. Each `account_move_line` related to a VAT tax line (via `tax_line_id`) is joined with the `account_move_line_account_tax_rel` table. If that base line is related to multiple IIBB taxes, the join multiplies the VAT line once per IIBB tax since multiple matching rows exist.

**Fix**
The solution separates the logic for computing tax lines and base lines into two distinct subqueries. Each is aggregated independently to prevent duplication caused by one-to-many and many-to-many joins. The results are then joined using the unique `account_move_line.id`, ensuring each tax amount is counted exactly once in the final totals.

opw-4776861

Forward-Port-Of: odoo/enterprise#98933
Forward-Port-Of: odoo/enterprise#85873

When doing a name_search with positive operators (=, ilike, in) the resulting query combines domains with the OR operator. This works fine when the leaves are all on the same table (product_product or product_template) as postgresql uses a Bitmap OR when everything is properly indexed.

When leaves are on multiple tables however postgresql has to plan a Seq Scan. For instance, let's take a simple domain on product.product of the form `['|', ('name', 'ilike', 'test'), ('default_code', 'ilike', 'test')]`. Because `name` is an inherited field via `product_tmpl_id`, the resulting query has the where clause `join_table.name ilike %s OR product_product.default_code ilike %s` with `join_table` the table you get after joining product_product and product_template. Since it's an `OR` condition, postgresql does not know in advance whether a given row will pass this condition. There's no way to filter the tables before the join. The condition moves therefore to a `Join Filter` node and postgresql has to scan the whole join table to fetch the correct tuples.

Same thing when there's a subquery. In case of a where clause `cond OR cond OR subquery`, postgresql does not know in advance whether or not a given row is gonna pass the subquery condition. So it has to scan the whole table.

In both cases this becomes a bottlneck when the number of products increaases. This commit introduces the use of `UNION ALL` instead of `OR`. There's one SubPlan for each individual table in the domain. The results are then appended to get the final products matching the conditions. Thanks to each table having its own SubPlan postgresql can now properly hit indexes for each table, greatly improving the performances.

#### speedup

In a database with 2.5M product_product, the name_search on product with a partner_id in the context and the ilike operator goes from 8s -> 5ms.

In another database with 500k product_template, the name_search on template with a partner_id in the context and the ilike operator goes from 1.8s -> 5ms.

opw-4921944
opw-5103287
opw-5049054
opw-5256691
opw-5221753

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

Forward-Port-Of: odoo/odoo#238901
Forward-Port-Of: odoo/odoo#229275

**Steps to reproduce:**
- (Firefox only)
- Go to any record which uses a chatter (e.g. Contact)
- Send message > Full composer > click the schedule message icon (lower right corner)
- Schedule the message in the future and click send
- You should see now a post in the chatter indicating that the message will be sent
- Now click Send message and repeat the above steps again to schedule a second message
- Whole page will be freezed
- Reloading doesn't help

**Issue:**
Infinite loop in reactive callback on firefox.
The code gets stuck in
```js
for (const callback of [...callbacks]) {
    clearReactivesForCallback(callback);
    callback();
}
```
because of
```js
const sortProxy2 = reactive(recordProxy, function sortObserver() {
    self.requestSort(record, fieldName);
});
this.fieldsSortProxy2.set(fieldName, sortProxy2);
```
which loops over `store._.ADD_QUEUE("sort", record, fieldName);`

(Forcing the `requestSort` only change the infinite loop into a recursion error)

The recomputation seems to be caused by a bad sorting here:
```js
this.scheduledMessages = Record.many("ScheduledMessage", {
    sort: (a, b) => {
        if (a.scheduled_date === b.scheduled_date) {
            return a.id - b.id;
        }
        return a.scheduled_date < b.scheduled_date ? -1 : 1;
    },
```
In the case both datetimes are equal the first condition doesn't properly catches it:
```
> a.scheduled_date - b.scheduled_date
> 0
> a.scheduled_date === b.scheduled_date
> false
> a.scheduled_date < b.scheduled_date
> false
> a.scheduled_date > b.scheduled_date
> false
```
Which make the ordering change on each sort iteration:
```
>  Array [ "ScheduledMessage,14", "ScheduledMessage,13" ]
> recordsFullProxy.sort(func);
>  Array [ "ScheduledMessage,13", "ScheduledMessage,14" ]
> recordsFullProxy.sort(func);
>  Array [ "ScheduledMessage,14", "ScheduledMessage,13" ]
```
Chromium based browsers probably use a different sorting algorithm than Firefox, which seems to prevent the issue.

**Fix:**
Use `compareDatetime` to ensure the ordering is constant for the same datetime values.

opw-5367371

Forward-Port-Of: odoo/odoo#239745
Forward-Port-Of: odoo/odoo#239199

Currently, an error occurs when a user applies a discount code to the cart.

Steps to reproduce:

 - Install the `website_sale_loyalty` module.
 - Go to `Discount & Loyalty` and create a new program with `Program Type = Discount Code`.
 - Under the `Rules & Rewards` tab, add a rule with a `code (e.g., demo)`.
 - `Archive` the program record.
 - Repeat `steps 2 and 3`.
 - `Unarchive` the first record.
 - Go to `Website` > `Shop`, add a product to the cart, and go to the cart page.
-  Apply the code `demo`.

`ValueError: Expected singleton: loyalty.program(2, 3)`

This error occurs when a user creates a sale loyalty program and adds a loyalty rule with a code, then archives that record. If the user creates the same record again and later unarchive the first record, there will be two rules with the same code, resulting in two loyalty programs [1], which raises the error [2].

This commit ensures that the system also checks archived records when unarchiving and verifies that there are no two or 
more programs with the same code being unarchived, so that no conflicting rules are activated.

[1]- https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_loyalty/models/sale_order.py#L1351

[2]- https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_loyalty/models/sale_order.py#L1371

sentry-6871330244

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

Forward-Port-Of: odoo/odoo#239713
Forward-Port-Of: odoo/odoo#226801

Description of the issue/feature this PR addresses:
- The POS receipt shows CGST, SGST, and IGST together, even when IGST is applicable.
- This is incorrect because only CGST+SGST or IGST should be displayed, not all three.

Current behavior before PR:
- The receipt always displays CGST, SGST, and IGST columns at the same time.
<img width="250" height="400" alt="image" src="https://github.com/user-attachments/assets/5c8487c7-c497-4c82-ad80-8cf0e98fbf38" />

Desired behavior after PR is merged:
- The receipt shows only the correct tax columns based on the transaction:
  - Shows CGST and SGST when GST applies.
  - Shows IGST when IGST applies.
<img width="250" height="400" alt="image" src="https://github.com/user-attachments/assets/68d2fb58-9e15-4861-a71f-ccb2d978e544" />

Changes implemented in this commit:
- Added `t-if="l10n_in_hsn_summary.has_gst"` to CGST and SGST headers.
- Added the same condition to CGST and SGST values in the item rows.


task-5268935

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

Forward-Port-Of: odoo/odoo#236243

**Issue**
When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is counted multiple times, once for each IIBB tax, leading to an inflated total.

**Steps to Reproduce**
1. Install the Accounting app and the Argentinian localization (l10n_ar)
2. Set the 21% VAT Purchase tax as Included in Price
3. Create a vendor bill applying the 21% VAT tax and at least two IIBB taxes
4. Open the VAT summary report for that bill

Expected Behaviour: The total in the VAT summary should match the total shown in the accounting form view, with each tax counted only once.

**Root Cause**
The VAT summary report in the Argentinian localization relies on an SQL query to aggregate tax information for each `account.move`. The query joins `account_move_line` with `account_tax`, `account_tax_group`, and the many-to-many relation table `account_move_line_account_tax_rel`. Each `account_move_line` related to a VAT tax line (via `tax_line_id`) is joined with the `account_move_line_account_tax_rel` table. If that base line is related to multiple IIBB taxes, the join multiplies the VAT line once per IIBB tax since multiple matching rows exist.

**Fix**
The solution separates the logic for computing tax lines and base lines into two distinct subqueries. Each is aggregated independently to prevent duplication caused by one-to-many and many-to-many joins. The results are then joined using the unique `account_move_line.id`, ensuring each tax amount is counted exactly once in the final totals.

opw-4776861

Forward-Port-Of: odoo/enterprise#98933
Forward-Port-Of: odoo/enterprise#85873

### Steps to reproduce:
	- Install Time off apps
	- Create two consecutive allocations (e.g. one for 2025 and one for 2026)
	- Create a leave that overlap with the two allocation (e.g. from 8th Dec to 3rd Jan)
	- Create a public holiday at the beginning of the second allocation (e.g. on 1st Jan 2026)

### Cause:
When we are checking the leave duration after having a public holiday the  will return the attendance without
the public holidays duration so when subtracting the attendance duration from the leave duration we will have a remaining amout equals to the public holiday duration and it will be considered as excess days.

https://github.com/odoo/odoo/blob/06e47d8601ba56b1650eeaeef71ebd7a4af39b8b/addons/hr_holidays/models/hr_employee_base.py#L228-L230

https://github.com/odoo/odoo/blob/06e47d8601ba56b1650eeaeef71ebd7a4af39b8b/addons/hr_holidays/models/hr_employee_base.py#L246-L254

### Fix:
We compute the leave duration before confirming it instead of computed them after

opw-5006119

Forward-Port-Of: odoo/odoo#239926
Forward-Port-Of: odoo/odoo#235575

Relativedelta on UTC dates or time-zoned dates doesn't return the same result. 
In order to calculate consistent prices (price for 1 month in December = price for 1 month in January), we need to work on time-zoned dates.

Example: 
Consider a website in UTC+1 (Brussels timezone DST off).
And a rental from the 01/12/2025 to the 31/12/2025 = by design, from the 01/01/2025 00h00 (start_date) to the 31/12/2025 23h59 (end_date). 
Converted in UTC for the back-end, we have:
from the 30/11/2025 23h00 to the 31/12/2025 22h59.
relativedelta(end_date, start_date) = time between the 2 dates is calculated as follow:
30/11/2025  23h00 + 1 month = 30/12/2025 23h00 +23h59 = 31/12/2025 22h59. 
Time difference = 1 month, 23 hours, 59 minutes. 
Price = 2 months. 

Consider a second rental from the 01/01/2026 to the 31/01/2026. 
31/12/2025 23h00 + 30 days = 30/01/2026 23h + 23h59 = 31/01/2026 22h59. 
Time difference = 30 days, 23 hours, 59 minutes.
Price = 1 month. 

opw-5130762

Forward-Port-Of: odoo/enterprise#98571

Version
- 18.0

Steps to Reproduce:
Issue 1: Incorrect tooltip text
  1. Go to Products → Products in subscription app.
  2. Open a product page and select goods product type
  3. observe product_tooltip show incorrect wording:
       * "Based on order" showed end of the period.
       * "Based on delivered" showed beginning of the period.

Issue 2: Product card shows both recurring and sales price
  1. Go to Products → Products in subscription app.
  2. Observe that the product card displays both recurring price and sales price

After this PR:
- Tooltip now correctly states:
   * for "based on order" invoice_policy -> beginning of period
   * for "based on delivery" invoice_policy -> end of period
- Product cards show only the recurring price when applicable.

task-5156390
<img width="1002" height="436" alt="image" src="https://github.com/user-attachments/assets/39f00555-e37a-44a5-8786-d7f8d6882de7" />
<img width="968" height="262" alt="image" src="https://github.com/user-attachments/assets/0d6d5c2d-d5ab-4376-bc03-dba243abce8b" />

Forward-Port-Of: odoo/enterprise#95010

Steps to Reproduce:
Issue 1: Incorrect tooltip text
  1. Go to Products -> Products in subscription app.
  2. Open a product page and select goods product type
  3. observe product_tooltip show incorrect wording: 
    - "Based on order" showed "end of the period."
    - "Based on delivered" showed "beginning of the period."

Issue 2: Product card shows both recurring and sales price
  1. Go to Products -> Products in subscription app.
  2. Observe that the product card displays both recurring price and list price

Solution:
-  Remove `product_template_form_view` from `sale_subscription_stock` and move
   it to `sale_subscription`, as the tooltip logic now applies to both goods and
   service-type products.
- In subscription product display only recurring price

task-5156390
---
<img width="1002" height="436" alt="image" src="https://github.com/user-attachments/assets/487fa076-264d-4565-a048-343c7317db42" />
<img width="968" height="262" alt="image" src="https://github.com/user-attachments/assets/d4fc4543-c7f4-4a98-be8f-b898057de896" />

…f related line is complete

### Steps to reproduce:

- In the settings enable Lots & Serials and Batch transfers
- On the delivery operation types enable show reserved lots in the barcode tab
- Create a storable product tracked by lots and put 10 x lot1 in stock
- Create and confirm a delivery for 10 units
- Create a batch transfer with your delivery
- Process your transfer from the barcode app
- Scan one unit of LOT1 and put in pack
- Toggle sublines select the 0/9 subline without lots nor package
- Scan LOT1
#### > The 1/1 LOT1 line with a pack is updated to 2/1 rather than the 0/9

### Cause of the issue:

Since e45249c2f6883d743a4e7d19e736c622e26a3d58 and 27bfb985a29e9f0abe94dec8a76bf6d08560fbc9 an override of the `_findLine` method has been introduced in `BarcodePickingBatchModel` to ensure that scanning a lot referenced by an already existing line of the batch transfer triggers an update of that line rather than an override of the lot of an other line. However, these lines should not priorities a completed line when there is line without a set lot.

opw-5340865

Forward-Port-Of: odoo/enterprise#101908
Forward-Port-Of: odoo/enterprise#101611

### Steps to reproduce:

- In the settings enable By-Products an Multi-step routes
- Put your warehouse in manufacturing in 3 steps
- Create two storable products:
    - Final Product (FP) with an empty bom
    - By Product (BP)
- Go to the barcode app > Operations > Manufacturing > New
- Scan FP > Register By-Products
- Scan BP
#### > The line is created with pre-prod as location and prod as destination

### Cause of the issue:

Since no existing line refers to the by product, a new line is created and its `location_id` and `location_dest_id` are provided by the `_getNewLineDefaultValues`:
https://github.com/odoo/enterprise/blob/17fd46b04d87585b7ed46c00d9559414daa17384/stock_barcode/static/src/models/barcode_model.js#L562-L566 However, at this point nothing had set the `params.newByProduct` in the `processBarcode`:
https://github.com/odoo/enterprise/blob/17fd46b04d87585b7ed46c00d9559414daa17384/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L375-L383 In fact, the only thing indicating that we are creating a by prodcut line at this point is the `displayByProduct`.

### Note:

The issue is no longer reproducible in 18.0+ as this change has already been applied in 2d5dbb93e6b33c2be786f9b2361c993f715d1a7f

opw-5350222

Forward-Port-Of: odoo/enterprise#101861
Forward-Port-Of: odoo/enterprise#101087

**Issue**
When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is counted multiple times, once for each IIBB tax, leading to an inflated total.

**Steps to Reproduce**
1. Install the Accounting app and the Argentinian localization (l10n_ar)
2. Set the 21% VAT Purchase tax as Included in Price
3. Create a vendor bill applying the 21% VAT tax and at least two IIBB taxes
4. Open the VAT summary report for that bill

Expected Behaviour: The total in the VAT summary should match the total shown in the accounting form view, with each tax counted only once.

**Root Cause**
The VAT summary report in the Argentinian localization relies on an SQL query to aggregate tax information for each `account.move`. The query joins `account_move_line` with `account_tax`, `account_tax_group`, and the many-to-many relation table `account_move_line_account_tax_rel`. Each `account_move_line` related to a VAT tax line (via `tax_line_id`) is joined with the `account_move_line_account_tax_rel` table. If that base line is related to multiple IIBB taxes, the join multiplies the VAT line once per IIBB tax since multiple matching rows exist.

**Fix**
The solution separates the logic for computing tax lines and base lines into two distinct subqueries. Each is aggregated independently to prevent duplication caused by one-to-many and many-to-many joins. The results are then joined using the unique `account_move_line.id`, ensuring each tax amount is counted exactly once in the final totals.

opw-4776861

Forward-Port-Of: odoo/enterprise#98933
Forward-Port-Of: odoo/enterprise#85873

This commit adds expense import test when using total_amount_currency with price_unit missing.

opw-5211041

---

**Workaround:** Use `total_amount_currency` instead of `total_amount`. Original bug complaint described below.

**Version:** Odoo 18.0, 18.4, and 19.0. The feature works as expected in Odoo 17.

**Steps:**

1. On an Odoo 18 or 19 database, ensure an Expense Category (e.g., "Meals") is configured with a tax (e.g., 12% VAT, Price Included).
2. Prepare an import file (XLSX/CSV) with columns for Total (tax-included amount) and Category.
3. Go to Expenses > My Expenses > Actions > Import records.
4. Upload the file. Map the Total column to the "Total" field and the Category column to the "Category" field.
5. Complete the import and open the newly created expense.
6. Result: The Total is correct, the Category is correct, and the 12% tax is listed, but the **`Tax Amount`** field shows 0.00.
7. Expected Result (from Odoo 17): The system should auto-calculate and populate the Tax Amount based on the Total and the tax rate from the Category.


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

There are two issues:

1) When making a purchase matching, and adding a vendor bill to a PO, when searching for the corresponding purchase order, it will not find it if the purchase order is an user with a company
2) When making a bill matching, the vendors bill will not appear.

Steps to reproduce:
-------------------
* Create a company A
* Create a partner A of type individual as a sub-partner to the company A
* Create a purchase order with partner A and confirm it
* Create a vendor bill corresponding to the purchase order

1)
* Click on the purchase matching smart button the vendor bill and try to add to PO
* Search for the purchase order
-> Issue, the purchase order does not appear.

2)
* Go on the purchase order
* Click on Bill matching smart button
-> Issue the vendor bills will not appear

Observation:
-----------
The issue is that purchase Orders store the partner exactly as selected (individual contact), while Vendor Bills are normalized internally to the parent company ("commercial_partner_id'). This creates a mismatch when making the search.
https://github.com/odoo/odoo/blob/9e9e992698946b75212040ca0ff812194200a8bf/addons/account/models/account_move_line.py#L480-L483

1) The domain of the search is
https://github.com/odoo/odoo/blob/58b888992f80a58fecdb92e23fea0050f2178faf/addons/purchase/wizard/bill_to_po_wizard_views.xml#L10-L11
The domain on the search does not take into consideration the missmatch between Vendor Bill and PO.

2) When calling action_bill_matching, the domain is:
https://github.com/odoo/odoo/blob/73590e017e9f2861b0852952e14261e57eb67f70/addons/purchase/models/purchase_order.py#L609-L621
This is a similar issue as 1) and https://github.com/odoo/odoo/commit/c0e86ba6d31708fb16765ba0e0596adc2f29dcd8

Why the fix:
------------
Commercial_partner_id is always set, adding it in the search will allow to normalize the search on the parent_company if there is one.
https://github.com/odoo/odoo/blob/18.0/odoo/addons/base/models/res_partner.py#L450-L455
opw-5067995

```
  File "/home/odoo/src/odoo/19.0/addons/account/models/ir_module.py", line 100, in _register_hook
    self.env.registry._delayed_account_translator(self.env)
  File "/home/odoo/src/odoo/19.0/addons/account/models/ir_module.py", line 90, in load_account_translations
    env['account.chart.template']._load_translations(langs=langs)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 1449, in _load_translations
    ._get_chart_template_data(chart_template)
  File "/home/odoo/src/enterprise/19.0/account_accountant/models/account_chart_template.py", line 31, in _get_chart_template_data
    data = super()._get_chart_template_data(chart_template)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 803, in _get_chart_template_data
    data = func(self, template_code)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 59, in wrapper
    return func(*args, **kwargs)
  File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_chart_template.py", line 52, in _get_be_account_reconcile_model
    prepayment_communication = self.env['qr.code.payment.wizard']._be_company_vat_communication(self.env.company).replace('+++', '')
  File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/qr_code_payment_wizard.py", line 14, in _be_company_vat_communication
    number = int(vat)
ValueError: invalid literal for int() with base 10: 'LU19038918'
```
```sql
kmod_3311837=> select id,name,chart_template,parent_id from res_company;
 id |        name         | chart_template | parent_id
----+---------------------+----------------+-----------
  3 | C.R.O.Qu.E.T. S.A.  | be_comp        |
  2 | KG5380              | be_comp        |
  1 | KNOWLEDGE GATE S.A. | lu             |
(3 rows)

kmod_3311837=> select id,model,module,res_id from ir_model_data where name = 'main_company';
 id |    model    | module | res_id
----+-------------+--------+--------
  2 | res.company | base   |      1
(1 row)
```
```
> /home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_chart_template.py(52)_get_be_account_reconcile_model()
-> if template_code in ['be', 'be_comp', 'be_asso']:
(Pdb) template_code
'be_comp'
(Pdb) self.env.company
res.company(1,)
(Pdb) self.env.company.chart_template
'lu'
(Pdb)
```

- The traceback occurs because during the translation loading process, the system calls [_get_chart_template_data](https://github.com/odoo/odoo/blob/38cffd1d1580693c56f0d897b8c8e60b938a8e85/addons/account/models/chart_template.py#L1465) for all available template codes. In the customer’s database, there are three companies: Company 2 and Company 3 use the BE_COMP localization, while Company 1 uses the LU localization.
- When _get_chart_template_data is executed for the BE_COMP chart template, it eventually calls [_get_be_account_reconcile_mode](https://github.com/odoo/enterprise/blob/d13dc2d7b54d7e43f3b27b19131d0a277d0498b8/l10n_be_reports/models/account_chart_template.py#L49) During this call, the function receives the correct template code (be_comp) as an argument. However, self.env.company returns Company 1, because Company 1 is set as the main_company.
- As a result, [_be_company_vat_communication](https://github.com/odoo/enterprise/blob/d13dc2d7b54d7e43f3b27b19131d0a277d0498b8/l10n_be_reports/models/qr_code_payment_wizard.py#L14) is called with Company 1, even though this company uses the LU localization. Since LU localization does not support the BE VAT communication logic, an error is raised from this method.
- There is no context of the company passed when calling _get_chart_template_data from _load_translations, so I have applied with_company, so _get_chart_template_data is called in the context of a specific company.
opw-5342498
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#239809

**BUG:** 
Traceback when **suggesting** deleting a BOM step from the shopfoor. 

**STEPS TO REPRODUCE:** 
- Open a shopfloor MO (with PLM installed)
-- Add a suggestion step (MO > cog> Update instructions > Improvement Suggestion > Add a step). 
-- Add a second suggestion step after the first one.
-- Delete the second suggestion step  (MO > cog> Update instructions > Improvement Suggestion > Delete a step).
-- Add a third suggest suggestion step after the second one we just suggested deleting.
-- > Traceback 

**ORIGIN:** 
First, when adding the suggestions:
 - 2 Quality Check (QC) are created on the **new_bom_id** in `add_quality_check_from_tablet.save()` 
 - 2 Quality Point (QP) are also created in  `add_check_in_chain()`, (only in mrp_workorder_plm override) 
- The 2nd new QC is linked to previous QC in `_insert_in_chain`

Secondly, when deleting the 2nd added suggestion (_on the same MO, as suggestions are linked to the new bom_id and wont appear on other MOs until ECO is validated_):
- The QP of the second QC is deleted (but the QC itself is not deleted) here:

https://github.com/odoo/enterprise/blob/f91b0c8c41f40a71cbea3cd4f5ccc6873af3c004/mrp_workorder_plm/wizard/propose_change.py#L72-L74

Finally, when adding a new suggestion after the one we just suggested deleting, in `_add_check_in_chain`, a traceback happens by trying to access the QP point we deleted in the resequencing part of  `_add_check_in_chain` here:
https://github.com/odoo/enterprise/blob/eb716c18944ec50c9c8c74a2888ed5f3032a7b08/mrp_workorder_plm/models/mrp_workorder.py#L62-L63

**FIX:**
We accept that not all QCs must have QPs  `[0]` -> `[:1]` (see note on another approach idea) changing

```diff
- point = check.point_id if check.point_id.operation_id == operation else points.filtered(lambda p: p._get_sync_values() == check.point_id._get_sync_values())[0] 
+ point = check.point_id if check.point_id.operation_id == operation else points.filtered(lambda p: p._get_sync_values() == check.point_id._get_sync_values())[:1] 
```

**NOTES:**
-1 Another fix could have been to delete the QC at the same time as the QP but I did not find any `remove_from_chain` function to safely remove the QC from the chain of QC. Along those lines we could rethink the sequencing / resequencing of QC and QP as the logic seems to differ between both. 
-2 Added some comments to remove the field and the line setting the `is_deleted` field in master as it was not used anywhere in the code (the color highlighting in the ECO is done with `<list decoration-danger="change_type=='remove'" ...>`)


ticket #5180122

**Issue:**
```python
 File "/data/build/enterprise/l10n_cl_edi/models/account_move.py", line 744, in _l10n_cl_edi_post_validation
    raise UserError(
odoo.exceptions.UserError: The stamp date and time cannot be prior to the invoice issue date and time. TIP: check in your user preferences if the timezone is "America/Santiago"
```

**Cause:**
Posting an invoice at early local hours (e.g., 2025-12-11 04:00) is converted by the [Chilean timezone (America/Santiago)](https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/l10n_cl_edi/models/l10n_cl_edi_util.py#L117-L120) to the previous day (e.g., 2025-12-10 19:30).

**Solution:**
- Freeze the test time at a stable CL-safe hour
- Add a fixed `invoice_date` aligned with the frozen timestamp

Reference : [timezone converter](https://dateful.com/time-zone-converter?t=730pm&d=2025-12-10&tz2=Santiago-Chile)
Runbot error: [234755](https://runbot.odoo.com/odoo/runbot.build.error/234755)
Related PR: https://github.com/odoo/enterprise/pull/99518