**Problem:**
When we do a downpayment on an invoice then pay the rest and do a credit note, the credit note does not reverse the cogs

**Steps to reproduce:**
- create a storable product invoiced on ordered quantity
- set the category of the product as avco and "inventory valuation"
of the category as automated
- set an onhand quantity and a positive cost
- create a SO for 1 quantity of this product and confirm
- click on create invoice, select downpayment percentage and 25%
- click on create draft and confirm it
- click on create invoice, select regular, create draft
- confirm and select credit note
- write something in the reason field and click on reserve
- confirm it

**Current behavior:**
if you open the "Journal Items" page of the credit note you'll see that there is no line revresing the cogs (there would be if we didn't do a downpayment but invoiced all at once)

**Expected behavior:**
There should be:
- A line crediting "600000 Expenses" (or the account that was debited for the cogs on the original invoice) with the amount being the cost of your product.
- A line debiting "110300 stock interim (delivered)"(or the account that was credited for the cogs on the original invoice) with the amount being the cost of your product.

**Cause of the issue:**
Since this commit https://github.com/odoo/odoo/pull/163251/commits/d7b0510908d341c205461ca18b1730c93b88e445 (slightly modfified for efficieny reasons by this commit https://github.com/odoo/odoo/commit/4f9c52c03c65a497937053530e8d6c775d305e35), when _stock_account_prepare_anglo_saxon_out_lines_vals is called on the account move (the credit note) it calls _get_anglo_saxon_price_ctx.
https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/stock_account/models/account_move.py#L114 One of the invoice lines of the account move is linked via sale_line_ids attribute to a sale order line that is a downpayment. As a consequence, inside _get_anglo_saxon_price_ctx, move_is_downpayment will be populated with this line. https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_stock/models/account_move.py#L136-L139 Then _stock_account_prepare_anglo_saxon_out_lines_vals calls _stock_account_get_anglo_saxon_price_unit.
https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/stock_account/models/account_move.py#L131

Inside this method, because move_is_downpayment is populated, is_line_reversing will stay false
https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_stock/models/account_move.py#L163-L164

As a consequence,
- qty_to_invoice will become - qty_to_invoice
- account_move will be populated
- therefore posted_cogs will be populated https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_stock/models/account_move.py#L166-L174 So _compute average price will be called with a qty_invoiced of 1 instead of 0 and a qty_to_invoice of -1 instead of 1. So it will return 0 instead of the cost of the product because "missing" will be negative.
https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/stock_account/models/product.py#L915

**fix**
The use case of this commit https://github.com/odoo/odoo/pull/163251/commits/d7b0510908d341c205461ca18b1730c93b88e445 is this one :
- SO for qty of 10 (product invoiced on delivered qty).
- 100% downpayment.
- deliver 6.
- invoice. 
In that case the invoice is actually a credit note but it still has to include the cogs (not reversed), so move_is_downpayment needs to be populated

However in our use case the cogs has to be reversed (so move_is_downpayment has to be None). One difference between those two use case is that in our use case the account move has a reversed_entry_id.

opw-5041783

Forward-Port-Of: odoo/odoo#229774
Forward-Port-Of: odoo/odoo#226809

**Steps to reproduce:**
- create a storable product with fifo category
- update the cost to 200
- click on the on hand smart button and add a quant of 1 quantity
- update the cost to 300
- click on the on hand smart button and update the quantity to 2
- the value should be 500, which makes a 250 value per product
- open Inventory/valuation and search your product
- group by product, select your product and click on "+" icon to open 
the revaluation widget
- add 200 (so +100 per unit)
- go back to the product form

**Current behavior:**
the cost is now at 400

**Expected behavior:**
the cost should be at 350 (250 + 100)
If we change the standard_price we should change it in accordance 
with the valuation

**Cause of the issue:**
In action_validate_revaluation, during the update of the standard_price, 
the current standard_price (set by the user and disconnected from the
valuation) is used in the computation.
https://github.com/odoo/odoo/blob/5118f7cb80744f901d7028dc75c29aba9591b83b/addons/stock_account/wizard/stock_valuation_layer_revaluation.py#L127

opw-5028848

Forward-Port-Of: odoo/odoo#229977
Forward-Port-Of: odoo/odoo#228457

Currently, leads are not automatically assigned via rule-based assignment 
when duplicating an existing lead, even if the duplicated lead matches 
the assignment criteria.

**Pre-requisites:**
1) Set up rule-based lead assignment in the CRM settings. 
2) Configure the sales team's assignment domain:
   `[("user_id", "=", False)]`
3) Configure the sales team members' domain:
   `[("probability", ">=", 10)]`

**Steps to Reproduce:**

1) Create a lead that matches the above assignment rules. 
2) Remove the salesperson (user_id) and sales team from the lead. 
3) Duplicate the lead.
4) Update the probability to a valid value (e.g., ≥ 10). 
5) Manually trigger the `Rule-Based Assignment`.

**Issue:**
The original lead gets assigned, but the duplicated one does not.

**Cause:**
When duplicating, the system sets date_open to the current date by default, 
even if the duplicated and original leads have no assigned users.

https://github.com/odoo/odoo/blob/3e7d85cf25386615dea559d954cebb1424b62f35/addons/crm/models/crm_lead.py#L929-L931

However, `rule-based assignment` only considers leads where `date_open` is False https://github.com/odoo/odoo/blob/3e7d85cf25386615dea559d954cebb1424b62f35/addons/crm/models/crm_team_member.py#L136-L141

**Solution:**
Set `date_open` to False during duplication if the original lead has no `user_id`. 
This ensures the new lead remains eligible for assignment.

opw-5003529

Forward-Port-Of: odoo/odoo#229512
Forward-Port-Of: odoo/odoo#227387

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

Forward-Port-Of: odoo/odoo#230134
Forward-Port-Of: odoo/odoo#217171

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

Steps
-----
1. Have a database with GeoIP enabled;
2. have a promotion program that gives a discount on a specific product;
3. use a VPN to browse /shop from California before 7:00 UTC;
4. add the product to your cart;
5. go to checkout;
6. pay for the order.

Issue
-----
Order cannot be confirmed due to incomplete payment.

Cause
-----
The `_frontend_pre_dispatch` method of `website` adds a timezone value to the context based on the request's `geoip`. This context value then gets used to find applicable loyalty programs via `Date.context_today`, and applies them to the order.

Then after payment was initiated, the order gets validated again using server time (UTC), which now considers the applied program expired, and removes the reward before confirming the order.

Consequently, with the discount removed, the paid amount no longer matches the order total, thus the order remains unconfirmed.

Solution
--------
If the order has a confirmed transaction, use its `create_date` to verify loyalty expiration dates.

For time zone, instead of `Date.context_today`, using whatever `tz` value is in the context, use a helper function which retrieves the current day in the company's timezone.

For website orders, if defined, use the eCommerce salesperson's time zone instead.

Also fix an issue where expired coupon lines weren't getting removed from the order.

opw-4765873
opw-4781346
opw-4939268

Forward-Port-Of: odoo/odoo#229749
Forward-Port-Of: odoo/odoo#222428

Currently, an error occurs when computing taxes for an invoice.

**Error:**
    `KeyError: 'manual_tax_amounts'`

**Cause:**
When a user clicks the `Compute Tax` button, the system calculates the tax for that invoice, including the `manual_tax_amount` [1]. However, if no tax is found for a given customer ZIP code, the `tax_values_list` becomes empty [2]. As a result, `manual_tax_amounts` in the base line also becomes empty.

Later, when the system tries to fetch the `manual_tax_amounts` key from extra_tax_data, it raises a KeyError [2], because the key no longer exists.

Additionally, the condition in [3] indicates that there is no guarantee that the `manual_tax_amounts` key will always be present in the base_line.

**FIX:**
This commit ensures that if the manual_tax_amounts key does not exist, an empty dictionary {} is used instead. This prevents the KeyError from occurring during tax computation.

[1]- https://github.com/odoo/enterprise/blob/b17b6b4e5ca3085d831fc763457496b5c5b639c5/account_external_tax/models/account_external_tax_mixin.py#L155-L163

[2]- https://github.com/odoo/enterprise/blob/a51aee8f6e8bce2aa699d3199d6723495464a762/account_external_tax/models/account_external_tax_mixin.py#L88

[3]- https://github.com/odoo/odoo/blob/241c170dbece8c1652db9ca1aa935b2106ede532/addons/account/models/account_tax.py#L1330

sentry-6919182805