**Steps to reproduce:**
- Install Accounting

- Create an invoice with an invoice line
- Save the invoice

- Change the unit price => The totals should change
- Change the product => The unit price and the totals should change
- Change the unit price again

**Issue:**
After this point, the totals don't change anymore, even if the unit price is changed several times.
Only saving the form will adapt the totals correctly.

**Cause:**
When changing the unit price the first time, a "price_unit "key is added in the onchange values.
When changing the product, a "product_id" key is added after the price key.
Changing the product triggers an onchange of the price with the price of the new product.
However, when the price is changed again, as the "price_unit" key already exists, it's reused and its position is still before "product_id" key even if it should be computed after.
This order results in the use of the price of the second product instead of the one entered manually when computing the "tax_totals".

**Solution:**
If "product_id" and "price_unit" are the values of the onchange method, the list of values is reordered to make sure that "product_id" is computed first.

opw-5012125




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

Forward-Port-Of: odoo/odoo#239110
Forward-Port-Of: odoo/odoo#232684

Calling Avatax without lines results in an error and blocks flows:

```
Odoo could not fetch the taxes related to MXXX - SOXXX/XXX.
Please check the status of `Sales Order XXX` in the AvaTax portal.
Transactions must have at least one line.
```

There are various cases this can happen:

1/ if `industry_fsm_stock` is installed, empty orders are confirmed [1],
2/ if you put the `end_date` of a subscription before the `next_invoice_date`,
   then none of the lines are considered invoiceable [2] and you get the
   error when viewing the subscription in the portal

This commit filters out orders without lines.

It's also possible to filter this on the level of the models by doing it in `_get_and_set_external_taxes_on_eligible_records()`. However, this means doing it separately for each model, and requires every implementer do it manually.

[1] https://github.com/odoo/enterprise/blob/703e7fd413e93a8287da98286aa93b9699ae3e96/industry_fsm_stock/models/project_task.py#L159
[2] https://github.com/odoo/enterprise/blob/c7bf4367a9bf6757a36a9f34a872a6e35a19a3a5/sale_subscription/models/sale_order_line.py#L475

opw-5214609
opw-5247727
opw-5311132
opw-5385960

Currently, an error is raised when trying to fetch the shipping rate if the partner does not have the required geolocation fields (country, state, and city).

**Steps to Reproduce:**
1. Install and configure the **Envia Shipping** module.
2. Create a partner without an address (only name + phone).
3. Create quotation for that partner with a deliverable product (e.g; Conference Chair).
4. Click "**Add Shipping**", choose _Envia Shipping_ Method, and then click "**Get Rate**".

**Error:**
`TypeError - quote_from_bytes() expected bytes`

**Cause:**
At [1], the system tries to compute Envia shipping rates based on the partner’s country, state, and city. If any of these fields are not set, an error is raised.

**Fix:**
This commit adds a check for the required fields (country, state, and city). If any are missing, `_geolocate_zip` returns False, leading to a proper validation error instead of a traceback. - [2]

[1] - https://github.com/odoo/enterprise/blob/f1a02626a1fbe76add104832e151c647307f3ae7/delivery_envia/models/envia_request.py#L591-L593
[2] - https://github.com/odoo/enterprise/blob/f1a02626a1fbe76add104832e151c647307f3ae7/delivery_envia/models/envia_request.py#L617-L624

sentry-7063870478

Forward-Port-Of: odoo/enterprise#100734

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

Steps
-----
1. Create a loyalty program;
2. Create a reward;
3. Add a Product domain to the reward containing the `not ilike` operator;
4. Load the POS;
5. Try to trigger the Loyalty program;
6. The Reward is not applied when the domain is satisfied

Issue
-----
Loyalty Program rewards containing `not ilike`-based product domains are not applied when they should.

Cause
-----
The `_replace_ilike_with_in` function in loyalty_reward.py converts the `ilike` and `not ilike` operators by first fetching the records that very the domain with the operator used, and then by replacing the domain by `in` or `not in` with the returned records ids. This is problematic as in the case of `not ilike`, it leads to a double negation.

Example
-----
For `ilike`: `['categ_id', 'ilike', 'service']`
-> Search for all categories that contain "service": `_search([('display_name', 'ilike', 'service')])` 
-> Return new domain `['categ_id', 'in', matching_ids]`
Which is correct.

For `not ilike`: `['categ_id', 'not ilike', 'service']`
-> Search for all categories that **do not contain** "service": `_search([('display_name', 'not ilike', 'service')])`
-> Return new domain `['categ_id', 'not in', matching_ids]`
Which is incorrect, as the matching_ids are already the ids that are not like "service". (i.e., *categ_id not in the categories that do not contain "service"* <=> *categ_id in the categories that contain "service"*, opposite of what is expected.)

Solution
--------
1. Perform the initial search with `ilike` for both operators

opw-5182818

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

Forward-Port-Of: odoo/odoo#235656

Bug
===
Facebook deprecated some of the endpoints related to statistics
https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics

We fixed all metric except the audience trend, because we needed a
fix rapidly, and we wasn't sure about unfollow.

And indeed, `page_daily_follows` only count for positive value, unlike
the old `page_fan_adds` / `page_fan_removes`, and there's no equivalent
of `page_fan_removes`...

Example of data for a month:
```
page_follows       4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5
page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0

page_follows       1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0
page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
```

So we now use `page_follows`, so the total value at a given time, and
we look for the newest and oldest value (note that if we could do the
same for `page_post_engagements`, then we could just make 2 APIs calls
for the year stat).

Task-5353390

Forward-Port-Of: odoo/enterprise#101625
Forward-Port-Of: odoo/enterprise#100275

### Steps to reproduce:

- Create a rentable, storable product
- Create and confirm a rental order for 1 unit of this product
- Click on pickup
- Inventory > Reporting > Moves History
#### > Your pickup move appears without any reference

### Cause of the issue:

The issue has been introduced in d0c1e7845feeee1c2e85a21b5d40570d051458d3 which purpose was to remove the `name` field of the `stock.move` model. However, the `_compute_reference` compute method use to rely on this `move.name` to propagate the info that the move was related to a rental order (since there is no picking). Indeed prior to saas-18.4, the compute method was:
https://github.com/odoo/odoo/blob/404cb10283cbc706eae67dd793ced363273f3602/addons/stock/models/stock_move.py#L325-L328 
And the reference to the rental order was set on the move at pickup: https://github.com/odoo/enterprise/blob/1466a0139ee64ecd059738bc414f6e7e5a9f4354/sale_stock_renting/models/sale_order_line.py#L303-L313 https://github.com/odoo/enterprise/blob/1466a0139ee64ecd059738bc414f6e7e5a9f4354/sale_stock_renting/models/sale_order_line.py#L248-L257

### Fix:

Since the reference field is a computed and stored fields and since some of its dependencies are set at creation the rental move we can not set the `reference` directly in the creation of the record as we used to do for its name since the compute method will then override and erase or reference.

opw-5385004