**Steps to reproduce:**
- Have two products, A (150$) and B (50$)
- Make a loyalty program for A, 10$ reduction on the order when bought
- Make another one for B, 100% reduction on B when bought. Make it a coupon with a code
- Open the PoS, click on A, then B, then enter the coupon code

**Problem:**
After those steps, the reward for buying be should be 100% of B, meaning 50$, but it is only 40$.

**Why the fix:**
This happens because the reward line for A was taken into account when computing B's reward value.
Meaning that the original 50$ was taking the -10$
into account, thus making it 40$.

We now check if the current product is in all_discount_product_ids, and do not go through the next step if it is. This attribute represents all the products that the current reward applies to. 
So this means that if the current product is in the products the reward applies to, we do not add it to the lines to discount.
With this condition, we prevent a reward from discounting a product it already applies to again.

With this fix, we exclude the reward lines that target one of the products the reward targets. This ensures that any line directly associated with a discounted product are not considered.

opw-4970441

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

Versions
--------
- 17.0+

Steps
-----
1. Have a sale order with deliverable products & no payment terms;
2. confirm order & validate delivery;
3. create an invoice;
4. modify the delivery date;
5. save changes;
6. change product quantity of a line & confirm invoice.

Issue
-----
The delivery date got reset.

Cause
-----
The `_compute_show_delivery_date` method gets called, which triggers the recomputation of the `_compute_delivery_date` due it the latter having `line_ids.sale_line_ids.order_id` as its `depends`.

Due to the way how `depends` works, if any of the fields in the record chain gets modified, the compute gets triggered. In this case, because we modified a `line_ids` record by changing the quantity, it will therefore recompute the delivery date, overwriting the custom value.

Solution
--------
As we only want the delivery date to be recomputed when the `effective_date` on the order changes, we should add it to the `depends` to trigger the compute in that scenario.

In other scenarios, e.g. modifying the move or one of its lines, we don't want to trigger a recompute, which we can achieve by always including `delivery_date` via `_get_protected_vals` on create/write.

opw-4996654

We need to know for each partner if it is a customer or a supplier, even
more for Romania[^1] where it is enfored and validated.
> 1. If the element SD.P.22 CustomerID is reported with value ”0”
  (zero), then the element SD.P.23 SupplierID must be different from ”0”
  (zero), meaning the identity of the partner from which the purchase was
  made (conventionally considered ”supplier”) is reported. Else if SD.P.22
  CustomerID AND SD.P.23 SupplierID are concomitantly equal to ”0” (zero),
  then is return a semantic validation error. (CustomerID and SupplierID
  can not be concomitantly 0 (zero))

In order to fix this, we don't use the Partner Ledger anymore to query
the balance per partner because it is removing the partners with 0
balance automatically.
To keep it simple, we query manually and locally, allowing to reduce the
number of queries from 3 to 1 for that part.

For the performance, the `|=` operator done in a loop has also been
removed, keeping the time complexity in `O(n)` instead of `O(n²)`.

opw-5122910

[^1]: https://www.anaf.ro/anaf/internet/ANAF/despre_anaf/strategii_anaf/proiecte_digitalizare/saf_t