Currently an error occurs when the **'Payroll: Generate pdfs'** scheduled action runs and tries to create a document for a payslip belonging to an employee who does not have a related partner.

**Prerequisites:**
- Ensure HR is enabled in `settings>Documents`

**Steps to Reproduce:**
1) Install `documents_hr_payroll` module.(with Demo) 
2) Navigate to the Employees App.
3) Select any Employee(e.g Abigail Peterson) and open form view.
>- click on **contacts** smart button.
>- Delete that Record
4) Create a confirmed Payslip for the selected Employee(e.g Abigail Peterson). 
5) Activate Developer mode and navigate to schedule Actions.
>- Search for 'Payroll: Generate pdfs'.
>- Run Manually.

Error:
`NotNullViolation: null value in column 'partner_id' of relation 'documents_access' violates not-null constraint`

Root Cause:
When the partner is deleted, the value received from `_get_document_partner` at [1]
is `False`, which later on tries to create the `documents.access`
record for the new document, it fails because no partner is available to assign
access rights, resulting in the error.


Solution:
This commit prevent Error by ensuring `_check_create_documents` method doesn't allow document creation without valid partner.

[1]: https://github.com/odoo/enterprise/blob/99a8d83edb42f172d0dd35c91743fa0c9653dcbb/documents_hr_payroll/models/hr_payslip.py#L20C1-L21 

sentry-6814524392

Forward-Port-Of: odoo/enterprise#96191
Forward-Port-Of: odoo/enterprise#92865

### Problem  
When clicking **"Export PDF"** on a 325 form that has **no generated 281.50 forms**, Odoo raised a **server error**:  


This happened because the method assumed that at least one attachment would always be generated, even if no eligible transactions were present.

---

### Steps to Reproduce  
1. Go to **Accounting → Reporting → 325 Form**.  
2. Create a 325 form for a year without any transactions on accounts tagged with **281.50**.  
3. Do not generate any 281.50 forms (`form_281_50_ids` is empty).  
4. Click **Export PDF**.  

**Result before fix:**  
- Crash with `IndexError: list index out of range`.  

---

### Solution  
- Added a safeguard check before accessing attachments.  
- If no attachments exist, raise a **UserError** instead of crashing.  

**New behavior:**  
> *“No 281.50 lines found to generate a PDF. Please record a transaction with a 281.50 tag first.”*  

This gives users a instruction on how to resolve the issue.

---

### Result After Fix  
- **User error message** replaces traceback.  
- **Normal behavior preserved** when attachments exist:  
  - One file → direct download.  
  - Multiple files → zipped download.  

---

task-5090120

Forward-Port-Of: odoo/enterprise#94877

**Issue**
When accessing the EC Sales List report via the smart button from the VAT Return page, downloading the XML without explicitly selecting a period omits the <Month> element—even though a month is visibly preselected.

**Steps to Reproduce**
1. Install the Accounting module and Belgium localization.
2. Go to the Accounting dashboard.
3. Open the VAT Return via the "Miscellaneous Operations" section.
4. Click the smart button to access the EC Sales List report.
5. Use the gear icon to export the XML.
6. Observe that the XML <Period> section only includes the <Year>—the <Month> is missing.

**Root Cause**
If no period is explicitly selected, the report uses a period_type of "tax_period". However, this value was not handled when generating the XML, so the logic to include the \<Month> or \<Quarter> elements skipped it. As a result, only the \<Year>, which is always included, was rendered.

**Fix**
Extend the handling of tax_period to derive the period from the company’s tax periodicity settings and adjust the filter accordingly. This ensures that the generated XML always includes the \<Month> or \<Quarter> element, in addition to \<Year>, whenever the report is based on a tax period.

Opw-4702613

Forward-Port-Of: odoo/enterprise#93647
Forward-Port-Of: odoo/enterprise#89290

### Issue:

In this bug, the workorder duration being set to duration_expected is causing issues in backorder.

To reproduce:
1- Create a Bill of Materials with at least two operations at two work centers
2- Create a manufacturing order and confirm it.
3- Complete the first operation and edit the quantity on the second operation so there is a backorder for the remaining quantity.
4- In the second work order, the first operation is cancelled, Finish the 2nd operation
5- As you can see, the cancelled operation duration is set to expected duration which is wrong.

### Cause:

This issue is caused because of:
https://github.com/odoo/odoo/blob/8f0e40286da7b144bfa17880a257406dd8585e57/addons/mrp/models/mrp_production.py#L1774-L1779

Which if work.order.state is `cancel`, the duration will set to `duration_expected`.
This will eventually cause issue here:
https://github.com/odoo/odoo/pull/222075/commits/8f0e40286da7b144bfa17880a257406dd8585e57#diff-fac872ffb03b811c4976eb2e52991ec544265332df814d92cfda658a5b917423L348
which is fixed by not making the state into `progres` if the state is `cancel`.
But that doesn't fix the fact that the cancelled workorder has duration set and it might cause inconsistencies in manufacturing costs.

related:
#222075

opw-4931653

Forward-Port-Of: odoo/odoo#229975
Forward-Port-Of: odoo/odoo#229742

# Problem

Unreserve issue preventing users from validating a delivery order with 2-step delivery warehouse configuration. Introduced in the following commit: https://github.com/odoo/odoo/commit/13567aa27250f5798bbe42648eeac82241dbb780

# Steps to reproduce on the runbot:

- Activate packages
- Edit the warehouse to deliver in 2-steps
- Create a product tracked by lot
- Create two lots with 5 qty each
- Create a sale order with 10 qty and confirm
- Check the delivery order and assign: 
=> 2 units to lot1 and create a pkg for it
=> 1 units to lot1 without pkg
=> 3 to lot2 without package
- Validate the delivery and create a backorder
- go to pick backorder and try to validate
- Unreserve issue pops up
- For further details, check: [#225948](https://github.com/odoo/odoo/issues/225948)

# Solution:

Conditional subtracting limited to new lines only.

Task ID: opw-5086289


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

Forward-Port-Of: odoo/odoo#229994
Forward-Port-Of: odoo/odoo#229420

### Problem  
When clicking **"Export PDF"** on a 325 form that has **no generated 281.50 forms**, Odoo raised a **server error**:  


This happened because the method assumed that at least one attachment would always be generated, even if no eligible transactions were present.

---

### Steps to Reproduce  
1. Go to **Accounting → Reporting → 325 Form**.  
2. Create a 325 form for a year without any transactions on accounts tagged with **281.50**.  
3. Do not generate any 281.50 forms (`form_281_50_ids` is empty).  
4. Click **Export PDF**.  

**Result before fix:**  
- Crash with `IndexError: list index out of range`.  

---

### Solution  
- Added a safeguard check before accessing attachments.  
- If no attachments exist, raise a **UserError** instead of crashing.  

**New behavior:**  
> *“No 281.50 lines found to generate a PDF. Please record a transaction with a 281.50 tag first.”*  

This gives users a instruction on how to resolve the issue.

---

### Result After Fix  
- **User error message** replaces traceback.  
- **Normal behavior preserved** when attachments exist:  
  - One file → direct download.  
  - Multiple files → zipped download.  

---

task-5090120

Forward-Port-Of: odoo/enterprise#94877

**Issue**
When accessing the EC Sales List report via the smart button from the VAT Return page, downloading the XML without explicitly selecting a period omits the <Month> element—even though a month is visibly preselected.

**Steps to Reproduce**
1. Install the Accounting module and Belgium localization.
2. Go to the Accounting dashboard.
3. Open the VAT Return via the "Miscellaneous Operations" section.
4. Click the smart button to access the EC Sales List report.
5. Use the gear icon to export the XML.
6. Observe that the XML <Period> section only includes the <Year>—the <Month> is missing.

**Root Cause**
If no period is explicitly selected, the report uses a period_type of "tax_period". However, this value was not handled when generating the XML, so the logic to include the \<Month> or \<Quarter> elements skipped it. As a result, only the \<Year>, which is always included, was rendered.

**Fix**
Extend the handling of tax_period to derive the period from the company’s tax periodicity settings and adjust the filter accordingly. This ensures that the generated XML always includes the \<Month> or \<Quarter> element, in addition to \<Year>, whenever the report is based on a tax period.

Opw-4702613

Forward-Port-Of: odoo/enterprise#89290

**Issue**
When the delivered quantity of a product is less than the originally demanded quantity, the generated Delivery Guide XML shows the demand (product_uom_qty) instead of the actual delivered quantity (quantity). This results in an incorrect quantity being displayed in the DTE.

**Steps to Reproduce**
1. Install the Accounting module, Chilean localization, Sales module, and l10n_cl_edi_stock.
2. Create and confirm a new Sale Order.
3. Click on the Delivery smart button.
4. Adjust the delivered quantity to a value lower than the demand, save, and validate with no backorder.
5. Generate the Delivery Guide.
6. Open the generated DTE XML and observe that the quantity is incorrect.

**Root Cause**
The quantity displayed in the DTE is taken from product_uom_qty, which represents the planned quantity to be moved, not the actual delivered quantity. The correct field to use is quantity, which reflects the real delivered amount.

**Fix**
Change the XML output to use quantity instead of product_uom_qty to accurately reflect the actual delivered quantity in the DTE.

Opw-4892276

Forward-Port-Of: odoo/enterprise#93260
Forward-Port-Of: odoo/enterprise#89633

Steps to reproduce:
- Unarchive subcontracting operation type
- Create a storable product P1 with a BoM:
    - BoM type: Subcontracting
    - Subcontractor: Azure Interior
    - Component C1 (route: Resupply Subcontractor on Order)
- Create a purchase order:
    - Vendor: Azure Interior
    - 10 units of P1
    - Confirm the PO → 2 pickings are created:
        - Resupply of 10 units of C1
        - Receipt of 10 units of P1
- Confirm and validate the resupply of C1
- Components are reserved in the subcontracting MO
- Validate the consumption of 10 units in the receipt
- The MO is updated to 10
- Update the quantity of P1 to 0 in the receipt

Issue:
The manufacturing order is cancelled. As a result, subsequent updates on the receipt cannot recreate MOs.

Fix:
When reducing the receipt quantity, cancel only the extra MOs, but always keep at least one open MO if a subcontracting move is still ongoing.

opw-4792379

Forward-Port-Of: odoo/odoo#225236
Forward-Port-Of: odoo/odoo#223858

### Issue: 
The partner ledger does consider lines without partners when calculating the initial balance.

### Steps to reproduce:
- Create an invoice in 2025
- Create an entry in 2025 without partner for the same amount
- Reconcile the two
- Open the partner ledger for 2025, everything is correct
- Change the dates to 2026, the amount of the initial balance ignores the entry but not the totals

### Cause:
The method `_get_sums_without_partner` is called for the totals, but not for the initial balance. Its purpose is to add the amounts of the lines without partners that were reconciled with lines with a partner.

### Solution:
Call `_get_sums_without_partner()` in `_get_initial_balance_values()` add the results before returning the initial balances.

As this is the same logic as `_query_partners()` we create a new method.

This method needs to be called with the dates of the initial balance in the options. So we create a duplicate of the options and input the new dates options.

opw-5068790

Forward-Port-Of: odoo/enterprise#96125
Forward-Port-Of: odoo/enterprise#95881

### Problem  
When clicking **"Export PDF"** on a 325 form that has **no generated 281.50 forms**, Odoo raised a **server error**:  


This happened because the method assumed that at least one attachment would always be generated, even if no eligible transactions were present.

---

### Steps to Reproduce  
1. Go to **Accounting → Reporting → 325 Form**.  
2. Create a 325 form for a year without any transactions on accounts tagged with **281.50**.  
3. Do not generate any 281.50 forms (`form_281_50_ids` is empty).  
4. Click **Export PDF**.  

**Result before fix:**  
- Crash with `IndexError: list index out of range`.  

---

### Solution  
- Added a safeguard check before accessing attachments.  
- If no attachments exist, raise a **UserError** instead of crashing.  

**New behavior:**  
> *“No 281.50 lines found to generate a PDF. Please record a transaction with a 281.50 tag first.”*  

This gives users a instruction on how to resolve the issue.

---

### Result After Fix  
- **User error message** replaces traceback.  
- **Normal behavior preserved** when attachments exist:  
  - One file → direct download.  
  - Multiple files → zipped download.  

---

task-5090120

Forward-Port-Of: odoo/enterprise#94877

**Issue**
When accessing the EC Sales List report via the smart button from the VAT Return page, downloading the XML without explicitly selecting a period omits the <Month> element—even though a month is visibly preselected.

**Steps to Reproduce**
1. Install the Accounting module and Belgium localization.
2. Go to the Accounting dashboard.
3. Open the VAT Return via the "Miscellaneous Operations" section.
4. Click the smart button to access the EC Sales List report.
5. Use the gear icon to export the XML.
6. Observe that the XML <Period> section only includes the <Year>—the <Month> is missing.

**Root Cause**
If no period is explicitly selected, the report uses a period_type of "tax_period". However, this value was not handled when generating the XML, so the logic to include the \<Month> or \<Quarter> elements skipped it. As a result, only the \<Year>, which is always included, was rendered.

**Fix**
Extend the handling of tax_period to derive the period from the company’s tax periodicity settings and adjust the filter accordingly. This ensures that the generated XML always includes the \<Month> or \<Quarter> element, in addition to \<Year>, whenever the report is based on a tax period.

Opw-4702613

Forward-Port-Of: odoo/enterprise#93647
Forward-Port-Of: odoo/enterprise#89290

Resolve theme options compatibility, editing behavior, accessibility
and design problems affecting UX and standards compliance.

Adherence to theme options:
- Apply border-radius correctly to target elements
- Fix bg-color applying to text-area instead of intended container

Edition:
- Remove resize/style options on the column since these are not retained
  on save
- Fix the preview that mismatch with actual rendered result
- Resolve title/form misalignment in edit mode
- Ensure "OR" text readability across different background colors
- Preserve container size when the "fullscreen" feature is activated

Accessibility:
- Add missing focus state for form fields
- Add role="presentation" to icons
- Add role="button" to anchor tags functioning as buttons

Design:
- Reduce oversized title font size
- Adjust container width on xl and xxl breakpoints
- Smooth fullscreen transition to prevent abrupt activation

| 19.0 | this PR |
|--------|--------|
| <img width="1092" height="424" alt="image" src="https://github.com/user-attachments/assets/5cd85204-b9af-4810-9458-c4c96dad562d" /> | <img width="1083" height="409" alt="image" src="https://github.com/user-attachments/assets/b83f2d18-0135-4f5d-b420-11f58070c8a3" /> | 


task-5089787

*: website_sale

__Current behavior before commit:__
Some builder actions (e.g `ProductPageImageLayoutAction`) reload the
editor after being applied. If another button in the builder is pressed
rapidly, `refreshCurrentItem` might be called after the editor is
destroyed leading to the following error in [`isApplied`]:

`TypeError: Cannot read properties of undefined (reading 'getAction')`.

The "Product page options" test fails in rare occasion due to this
issue.

__Description of the fix:__
- Add a safety guard to make sure the editor is not destroyed before
calling `refreshCurrentItem`.
- Add some checks at the end of the test in order for the crash to
appear consistently (if the fix is not applied).
- Make the test more robust (some code is backported from
[this commit]).

[this commit]: https://github.com/odoo/odoo/commit/670b1daa2254d76
[`isApplied`]: https://github.com/odoo/odoo/blob/f258b263136f606f7896/addons/html_builder/static/src/core/utils.js#L939

Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/232649

Forward-Port-Of: odoo/odoo#227739

### Issue:

In this bug, the workorder duration being set to duration_expected is causing issues in backorder.

To reproduce:
1- Create a Bill of Materials with at least two operations at two work centers
2- Create a manufacturing order and confirm it.
3- Complete the first operation and edit the quantity on the second operation so there is a backorder for the remaining quantity.
4- In the second work order, the first operation is cancelled, Finish the 2nd operation
5- As you can see, the cancelled operation duration is set to expected duration which is wrong.

### Cause:

This issue is caused because of:
https://github.com/odoo/odoo/blob/8f0e40286da7b144bfa17880a257406dd8585e57/addons/mrp/models/mrp_production.py#L1774-L1779

Which if work.order.state is `cancel`, the duration will set to `duration_expected`.
This will eventually cause issue here:
https://github.com/odoo/odoo/pull/222075/commits/8f0e40286da7b144bfa17880a257406dd8585e57#diff-fac872ffb03b811c4976eb2e52991ec544265332df814d92cfda658a5b917423L348
which is fixed by not making the state into `progres` if the state is `cancel`.
But that doesn't fix the fact that the cancelled workorder has duration set and it might cause inconsistencies in manufacturing costs.

related:
#222075

opw-4931653

Forward-Port-Of: odoo/odoo#229975
Forward-Port-Of: odoo/odoo#229742

### Issue:

#### Steps to reproduce:
1- Activate routes & locations and enable Reception Report
2- Enable Show reception report at validation from operation type: receipts
3- Create a product with vendor. Put 2 unit on `WH/Stock/Shelf1`
4- Create a Sales Order for 3 units.
5- Create a PO for 1 unit and validate/receive.
6- On the Reception Report, click Assign to link incoming to sales pick
7- Open the sales pick in a new tab, observe there are 2 moves which first one is 1 and 2nd one is 2
8- On the reception report, click Unassign, then Assign again

Back on the Pick, only 1 move (the one with quantity of 2) is reserved; checking availability reserves nothing although stock exists.

#### Cause:
When unassigning from the Reception Report, the system incorrectly unreserves stock that was already in `Shelf1` instead of unreserving the incoming move which the location_id is `WH/Stock`:

User clicks Unassign on the Reception Report.
`report_stock_reception.action_unassign()` is invoked.
That calls `stock_move._do_unreserve()`.
`_do_unreserve()` unpicks quants referenced by the `move.move_line_ids`.
At this moment one of the `move_line_ids` points to `WH/Stock/Shelf1`, so `_do_unreserve()` removes the reservation from that `shelf1` quant.
Consequence: `shelf1` stock(which should have remained reserved) becomes free. The receipt quant at `WH/Stock` remains reserved/ unavailable.

When the user clicks Assign again, the system cannot reserve because it is alreade reserved by another move and therefore it is unavailable.

#### Root cause:
Now we look earlier in the flow to see why the move had a move_line pointing to `WH/Stock/Shelf1` in the first place. Earlier, in `report_stock_reception.action_assign` in the first assign:
We create a new move from current outgoing move:
https://github.com/odoo/odoo/blob/35ea3dcb2eeb379c8b1127f0c7b42191853c0bd2/addons/stock/report/report_stock_reception.py#L224-L231 And we link current move_lines to the new move:
https://github.com/odoo/odoo/blob/35ea3dcb2eeb379c8b1127f0c7b42191853c0bd2/addons/stock/report/report_stock_reception.py#L245-L259 new_out.move_line_ids now contains move lines for multiple source locations, here in our case `[WH/Stock/Shelf1, WH/Stock]` The loop in above code does not check `move_line_id.location_id` when selecting lines. The first matching line in the iteration can be the `shelf1` one, so the code links the `shelf1` move_line to out instead of the `WH/Stock` move_line, which is a mismatch and causes the out move having different location with its move_line, which later will going to cause problem is unassign as explained.

### Fix:
We can sort move_line_ids in a way that which line have the same location as potential ins' dest locations come first
as better candidates:
```diff
- for move_line_id in new_out.move_line_ids:
+ matching_locations = potential_ins.location_dest_id
+ for move_line_id in new_out.move_line_ids.sorted(lambda ml: ml.location_id not in matching_locations):
```

opw-4944047

Forward-Port-Of: odoo/odoo#229954
Forward-Port-Of: odoo/odoo#226120

**Description of the issue/feature this PR addresses:**
When creating or editing an analytic distribution, the analytic account selection does not respect the company context.
This allows users to see and select analytic accounts from other companies, which violates the multi-company record rules.

<img width="669" height="333" alt="2025-09-08_09-28" src="https://github.com/user-attachments/assets/488eb4b1-fdfa-49ca-a57e-8f46a264107d" />


**Current behavior before PR:**
The analytic account dropdown in the analytic distribution widget shows analytic accounts from all companies, instead of being restricted to the current company.

**Desired behavior after PR is merged:**
The analytic account selection in the analytic distribution widget is filtered by company.
Only analytic accounts belonging to the document company will be displayed, ensuring compliance with multi-company record rules.




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

Forward-Port-Of: odoo/odoo#228935
Forward-Port-Of: odoo/odoo#225835

Versions
--------
- 18.0+

Steps
-----
1. Enable Google address autocomplete;
2. go eCommerce checkout;
3. add an address during the delivery step;
4. autocomplete a bunch of addresses.

> [!Note]
> I haven't been able to reproduce it myself, but others have.
> It appears that the order Google provides place types isn't always the same.

Issue
-----
You may get a `KeyError`, trying to fetch `standard_data['country']`.

Cause
-----
The fields get sorted by type, and we try to sort `country` before `state`, so that the `country` key should be present when we get to `state`.

The likely issue is that Google often provides multiple types per field, and we only keep the first one, assuming it to be the most relevant one, but the API documentation makes no guarantees about the array's order[^1].

For example, if a field were to have `political` in front of `country`, we would keep the `political` type, only to ignore it later on, as we have no mapping for it.

[^1]: https://developers.google.com/maps/documentation/places/web-service/place-types#address-types

Solution
--------
1. Iterate over the types, and get the first one that's part of `FIELDS_MAPPING`
2. Before searching for a `state`, ensure `country` has already been set, otherwise log a warning.
3. Extra: add `postal_town` as a type, which gets used instead of `locality` in some countries like Sweden.

opw-4880651

### Steps to reproduct:

- Create 2 products: Final Product (FP), Kit Product (KP)
- On KP add a Color attribute with 2 values: Blue, Red
- Create a KIT bom for KP wtih 2 operations:
    - OP: paint it Blue, apply on Color: Blue
    - OP: paint it Red, apply on Color: Red
- Create a bom for FP with only one component line:
    - 1 x Red Kit Product
- Create a MO for 1 unit of FP
#### > The operation was not created using the kit bom

### Cause of the issue:

Even if the bom exploded to find the operations to add on the MO: https://github.com/odoo/odoo/blob/2dfcbe53c80d2d8fe5b6d9828eea90a1d214c2e4/addons/mrp/models/mrp_production.py#L579-L599 The `_skip_operation_line`:
https://github.com/odoo/odoo/blob/2dfcbe53c80d2d8fe5b6d9828eea90a1d214c2e4/addons/mrp/models/mrp_routing.py#L164-L174 is checking if the product of the main bom has the attributes of the operation rather than the kit product used as component.

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

Forward-Port-Of: odoo/odoo#228032

Currently, when you use a default fiscal position in the pos, if you switch to no fiscal position, upon order validation the tax amount is counted as change.

Steps to reproduce:
-------------------
* Install l10n_es_pos, switch to es company
* In the config of a shop, use fiscal position, set some as available, one as default
* Open shop session
* Add a product that has taxes
* Switch fiscal position to one that has 0% taxes
* There should not be taxes in the cart at this point
* Go to pay the order (cash or bank)
> Observation: On the receipt the previous tax value is counted as
  change

Why the fix:
------------
The issue happens because of the simplified invoice mechanism present in the ES localization. When you validate an order and that order can apply for simplified invoice, if there is no customer on the order the partner is set with the simplified partner. When setting a partner on the order we update the fiscal position and pricelist.
https://github.com/odoo/odoo/blob/1358f93a4c73de5a28cda72ec78769625c863efd/addons/point_of_sale/static/src/app/models/pos_order.js#L929

The fiscal position is updated with the partner's fiscal position or the default one if none on the partner.
https://github.com/odoo/odoo/blob/1358f93a4c73de5a28cda72ec78769625c863efd/addons/point_of_sale/static/src/app/models/pos_order.js#L986-L995

Instead of the fallback on the default fiscal position in the case it is not set on a partner we fallback on the order current fiscal position. If it is different than the default one is means that it was changed intentionally and there's a high chance we want to keep it, otherwise it will already be the default fp.

opw-5051231

Loyalty points were not being awarded correctly for some orders. The system granted points even when the minimum required quantity of items was not reached. In some cases, it also added negative loyalty points, which led to an excessive deduction for the customer —sometimes just for claiming a single free product.

> Setup of the Loyalty Program (Discount & Loyalty):
Program Type : Loyalty Card
Rule : minimum 5 items => 10 Loyalty Points per $
Reward : Free product (Simple Pen) => in exchange of 5 Loyalty Points

Steps to reproduce:
-------------------
* Open the pos Shop
* Select a customer with loyalty points
* Add a Simple Pen
* Click on * Reward > Free Product - Loyalty Program

> Observation:
Customer shouldn't 'win' points here
New Total is mathematically correct but not logic

Why the fix:
------------
We need to verify that the order is eligible to generate reward points based on the configured rules, before adding the won points.

opw-4914774

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

Forward-Port-Of: odoo/odoo#221570

**PROBLEM**
Pricelist rules based on a minimum quantity does not work well with lot tracked product, when the quantity is splitted between multiples lots. For example, if you take 2 product from lot A, and 3 product from lot B, a rule defining the price for a minimum quantity of 5 will not trigger (it should).

**STEP TO REPRODUCE**
1. install pos
2. create a lot tracked product
3. create a pricelist rule for the product, with a price based on min qty
4. from the pos, order the min qty but split it accross multiple lots
5. price will not takethe rule into account

**CAUSE**
Order line of lot tracked products are never merged. The quantity used to compute if a pricelist trigger is the quantity of each line individually.

**FIX**
For lot tracked product, to determine the price of a line, we parse find all corresponding lines and add their quantities together. Then we update all of their prices. To know if we should take into account a line, we verify if they would have been merged, if their product wasn't lot tracked.

**REMARK**
Ideally, their would be a way to merged order line of lot tracked product, while being able to edit the quantity taken from each lot directly from the pos. From now, order line doesn't work well with multiple lots, and it would require unstable change on the db.

opw-4751920