Steps to reproduce:
- Employee > New
- Time Off > Configuration > Accrual Plans > New
- Accrued Gain Time: 'Start of the accrual period'
- New Milestone > 20 days; Yearly; Carry over: None
- Time Off > Management > Allocations > New
- Accrual allocation; Start at the 1st Jan this year
- Asign it to your new employee
- Employees > Your employee > Time Off
- Take 10 days off this year
- Check balance at the beginning of next year

Only 10 days are available when we should get 20 after the carryover date. While the allocation is computed correctly, leaves taken prior to the carryover are still deducted from the available days. This should not happen for days reset on carryover as the allocated days should have already been taken from the previous year's days we no longer have access to.

This happens because sudo drops the context when creating a new environment, meaning we lose the target date which simply defaults back to today, making the accrual computation wrong. Note that this fix only addresses the case where leaves are validated.

opw-4326914

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

Steps to reproduce:

- create two workcenters, one having a shift with a lunch pause (WC A) (i.e. the default 40hours week will do the job), the other having no lunch pause (WC B).
- create a MO with a work order of a sufficient duration to be splitted in two part (before and after lunch) (6h for instance) and add it on the WC A.
- plan the MO
- go to the planning by workcenter view
- move the WO from WC A to WC B (in the same day)
- move it back to WC A (in the same day)
- move the WO a day later (on the same WC)

Problem:
The duration displayed changes from 6h (correct one) to 7h on the first step, which is incorrect.
Moving the MO back to it's original WC will change the time to 5h which is also incorrect, but moving it a day later fixes the issue (6h)

The problem is that computing the date_finished in the write method is incorrect when `workcenter_id` is in vals, as calling `_calculate_date_finished` will return the value computed with the non-modified yet workcenter

opw-4321104


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

**Steps to reproduce:**
- Install Accounting and Point of Sale
- Open a "Point of Sale" session
- Create a POS order and pay it by bank
- Create another POS order and pay it by Customer Account
- Close POS session
- Go to Accounting
- Open Bank journal
- Create a statement line and reconcile it with the POS payment
- Go to "Accounting / Reporting / Audit Reports / General Ledger"
- Check the amount of the POS orders in the following journals:
  * [101300] Account Receivable (PoS)
  * [121000] Account Receivable
  * [400000] Product Sales
- Check "Cash Basis Method" in the options
- Check again the amount of the POS orders in the same journals

**Issue 1:**
The amount for "[121000] Account Receivable" is present but it shouldn't because no payment has been done for it yet.

**Extra steps:**
- Create another statement line and reconcile it with the POS customer account payment
- Check again the amount of the POS orders in the same journals

**Issue 2:**
The amount of the POS orders is double the original amount.

**Issue 3:**
If a partial payment is made for one line, the report has incorrect values.

**Cause:**
To retrieve the cash basis lines, a complex SQL query is executed.

Let's take the following entries:

- Invoice:

| account | debit | credit |
| ----------- | -------- | -------- |
| Account Receivable 1 |  100  |   0 |
| Account Receivable 2 |  200  |   0 |
| Product Sales |   0   |  300 |

- Payments:

 | account | debit | credit |
 | ---------------- | ------------ | ----------- |
 | Bank | 50 |    0 |
 | Account Receivable 1 |   0   |   50 |

 |       account        | debit | credit |
 | ------------ | ---------------- | ----------- |
 | Bank                 |  200  |   0 |
 | Account Receivable 2 |   0   |  200|

A SELECT is executed to compute and get the percentage of the paid amount of each receivable/payable account by move, generating a temporary "table" as followed:

| move_id |             matched_percentage|
| ------------------|---------------------------------|
|    1    | 0.5 (50% paid for Account Receivable 1)|
|    1    | 1.0 (100% paid for Account Receivable 2)|

This table is then joined to account_move_line table on move_id where matched_percentage is applied to the amounts.

Issues 1 and 2 are due to the fact that it was assumed that each account move would only contain 1 receivable/payable account, which is not the case here.
As account_id is not present in the temporary table, it is not possible to identify to which account a line of that table refers to.
As there is only a JOIN ON move_id when joining with account_move_line table, each aml from a move is taken into account even when it shouldn't.
In this example, they are taken into account twice because the 2 entries have the same move_id.

Issue 3 is coming from the fact that the WHOLE amount of "Product Sales" is computed with matched_percentage each time.
For example, these 2 lines are computed from the tempory table for "Product Sales":

* Product Sales = 300 * 0.5 = 150 (for Account Receivable 1)
* Product Sales = 300 * 1.0 = 300 (for Account Receivable 2)

The amount for "Product Sales" sums to 450, which is not correct.
It should be 250.

**Solution for issues 1 and 2:**
Get account_id and join account_move_line table on it.
An exception should be done for "Product Sales" when joining account_move_line table because it is not a receivable/payable account and the temporay table only contains receivable/payable accounts.

**Solution for issue 3:**
Compute a ratio for "Product Sales" for each receivable account.
Its amount is 100 for "Account Receivable 1" and 200 for "Account Receivable 2"
So its ratio should be:

* 100 / 300 = 0.33 (for Account Receivable 1)
* 100 / 300 = 0.66 (for Account Receivable 2)

By applying this ratio, the correct amounts are computed for "Product Sales":

* Product Sales = 300 * 0.5 * 0.33 = 50 (for Account Receivable 1)
* Product Sales = 300 * 1.0 * 0.66 = 200 (for Account Receivable 2)

opw-4224136

Forward-Port-Of: odoo/enterprise#73593

### Steps to reproduce:
	- Create a new project and set it to be billable.
	- Set an analytic account on it
	- On the analytic account, set a plan that is not the default plan
	- Create a sale order for a subscription product with this analytic account and confirm it.
	- Create an invoice and confirm it.
	- Go to the project and click on Status Updates
	- Notice that the revenues show 0 in “Invoiced” even though we have invoiced the product
	- If we change the plan on the analytic account, we will be able to see the invoiced amount on the profitability report

### Current behavior before PR:
When setting analytic account with different analytic plan than the default one the analytic account value will be stored in x_plan{plan_id}_id field when creating the analytic account line record. https://github.com/odoo/odoo/blob/39029710bbce55889c6b951fc423c1254e05ff22/addons/account/models/account_move_line.py#L3092

https://github.com/odoo/odoo/blob/17.0/addons/analytic/models/analytic_plan.py#L106:L122

So when fetching the profitability data for a project we are just checking the account_id field.
https://github.com/odoo/enterprise/blob/17.0/project_sale_subscription/models/project.py#L111:L115

### Desired behavior after PR is merged:
We are now using the same method of _column_name() to know which field should we use in the domain whether it is 'account_id' or 'x_plan{plan_id}_id'

opw-4137931