Steps to reproduce:
-------------------------
1. Install the Accounting module.
2. Create and confirm a Vendor Bill.
3. Click on Pay and create a payment for the bill.
4. Open the created payment using the smart button.
5. Delete the payment or click on Reset to Draft.


Observation:
-------------------------
1. On deleting the payment:
The Vendor Bill still shows the "In Payment" status even after the payment is
deleted.
2. On resetting the payment to draft:
The Vendor Bill also remains in the "In Payment" status instead of reverting to
"Not Paid".

This behavior is not observed for customer invoices, where the payment state
updates correctly in both cases.


Issue:
-------------------------
1. Delete case:
In the `unlink` method,
https://github.com/odoo/odoo/blob/b991f766e28dc71f8627fdfbf2d59589d9707d3a/addons/account/models/account_payment.py#L938-L945
the `linked_invoices` variable only includes invoices that are reconciled
(i.e., their journal items are matched). Since the Vendor Bill is not yet
reconciled, it is excluded from recomputation. Hence, its `payment_state`
remains unchanged.

2. Reset to draft case:
In the `_compute_payment_state` method,
https://github.com/odoo/odoo/blob/b991f766e28dc71f8627fdfbf2d59589d9707d3a/addons/account/models/account_move.py#L1162-L1163
the compute depends on the state of reconciled payments. However, since these
payments are not reconciled, the compute method is not triggered, and the
payment state remains outdated.


Solution:
-------------------------
Added `matched_payment_ids.state` in the depends of the
`_compute_reconciled_payment_ids` method to ensure it recomputes correctly when
payment state changes on setting payment to draft or deleting payment

Ticket [link](https://www.odoo.com/odoo/project.task/5208772)
opw-5208772

Forward-Port-Of: odoo/odoo#234725

Before this commit:
-------------------------
- On the Purchase Dashboard, the 'Not Acknowledged' and 'Late Receipt' counters
  also included purchase orders whose receipts had already been done.
- For Not Acknowledged:
  - Such POs should be implicitly considered acknowledged once their receipts
    are done, but they were still shown at the counter.
  - Additionally, unacknowledged POs that were locked were incorrectly excluded
    from the counter.
- For Late Receipt:
  - POs with received products were incorrectly counted as late, even
    though their receipts were already done.
  - Locked POs with late receipts were also excluded from the counter, which was
    an incorrect behavior.

Steps to reproduce:
-------------------------
1. Install the 'purchase_stock' module.
2. Open Purchase module.
3. On the Purchase Dashboard, click on the 'Not Acknowledged' or 'Late
   Receipt' card.
4. Notice that POs whose receipts are already completed still appear in the
   counters and some locked POs that are unacknowledged or have late receipts
   are missing from the counters

Cause of the issue
-------------------------
- The domains for both Not Acknowledged and Late Receipt counters only relied on
  the purchase order state without checking whether the receipts were done.
- As a result, POs with done receipts were still included in the counters, while
  some locked POs were incorrectly excluded.

After this commit:
-----------------------
- Updated the search domains for both counters to properly exclude POs whose
  receipts are done.
- The action_done method now triggers action_acknowledged, ensuring that any
  unacknowledged POs with completed receipts are automatically marked as
  acknowledged and excluded from the Not Acknowledged counter. Locked POs that
  remain unacknowledged will still correctly appear in the counter.
- Now the POs with received products are no longer shown as late once their
  receipts are completed and Locked POs with late receipts will now correctly
  continue to appear in the counter.
- This ensures that the dashboard accurately reflects only pending
  acknowledgments and genuinely late receipts, helping users track POs in
  the correct state.

Task ID: 4874116

Forward-Port-Of: odoo/odoo#237176
Forward-Port-Of: odoo/odoo#224180

## **Issue Before This Commit:**
When a work order is assigned to an employee (not linked to the current user),
and the current user marks it as done, the time log is wrongly created
under the current user’s employee instead of the assigned one.
This behavior caused confusion for the user as the
wrong person was shown as working on the order.

## **Steps to Reproduce:**
- Create an MO with work orders and confirm it.
- Assign another employee to a work order.
- Mark the work order as done with the current user from the work order line.
- Open the workorder and notice that the time log is created for the current user’s employee.

## **Cause of the Issue:**
The bug was introduced in PR (https://github.com/odoo/enterprise/pull/84790),
where the logic for assigning the main employee was overridden,
ignoring the case of an already assigned employee.

## **With This Commit:**
The time log is now created for the assigned employee,
This resolves the confusion by ensuring
the right person is tracked on the work order.

TaskID: 4983514

Forward-Port-Of: odoo/enterprise#100467
Forward-Port-Of: odoo/enterprise#93378

A field on `account.analytic.line` is created for every plan using the `id` of the plan to make the names unique, like `x_plan{id}_id`. The plan that has the ID of the `analytic.project_plan` parameter does not get a dynamic field, it uses `account_id`. If you change the system parameter for analytic.project_plan, the plan with the corresponding value will now use `account_id,` and the plan that corresponds to the previous default value will have no corresponding field on `account.analytic.line`.

So, when the project plan system parameter changes, the dynamic fields that are created for each analytic plan (apart from the project one) do not get updated.

Steps:

1. Set the `analytic.project_plan` system parameter to a value other than `1`
2. Enable `Analytic Accounting` setting under `Accounting > Analytic`
3. Create a sales order with a service product that creates a project.
4. Confirm sales order
5. Traceback: `ValueError: Invalid field account.analytic.line.x_plan1_id in leaf 'x_plan1_id', 'in', [23])`


We now extend the write method on `ir.config_parameter` so that when the value of the analytic.project_plan is changed the dynamic fields on `account.analytic.line` are properly added and removed. This solution always creates a field for the previous value and deletes a field for the new value so that no plan ever has two fields referencing it.  

Ticket [link](https://www.odoo.com/odoo/project.task/5069381)
opw-5069381

Forward-Port-Of: odoo/odoo#234987
Forward-Port-Of: odoo/odoo#231981