This is a non-deterministic bug.

Setup:
- install mrp, enable workorders and serial numbers
- create a storable product A with serial tracking
- create a BOM with 1 operation for product A

Steps:
- create a MO for 2 units of product A -> the duration expected on the WO should be 120 minutes.
- confirm then plan the MO
- produce all -> you'll see a wizard for batch production (2nd wizard)
- generate serials then produce or prepare MO (doesn't matter which)

Issue:
Sometimes the duration of the initial workorder is correctly computed -> 60 minutes, sometimes it is not (left as is). This is a mix of 2 'bugs':

First, we have the `self.env['mrp.production'].browse` via a set(). Because it's a set, the productions received are not always in order, so the loop just after may process the last MO first. This triggers the 2nd 'bug'.

Second, the first MO (that was planned) won't trigger `_compute_duration_expected` at https://github.com/odoo/odoo/blob/014ed907a2fab280e9fa6dd93b23a6a852700796/addons/mrp/wizard/mrp_batch_produce.py#L116 when changing `qty_producing` because of `is_planned`: https://github.com/odoo/odoo/blob/014ed907a2fab280e9fa6dd93b23a6a852700796/addons/mrp/models/mrp_production.py#L730-L731 instead, it will go through the compute later because the second MO (created in the split, but not planned) will trigger the compute for both ids via `recompute` because the original MO id was still in the pending transactions:
https://github.com/odoo/odoo/blob/014ed907a2fab280e9fa6dd93b23a6a852700796/odoo/fields.py#L1413 However, the first workorder will already have its qty_producing set to 1 so won't pass in `_get_duration_expected`.

Fix:
Use `OrderedSet` instead of set along with `reversed()` so that the loop will process the last MO first.
This way the pending compute for the original MO will correctly compute the duration 
because it's WO's qty_producing will still be zero.

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

### 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