Current behaviour:
---
When trying to duplicate a resource booking containing a resource, you get a Validation Error for a missing field.

Expected behaviour:
---
Ability to duplicate a resource booking

Steps to reproduce:
---
1. Go to Appointments
2. Select a resource appointments (ie. Tennis Court)
3. Click on new (To make a new resource booking)
4. Set a name, attendee, AND resource (ie. Court 1)
5. Go to list view, and open newly made booking
6. Click on the cog > Duplicate
7. Validation Error

Cause of the issue:
---
Caused by: https://github.com/odoo/enterprise/commit/064e0da976edd7ef501e4fb33d4d579eaab85a3d 
When duplicating a calendar.event, at the field appointment_resource_ids, the relation table appointment_booking_line 
is used on the fields calendar_event_id and appointment_resource_id. 
However, the model appointment_booking_line has another required field capacity_reserved. 
So when inserting into the table:
https://github.com/odoo/odoo/blob/b64a507697381fd7bb205f4a2b2217322d31811a/odoo/fields.py#L4945 
Only the two specified columns/fields are set, but not the third required field capacity_reserved.
Which causes a SQL error "violates not-null constraint"

opw-4187159

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