Currently, an error occurs when user tries to generate lots on a picking receipt for a product that is tracked by lots.

Steps to replicate:
- Install `stock` and create a product `test` tracked `by lots`.
- Open Inventory > Operation > Receipts , create a new one with product `test` and quantity 3.
- Open the form view of the stock move for `test` using the `view` button.
- Click `Generate Serials/Lots` and type `a` in `Quantity received` and click generate. (Error-1 will occur.)
- Click `Generate Serials/Lots` and type `a` in `Quantity per lot` and click generate. (Error-2 will occur.)

Error-1 :
```
File '/home/odoo/odoo18/community/addons/stock/models/stock_move.py', line 1055, in generate_lot_qty
    line_count = int(quantity // qty_per_lot)
                     ~~~~~~~~~^^~~~~~~~~~~~~
TypeError: unsupported operand type(s) for //: 'NoneType' and 'int'
```

Error-2 :
```
File '/home/odoo/odoo18/community/addons/stock/models/stock_move.py', line 1053, in generate_lot_qty
    if qty_per_lot <= 0:
       ^^^^^^^^^^^^^^^^
TypeError: '<=' not supported between instances of 'NoneType' and 'int'
```

Cause:
- As the user typed in alphabets the [parsefloat] returns `NaN` which will be translated to `None` python side.
- As quantity is received as None the [line1] raises Error-1.
- As qty_per_lot is recieved as None the [line2] raises Error-2.

Solution:
- Raised Usererror when quantity received or quantity per lot is either negative or not a number.

[parsefloat]: https://github.com/odoo/odoo/blob/2da791df55762ae4dc1c06d2a43fad25b09dc11b/addons/stock/static/src/widgets/generate_serial.js#L50-L51

[line1]: https://github.com/odoo/odoo/blob/2da791df55762ae4dc1c06d2a43fad25b09dc11b/addons/stock/models/stock_move.py#L1001

[line2]: https://github.com/odoo/odoo/blob/2da791df55762ae4dc1c06d2a43fad25b09dc11b/addons/stock/models/stock_move.py#L999


related-sentry-7254849206

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

**Description of the issue:**                                                                                                                                                                     
  _get_cart_and_free_qty duplicates inline the same logic already provided by _get_product_available_qty, bypassing the intended extension point.                                               
                                                                                                                                                                                                
**Current behavior:**
  _all_product_available delegates to _get_product_available_qty, but _get_cart_and_free_qty calls free_qty directly, causing inconsistent stock availability results within the same cart flow.
                                                                                                                                                                                                
**Desired behavior:**                                                                                                                                                                             
  _get_cart_and_free_qty delegates to _get_product_available_qty, making it the single extension point for all stock availability queries in the cart.

@tecnativa TT60862
@carlosdauden @pedrobaeza 


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

Selling a kit product (phantom BOM) that was tracked by lots in the Point of Sale incorrectly opened the lot/serial popup for the kit line. Only the kit's components should drive stock moves and lots; the kit product itself must not require a lot on the order line.

Steps to reproduce:
-------------------
* Create a product "Kit" with tracking = By Lots.
* Create a phantom BOM (type Kit) for that product with a component that is also tracked by lots; add stock and a lot for the component.
* Open a POS session and add the kit product to the order.

> Observation:
The Lot/Serial Number(s) Required popup appears for the kit product. After payment, stock moves are correctly created for the components (and their lots), so the popup on the kit line is wrong.

Why the fix:
------------
POS was using product.tracking only when deciding to show the lot popup, and did not treat phantom-kit products differently. With pos_mrp, stock moves for a kit line come from the BOM components, not from the kit product, so the frontend must not ask for a lot on the kit line. We add a computed flag pos_has_phantom_bom on product.product in pos_mrp and make isTracked() return false when that flag is set so the lot popup is skipped for kit products.

opw-5917964

### Issue:
Applying multi gift card from the same program results in an infinite reload cycle.

#### Steps to reproduce:
1- Create a gift card program and generate two gift cards.
2- In eCommerce add a deliverable product to cart.
3- Open cart and add both gift card codes.
4- Click on checkout to navigate to delivery step.

The page is going to keep refreshing.

### Cause:
The reload is supposed to sync the discount lines in the back-end with the discount lines displayed during checkout. If the number of lines don't match, a reload is triggered.:
https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/website_sale_loyalty/static/src/js/checkout.js#L22-L24

After the fix #191132, discount lines are grouped by `reward_id`. This is done because in the back-end, by applying a single percent discount, separate lines are created per product lines with different taxes, while in front-end there is still single line.

However, that fix doesn't consider that a SO might have multiple lines of the same reward: ewallet, gift_card

### Fix:
This can be fixed by separating logic of groupable lines which are the lines with `percent` mode, with `per-point` mode lines.

Discount is the only mode that might be added to multiple lines separately, keeping #191132 fix, and `per-point` is the only mode that might be applied multiple times per reward (in ewallet and gift_card).

opw-5485912

Issue
-----
When doing delivery -> return -> re-delivery, only one label is received even when there are mutliple packages to be "re-delivered".

Steps to reproduce
-----
- Create a UPS delivery
- Multiple packages
- Validate transfer
- Return
- Validate IN
- Return again
- Add the UPS under the "additional info" tab
- Ensure still multiple packages
- Validate OUT

Cause
-----
When preparing the shipping data, we go through

https://github.com/odoo/enterprise/blob/913e55abc4a9aa58509aa2a60d378fb552de554d/delivery_ups_rest/models/delivery_ups.py#L120-L121

which leads us to do

https://github.com/odoo/odoo/blob/89733b0e4d1e9a57dd25f552db4e6330a6b14cdf/addons/stock_delivery/models/delivery_carrier.py#L142-L155

so we end up with a single package to send to the delivery service. The reason `is_return_picking` is true is because the compute method only checks for an existing move with an `origin_returned_move_id`.

https://github.com/odoo/odoo/blob/89733b0e4d1e9a57dd25f552db4e6330a6b14cdf/addons/stock_delivery/models/stock_picking.py#L53-L58

From a delivery flow perspective, it doesn't make much sense to consider outgoing shipments as returns.

-----
Ticket:
opw-5866100

### Issue:

Cannot get passed the address form in `ar` localization.

#### Steps to reproduce:
1- Set up a company with Argentinian localization.
2- Set the portal user to this company.
3- Add an address and set country to `Argentina`.
4- Assign website to Argentinian company;
5- As the portal user, add something to cart.
6- go to checkout, and save the address.

You will get the error that some fields are missing.

### Cause:

This issue is partially fixed in https://github.com/odoo/odoo/pull/239998. However, there are three issues left:

1. That fix doesn't show the error regarding 'Identification and AFIP Resposibility Types' when we have `use_delivery_as_billing`. As a result a generic error `some fields are missing` is shown.

2. `can_edit_vat` is used in:
https://github.com/odoo/odoo/blob/5b39cdceb84758f767b83b741be927c1a7cfac7a/addons/l10n_ar_website_sale/views/templates.xml#L7-L9
https://github.com/odoo/odoo/blob/5b39cdceb84758f767b83b741be927c1a7cfac7a/addons/l10n_ar_website_sale/views/templates.xml#L32-L35
This needs to also consider `l10n_ar_afip_responsibility_type_id` and `l10n_latam_identification_type_id` being set.

3. Also we need to make sure `Identification Number` which is `vat` is set if we want to prevent it from being modified.

opw-5376149

affected versions: 16, 17

The query for `_sdd_get_usable_mandate` is far from optimal.

An EXPLAIN ANALYZE shows some pain points that we address in this PR: https://explain.dalibo.com/plan/c4eddda16fa4cf39

- Indexing `sdd_mandate` in `account.move` lets the subquery use an Index Scan instead of a full-table Seq Scan.
- Without changing the logic of the subquery it is now way more performant using NOT EXISTS, which avoids the Aggregate node and enables early exit.

These two minor changes yield a ~10x speedup in our tests.

(probably there's more performance to gain, although this seems to be an issue that will cease on later versions)


Some captures on performance over ~2000 payments. Before, a big chunk of the time was spent retrieving the mandate. The more operations the larger the time:

<img width="1246" height="655" alt="image" src="https://github.com/user-attachments/assets/3b6695e1-dbb0-46fa-a22c-fba0e9c2ec2b" />

Now over the same amount of payments, the mandates retrievement isn't that troubling anymore:

<img width="1050" height="609" alt="image" src="https://github.com/user-attachments/assets/63ad88d1-51a0-4607-ae50-8022cf4cffc7" />


cc @moduon MT-11292

fyi @yajo

Forward-Port-Of: odoo/enterprise#97410

Currently, it is possible to set a DateV identifier on a partner even if it is already assigned to an archived partner. This leads to duplicate identifiers if the archived partner is later unarchived.

###  **Steps to reproduce:**
1) Install **l10n_de_reports, Contacts** App with Demo Data. 
2) Switch to a **DE company**.
3) Create a contact 'Test-A' and set `'DateV Vendor' to 123456789` in the **Accounting Section**. 
4) Archive 'Test-A'.
5) Create 'Test-B' and set `'DateV Vendor' to 123456789`. 
6) Unarchive 'Test-A'.

### **Observed Behavior:**
'Test-B' is created successfully. After step 6, both 'Test-A' and 'Test-B' are active with the same DateV identifier.

### **Expected Behavior:**
A validation error should be raised when trying to save 'Test-B', stating that the identifier is already defined.

### **Root Cause:**
Since [this commit](https://github.com/odoo/enterprise/commit/733c4ba1fd5558891ffdbc67066c3a3a5938e2f0), company-dependent fields are stored as JSONB in the database. Due to this improvement, the previous SQL constraint (which enforced uniqueness across all records) was removed and replaced with a Python constraint.

However, the new Python constraint utilizes `search_count`, which by default filters out archived records (`active=False`). This allows the reuse of identifiers belonging to archived partners, breaking the uniqueness requirement that existed in previous versions.

Fix:
Update the `_check_datev_identifier` and `_check_datev_identifier_customer` constraints to use `with_context(active_test=False)`. This ensures that the uniqueness check considers all partners, including archived ones.

opw-5474106