**Steps to reproduce:**
- Install Accounting and l10n_sa_edi
- Switch to a Saudi Arabian company (e.g. SA Company)
- Duplicate "Customer Invoices" journal:
  * Default Income Account: 500001 Sales Account
  * Electronic invoicing: [disabled]
- Create a retention tax:
  * Name: Retention 10%
  * Amount: -10.00000%
  * Is Retention: [checked]

- Create an invoice:
  * Customer: [a Saudi Arabian contact] (e.g. ARAMCO Medinah Branch)
  * Journal: Customer Invoices
  * Invoice Lines:
    - Price: 100.00
    - Taxes: "Sales Tax 15%" + "Retention 10%"
- Confirm the invoice
- Print the invoice
- Scan the QR code on the invoice with an app like "E-invoice QR Reader"

=> In the QR code, the total amount of the invoice with VAT included is 115.00 and the total amount of the VAT is 15.00.
The amount of the retention tax is excluded from the total and the VAT amounts, which is the expected behavior.

- Create the exact same invoice with the duplicated journal without electronic invoicing
- Confirm the invoice
- Print the invoice
- Scan the QR code on the invoice

**Issue:**
In the QR code, the amount of the retention (-10.00) is taken into account.
The total amount of the invoice with VAT included is 105.00 and the total amount of the VAT is 5.00.
The QR code should provide the same amounts either the used journal has "Electronic invoicing" enabled or not.

**Cause:**
Depending on the presence of an electronic invoice document or not, the QR code is generated by the overriding compute method from "l10_sa_edi" or the original one in "l10n_sa".
However, the "Is Retention" field of the "account.tax" model is introduced by "l10n_sa_edi" module and when the QR code is computed by the original method, this field is not taken into account and the corresponding retention tax is wrongly handled like any other tax.

**Solution:**
Use the same total amounts than the ones computed in "l10n_sa_edi" (where retention tax are excluded) in the original compute method if "l10n_sa_edi" is installed.

**Issue 2:** (revealed by the fix)
In "_get_invoice_line_allowance_vals_list" method, a variable can be used without being assigned (i.e. "fixed_tax_charge_vals_list").

opw-4525519



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

Forward-Port-Of: odoo/odoo#196640

Issue
=====
When product's code is computed, which is depend of the product's suppliers since each supplier can have a specific code, the first supplier is taken regardless if this supplier info is specific to another product variant which can cause to use the wrong code if there is multiple supplier with the same vendor but for different variants of the same product template.

How to reproduce
================
1. Install Puchase and Barcode;
2. Create a product with at least 2 variants;
3. In the "Purchase" tab of this product, add two vendor pricelists with the same vendor but each for a different product variant and each with a different code;
4. Go in Purchase, create a new RFQ for this vendor, add a PO line for each variant and confirm the order;
5. Go in Barcode and open the PO's receipt -> You can see both lines have the same vendor's code (from the first pricelist) regardless the pricelist's product variant.

Cause of the issue
==================
In `_compute_product_code`, it uses the first product (template) supplier info regardless the product variant.

Solution
========
In `_compute_product_code`, we skip a supplier info if it concerns another variant, and we break the supplier info loop only if it concerns the current product variant.

Miscellaneous
=============
The check of the `product.supplierinfo` `read` access right is moved outside of the loop so it is done only one time.

[OPW-4589073](https://www.odoo.com/odoo/project/49/tasks/4589073)

Forward-Port-Of: odoo/odoo#201900
Forward-Port-Of: odoo/odoo#201753

Issue: In Barcode, performing certain operations and then reverting your changes can drastically affect the state of records: "picked" status or the visual demand of the move.

### Steps to reproduce:

- Create a storable product tracked by SN. Put 2 SN in stock SN1 and SN2
- Create a delivery order for 2 units and mark as to do.
> The two SN's should be reserved on your delivery.
- Go to the barcode app, scan SN1.
- Edit edit the SN1 line to set the qty back to 0.
- Leave the barcode app and come back to the record.
#### > The subline related to SN1 displays now a demand of 0. A new barcode line has been created with a demand of 1 for SN1. In short an extra record was created unecessarily.

### Cause of the issue:

In the barcode app the demand of each line is measured by the quantity present on its move lines. In our set up, the move is related to 2 moves lines with a quantity of 1 that are not picked. Scanning SN1 will update the qty_done of its line to 1. As such, the move line quantity will be set from 1 to 1 and the move line will be picked:
https://github.com/odoo/enterprise/blob/e8c831a540c12019c560cc19abf7abe8785d0e0e/stock_barcode/models/stock_move_line.py#L58-L61 In turns, the picked state of the move will be set to picked: https://github.com/odoo/odoo/blob/7bc38562f1988ba15525c04168e30c06a8f1d33c/addons/stock/models/stock_move.py#L208-L212 Now, editing the qty done of the move once more from 1 to 0 to reset the reservation will not revert the process for 2 reasons:
1. The quantity of the move line will be reset form its current value to 0, altering the demand of the barcode line to 0.
2. Even if the move line was unpicked in this process, the picked compute method of the move will never reset the picked state as the compute method can only set a True value.

We therefore end up with a picked move without any picked move line and for which one of the picked move line has a quantity of 0. Now, leaving the barcode app will launch the split_uncompleted_moves method in order to not lose the changes made to the record and since the move is picked for the wrong reason, the move will be splitted in 2 instead of escaping the split process.
https://github.com/odoo/enterprise/blob/e8c831a540c12019c560cc19abf7abe8785d0e0e/stock_barcode/models/stock_move.py#L21-L22

Enterprise: https://github.com/odoo/enterprise/pull/80675

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

Forward-Port-Of: odoo/odoo#202469
Forward-Port-Of: odoo/odoo#200167

Commit 0bdfda2af4d70a6c33773ecd4aaa717ef6a17d62 introduced a new behavior where delivery transfer to transit locations (inter companies transfer) could create a new Sale Order Line if necessary. However, we do not want this behavior if the transit location is just a step in the delivery to the Customer location.

Hence, if there are any destination moves, we do not create a new sale order line.

OPW-4643937

---

Test result without fix:
```
2025-03-19 16:08:42,057 57047 ERROR oes_test_17.4 odoo.addons.sale_stock.tests.test_sale_stock: FAIL: TestSaleStock.test_custom_delivery_route_new_sale_line
Traceback (most recent call last):
  File "/home/odoo/projects/odoo-src/multiverse/src/saas-17.4/odoo/addons/sale_stock/tests/test_sale_stock.py", line 2197, in test_custom_delivery_route_new_sale_line
    self.assertEqual(len(sale_order.order_line), 1)
AssertionError: 2 != 1
 ``` 

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

Forward-Port-Of: odoo/odoo#202559

Steps to reproduce:

- In any of the SOL Many2one field with create=True.
- Create a SOL using create option in dropdown.

Issue:

- A SOL is created without product.

Reason:

- Incorrect SQL constraint passed .

Fix:

- Adding a validation error which is tapped in if Many2one quick create i.e.,
Create option fails and opens the Many2X form.

- We cant change the SQL contraint because it is only applied when module
is intalled/updated/reinstalled.

---
Why the SQL contsraint fails

"CHECK(display_type IS NOT NULL OR is_downpayment OR (product_id IS NOT NULL AND product_uom IS NOT NULL))"

Also is_downpayment doesnt have a default value.

Here consider we dont event send a single value all as nulls then result would
be

CHECK(NULL IS NOT NULL OR NULL OR (NULL IS NOT NULL AND NULL IS NOT NULL))

CHECK(FALSE OR NULL OR (FALSE AND FALSE)

CHECK(FALSE OR NULL OR FALSE)

CHECK(NULL)

SQL doesn't categorize NULL into truthy or falsy value.

For example a SQL constraint as
CHECK (row1 NOT NULL OR row2 ...(and N number of conditions)) -- will always
pass the check (even if you pass all the rows as NULL)

NULL OR NULL -- TRUE (passes the empty NULL column value as [null])
FALSE OR NULL -- TRUE (passes the empty NULL column value as [null])
TRUE OR NULL -- TRUE

It there is another column which has value it glady create a row with values
and [null]/empty value for others.

task-4441043

Co-Authored By - @xavierbol

Forward-Port-Of: odoo/odoo#192464

Nothing prevents from creating templates and composers on non thread
models. However most necessary code relies on mail.thread.

Here we move code from mail.thread directly to BaseModel. For most
business models it does not change anything. For some side models
it allows / fixes usage of SMS composer, allowing to dynamically
find numbers / partners, ...

One notable use case that triggered this PR is sending of SMS to
users using their work phone number, or through their partner. Either
we hack user model, either we provide a generic fix.

Note that in current master (18.2+) most 'mail' generic features are
supported on non-thread models (template usage and sending, mailing
using composer, ...). SMS is still thread-specific while phone
capabilities have already been moved to generic code.

We therefore continue towards generic simple mail / sms usage on
business records, while advanced features (followers, logs, direct
post using SMS type) require thread-enabled models.

Task-4113190
sentry-4681535519

Forward-Port-Of: odoo/odoo#202454
Forward-Port-Of: odoo/odoo#200650

Issue: In Barcode, performing certain operations and then reverting your changes can drastically affect the state of records: "picked" status or the visual demand of the move.

### Steps to reproduce:

- Create a storable product tracked by SN. Put 2 SN in stock SN1 and SN2
- Create a delivery order for 2 units and mark as to do.
> The two SN's should be reserved on your delivery.
- Go to the barcode app, scan SN1.
- Edit edit the SN1 line to set the qty back to 0.
- Leave the barcode app and come back to the record.
#### > The subline related to SN1 displays now a demand of 0. A new barcode line has been created with a demand of 1 for SN1. In short an extra record was created unecessarily.

### Cause of the issue:

In the barcode app the demand of each line is measured by the quantity present on its move lines. In our set up, the move is related to 2 moves lines with a quantity of 1 that are not picked. Scanning SN1 will update the qty_done of its line to 1. As such, the move line quantity will be set from 1 to 1 and the move line will be picked:
https://github.com/odoo/enterprise/blob/e8c831a540c12019c560cc19abf7abe8785d0e0e/stock_barcode/models/stock_move_line.py#L58-L61 In turns, the picked state of the move will be set to picked: https://github.com/odoo/odoo/blob/7bc38562f1988ba15525c04168e30c06a8f1d33c/addons/stock/models/stock_move.py#L208-L212 Now, editing the qty done of the move once more from 1 to 0 to reset the reservation will not revert the process for 2 reasons: 
1. The quantity of the move line will be reset form its current value to 0, altering the demand of the barcode line to 0.
2. Even if the move line was unpicked in this process, the picked compute method of the move will never reset the picked state as the compute method can only set a True value.

We therefore end up with a picked move without any picked move line and for which one of the picked move line has a quantity of 0. Now, leaving the barcode app will launch the split_uncompleted_moves method in order to not lose the changes made to the record and since the move is picked for the wrong reason, the move will be splitted in 2 instead of escaping the split process.
https://github.com/odoo/enterprise/blob/e8c831a540c12019c560cc19abf7abe8785d0e0e/stock_barcode/models/stock_move.py#L21-L22

Community: https://github.com/odoo/odoo/pull/200167

opw-4600565

Forward-Port-Of: odoo/enterprise#81744
Forward-Port-Of: odoo/enterprise#80675