**Problem:**
When making a purchase in the self order and put a table_stand_number, which is the table number you have to fill at the end of the order, it is displayed in the *pos_preparation_display*. But when loading this said order in the PoS, changing the order (like adding a note) and ordering it again, the table number is replaced by *IN*.

**Steps to reproduce:**
- Make a purchase in the kiosk
- Put a table number at the end of the order
- Go to the pos_preparation_display, it is displayed
- Go to the PoS session of the Kiosk and load the order
- Change the order by adding a note to it and order it again
- The table number is replaced by IN in the pos_preparation_display

**Why the fix:**
The field *table_stand_number* was not given to PoS in any case, which means that when reloading the order and saving it again, it saved it without the *table_stand_number*, as it was never loaded.
As it was never loaded, it went back to the fallback, which is writting *IN* if the table_stand_number was undefined. It is now loaded if the pos_self_order is installed, so that we can keep on showing the table number as it should be.

opw-4943404

Forward-Port-Of: odoo/odoo#220869

### Steps to reproduce:

- Install stock_delivery
- Create and confirm a receipt for 2 products:
    - 1 x P1
    - 1 x P2
- Modify the scheduled date of P1 to the day before
- Save the picking

#### Expected behavior:

The scheduled date of the picking is updated but not the one of the other move.

#### Current behavior:

The the move scheduled date is also updated.

### Cause of the issue:

Modifying the scheduled date of the move will trigger a call of the onchange on the picking because the `stock_move_ids` field has changed via a `Command.update` on its scheduled date:
https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/web/static/src/model/relational_model/record.js#L1214-L1219 However, this onchange will trigger a call of the
`_compute_scheduled_date` on the new records to determine if its value has changed and set the scheduled date of the picking to one day before: https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/stock/models/stock_picking.py#L846-L851 This is problematic because since each of these changes happen before the save of the real record, the inverse method of the scheduled date will be called and set the scheduled date of the other moves at save: https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/stock/models/stock_picking.py#L897-L901

### Note:

This is not reproducible without `stock_delivery`, changing the scheduled of a `move_ids_without_package` will only trigger the onchange of the `stock.picking` model (and hence the compute on the new records) in case the `move_ids_without_package` is flagged as `onchange=1` by the `get_view`:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/odoo/addons/base/models/ir_ui_view.py#L1218-L1225 But, since `move_ids_without_package` do not have `_onchange_methods` they will only be flagged as such if they are in the dependencies of a field present in the view:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/odoo/models.py#L7363-L7370 This is the case as soon as `stock_delivery` is installed because of the `is_return_picking` field:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/addons/stock_delivery/models/stock_picking.py#L37-L38

opw-5017423

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

Forward-Port-Of: odoo/odoo#224986

## Issue:
In a multi-company setup with Inter-Company Transactions set to Sales Orders and Purchase Orders, after creating two Sales Orders from one company to the other,
then generate a Consolidated Invoice for both SO, and import it as Vendor Bill in the client Company, the bill isn't linked to the matching Purchase Order

## Cause:
The `invoice_origin` is used to get the references, but it doesn't split causing the purchase's name to search in `_match_purchase_orders()` to be ["P00001, P00002"] instead of ["P00001", "P00002"]
https://github.com/odoo/odoo/blob/2718aaa7397e38be0fcd64fe6b5ef5c0be66cfe2/addons/purchase/models/account_invoice.py#L373-L374

## Steps to reproduce:
- Enable Inter-Company Transactions for Sales Orders and Purchase Orders in two Companies
- Create and Confirm two Sales Orders from one company to the other one
- Create a Consolidated Bill for both S0
- Send the Invoice (Download)
- Switch to the second Company
- In Purchase, Confirm both RFQ
- In Accounting > Vendor > Bills, Upload the downloaded bill
- The Smart Button isn't linked to the PO

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4690707)
opw-4690707

Forward-Port-Of: odoo/odoo#223398

### Description of the issue/feature this PR addresses:

Behavior in <= v17.4:

The onclick method for the delete button in the one2many list calls the `onDeleteRecord` method. This is inherited by the model-specific list renderer components to insert the deletion confirmation dialog before calling super which sets the clicked data attribute to be true. In this case, we display the dialog before setting the button as clicked.

Behavior in v18:

The onclick method for the delete button in the one2many list calls the `onRemoveCellClicked`. This method sets the clicked as True and then calls the `onDeleteRecord` method that is inherited by the various model-specific list renderer components to insert the Confirmation Dialog. In these cases, the dialog is called after we set the 'clicked' data-attribute on the delete button to be True. Hence now we are unable to click on the same button again due to it being in the clicked state.

### Current behavior before PR:

[Deletion Dialog does not reopen](https://github.com/user-attachments/assets/29b6c2c7-553b-4745-a20b-26a470952a01)

1. Try to delete a record of Project Subtask or Product Attribute Value
2. This would open the Deletion Confirmation Dialog box
3. Click on cancel 
4. Try to delete the same record again 

Result: Nothing happens and the confirmation dialog does not show up again for the second time


### Desired behavior after PR is merged:

If user attempts to delete any record that opens the confirmation dialog and then cancels it, the user is able to delete it as the confirmation dialog box is no longer disabled after spawning once.


opw-4731375

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