### Steps to reproduce the issue:

1. Create a Product and add a Vendor Price under the Purchase tab
2. Create a Request for Quotation from the Vendor with the Product, change the Unit Price
3. Confirm Order
4. Create a Vendor Bill from the Vendor with one Invoice Line, click on "Purchase Matching"
5. Select the Invoice Line and click on "Add to PO"
6. Select the PO previously created and Add Down Payment
7. On the PO, the Unit Price on the Product Line has reverted to the Vendor Price

### Explanation:

During `_create_downpayments`, `purchase.order.line` created from `account.move.line` are added to `purchase.order.order_line` through a concatenation operator (here a `+`, but `|` would have the same effect).
With this operation, `purchase.order.order_line` is flagged as a modified value and needs to be totally recomputed. In the triggered recomputation methods is `_compute_price_unit_and_date_planned_and_name`, which affects multiple values including `unit_price` and uses `product_product.seller_ids`. https://github.com/odoo/odoo/blob/d0e7be7832672d476f1b289af52d3a425990d719/addons/purchase/models/purchase_order_line.py#L313-L318 https://github.com/odoo/odoo/blob/d0e7be7832672d476f1b289af52d3a425990d719/addons/purchase/models/purchase_order_line.py#L351-L358

### Fix reasoning:

With `Command.link`, only the added lines are flagged as new values and `purchase.order.order_line` is not recomputed.

opw-4275163

Steps to Reproduce:

Create an accrual allocation:
  - Carryover date on allocation start date.
  - Has 1 level:
    * Start 0 days after allocation start date.
    * Accrues 1 day monthly on 1st day of the month.
    * Carryover policy all accrued time carried over.
    * Carryover validity 1 month.
    * Leave other options as is.
  - Leave other options as is.

Create an allocation:
  - Allocation type: accrual allocation.
  - Accrual plan: use the one defined above.
  - The following dates are in mm/dd/YYYY
  - Set allocation start date 08/01/2023.
    Number of days becomes 2 days (as expected).
  - Set allocation start date 09/01/2023.
    Number of day becomes 12 days (as expected).
  - Set allocation start date 08/01/2023.
    Number of days becomes 13 days (wrong).

The issue is that the expiration date of carried over days and the number of expiring days aren't reset when the start date of the allocation changes.

The fix is to reset these values when the start date of the allocation changes.

task-4208024

When the user edits the view and adds context with invalid syntax,
a traceback will appear.

Steps to reproduce the error:

- Go to Settings > Technical > Views > Open any view
- Add context = ``"[]"`` or context = ``"{a}"`` like this in the view
- Save

Traceback:
```
UnboundLocalError: cannot access local variable 'err' where it is not associated with a value
  File "odoo/http.py", line 2365, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1892, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1955, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 137, in retrying
    result = func()
  File "odoo/http.py", line 1922, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2169, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 329, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 728, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "home/odoo/src/enterprise/18.0/industry_fsm_report/controllers/main.py", line 10, in edit_view
    action = super().edit_view(view_id, studio_view_arch, operations, model, context)
  File "odoo/http.py", line 728, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "home/odoo/src/enterprise/18.0/worksheet/controllers/main.py", line 10, in edit_view
    action = super().edit_view(view_id, studio_view_arch, operations, model, context)
  File "odoo/http.py", line 728, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "home/odoo/src/enterprise/18.0/web_studio/controllers/main.py", line 695, in edit_view
    self._set_studio_view(view, new_arch)
  File "home/odoo/src/enterprise/18.0/web_studio/controllers/main.py", line 456, in _set_studio_view
    studio_view.arch_db = arch
  File "odoo/fields.py", line 1402, in __set__
    records.write({self.name: write_value})
  File "home/odoo/src/enterprise/18.0/web_studio/models/studio_mixin.py", line 33, in write
    res = super(StudioMixin, self).write(vals)
  File "odoo/addons/base/models/ir_ui_view.py", line 535, in write
    res = super(View, self).write(self._compute_defaults(vals))
  File "odoo/models.py", line 4750, in write
    real_recs._validate_fields(vals, inverse_fields)
  File "odoo/models.py", line 1599, in _validate_fields
    check(self)
  File "odoo/addons/base/models/ir_ui_view.py", line 413, in _check_xml
    elif err.__context__:
```

https://github.com/odoo/odoo/blob/69b404c7109ff689381f56520aad758424ec01aa/odoo/addons/base/models/ir_ui_view.py#L413-L418
Here, the ``err`` variable is referenced before the assignment,
So, it will lead to the above traceback.

sentry-5993638522

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

On a stock move, when using a lot from a sub-location, the created
SML will still start from SM's source location instead of lot's location

To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create a tracked-by-sn product P
3. Update its qty:
   - SN01 at WH/Stock
   - SN02 at WH/Stock/Shelf 1
4. Confirm a delivery with 1 x P
5. Enable the column "Serial Number"
   - SN01 should be present
6. Remove SN01, set SN02
7. Validate the transfer
8. Open the detailed operations

Result: SN02 has been taken from WH/Stock, but the user probably
wanted to use the existing one, in WH/Stock/Shelf 1.

An onchange already exists to make sure that the user is not using a
lot that already exists somewhere else. Before Odoo 17.2, we were
considering the sub locations as not expected:
https://github.com/odoo/odoo/blob/d5a7a3d02e3e2b4e47977abc8b9fc0d5d6135937/addons/stock/models/stock_move.py#L1167
But since Odoo 17.2 (via [1]), we now also accept the sub locations:
https://github.com/odoo/odoo/blob/60b0bafc8abd1893c9cdd9913617c234692369cf/addons/stock/models/stock_move.py#L1242

This is a bit confusing because we don't display any warning anymore,
but we don't select the correct source location neither. The commit
should help the user and avoid that confusion

[1] https://github.com/odoo/odoo/commit/99b39b72c7e65e85af6f06dcb6b02867623f3f69

OPW-4231749

Forward-Port-Of: odoo/odoo#185796

Currently, a traceback occurs when the user deletes a module which is having a gamification goal record.

To reproduce this issue:

1) Install `sale` and `gamification`
2) Create a new `gamification challenge` record
3) Create a new `goal` in the gamification challenge 
4) Make sure the goal has the definition as `Automatic: sum on a field` 
5) Select the model as `account`
6) Uninstall the invoicing module and start the `challenge` of that gamification.

Error:- 
```
KeyError: False
```

The value of the model_id became `False` when the user deletes a module used in goal.

This leads to a traceback as model_id is used for the reference of obj 

https://github.com/odoo/odoo/blob/d9603e93d2ab5e0b9fd1948dfd3e3bee20ede599/addons/gamification/models/gamification_goal.py#L164-L165

We can resolve this issue by adding `ondelete='cascade'` in the field
definition. Where the record will be deleted if the corresponding model is 
uninstalled.  

sentry-4089991441

Forward-Port-Of: odoo/odoo#180307

Currently it can happen that slightly changing the amount in (document)
currency (field `amount_currency`) i.e. on a tax line can lead to an
unbalanced move. (See example and "Reproduce" below.)

The issue is the syncing (function `_sync_invoice`) between
- amount in currency (document currency; field `amount_currency`) and
- balance (company currency; field `balance`).

There we update the amount in currency in case the balance is changed
and the amount in currency is not changed.
But this is problematic in case we want (in the same write) set
a different amount in currency but explicitly set the same balance
(and not just not write anything to the `balance` field).
Since we write the same balance it is not detected as a
change and we update the balance based on the amount in currency.
But this should not happen; the balance should be "protected"
from being updated (since it is the value we explicitly want).

This can i.e. cause the balance of the receivable line to receive the wrong value
I.e. consider the following case; with currency rate = 2 (also see "Reproduce" below)

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -30.00 €, balance =  -15.00
- Receivable: amount in currency = -1410.03 €, balance =  705.02

And we modify tax line 2: amount in currency = -29.99 €.
Then first we set the correct values because we basically compute the
receivable line by summing the other lines:

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -29.99 €, balance =  -15.00
- Receivable: amount in currency = -1410.02 €, balance =  705.02

So we have set the balance to the same as before but changed the
amount in currency. So then we recompute the balance on the receivable
line from the amount in currency due to the syncing (`_sync_invoice`)

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -29.99 €, balance =  -15.00
- Receivable: amount in currency = -1410.02 €, balance =  705.01

But now the move is not balanced (the sum of the balances should be 0)
  -500.00 + -100.00 + -90.02 + -15.00 = -705.02 (and not -705.01)

After this commit we "protect" the balance and amount in currency from
being updated by `_sync_invoice` in case the surrounding `write`
sets the balance (`balance`) or amount in currency (`amount_currency`)
respectively.

Reproduce: (c.f. example above)
  1. Select company "My Company (San Francisco)"
  2. Ensure EUR currency is activated and has value 2 unit per USD
     (at the time of the invoice that will be created further below)
  3. Copy the 15% tax
  4. Create a new invoice in EUR with 2 lines
     (1) qty = 1, unit price = 1000, taxes = 15%
     (2) qty = 1, unit price = 200, taxes = 15%, 15% (Copy)
  5. There should be 2 tax lines in the "Journal Items" tab
     (1) amount in currency = -180.00 €, credit = 90.00 USD
     (2) amount in currency = -30.00 €, credit = 90.00 USD
  6. Modify tax line (1); set amount in currency to -180.03 €
     and save.
     The credit will be updated to 90.02 USD.
  7. Modify tax line (2); set amount in currency to -29.99 €
     and try to save
  8. An "Invalid Operation" error is raised:
     The move (Draft Invoice ) is not balanced.
     The total of debits equals $ 705.01 and the total of credits equals $ 705.02.

Forward-Port-Of: odoo/odoo#185757
Forward-Port-Of: odoo/odoo#171705

**Note** 
Compared to previous versions the `amount_currency` is not updated
anymore in `_sync_invoice` (only the `balance`).