When creating a new allocation,
selecting "Accrual" with an accrual plan, and then re-selecting "Regular," the accrual plan is registered in the backend,
Flush accrual_plan_id when changing the allocation type.

### **Steps to reproduce:**

1. Create a test database (version 17 or later).
2. Install the `hr_holidays` module.
3. In the Time Off module, navigate to Allocations.
4. Create a new allocation.
5. Select "Accrual Allocation" and assign an accrual plan.
6. Change the allocation type back to "Regular Allocation" and save.
7. Verify the accrual plan is registered in the backend.

**Note:** The accrual_plan_id field is displayed for visibility.

**Before Fix:**
<img width="1897" height="610" alt="before_allocation" src="https://github.com/user-attachments/assets/357c6c1d-3d57-4d2e-bf23-1cf260897aa1" />
<img width="1894" height="477" alt="before" src="https://github.com/user-attachments/assets/af193cd9-2e61-4fa9-8488-927e899ca574" />

```python3
test_17=# select id,private_name,allocation_type,accrual_plan_id from hr_leave_allocation where id = 18;
 id |   private_name    | allocation_type | accrual_plan_id 
----+-------------------+-----------------+-----------------
 18 | Before allocation | regular         |               1
(1 row)
```

**After Fix:**
<img width="1898" height="555" alt="after_allocation" src="https://github.com/user-attachments/assets/60702c72-2e16-4a5f-9b48-213f3c845437" />
<img width="1900" height="535" alt="after" src="https://github.com/user-attachments/assets/15cb27fa-f54b-4e98-94c6-77ae92934c9f" />


```python3
test_17=# select id,private_name,allocation_type,accrual_plan_id from hr_leave_allocation where id = 19;
 id |   private_name   | allocation_type | accrual_plan_id 
----+------------------+-----------------+-----------------
 19 | after allocation | regular         |                
(1 row)
```

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#235568
Forward-Port-Of: odoo/odoo#231253

While investigating a few support tickets related to how the l10n_cl override the fetch mail methods, we noticed a more general issue:

As of now, the payload parsing business logic of Odoo can't handle emails encoding parts with `charset=cp-850`.

This is due to the fact that `cp-850` is not a accepted/standard encoding alias for cp850 charsets in python's `encoding` library.

Whether or not a mail stack should generate mail using `charset=cp-850` or not, we this fix aims at pro-actively declaring `cp-850` as a valid alias for cp850, so that implicitly the email CPython library can correctly decode the payloads in emails.

### Before this bug:

Sending a mail using `charset=cp-850` would generate a traceback.

Example:
```
From: Sender Name <sender@example.com>
To: Recipient Name <odooalias@example.com>
Subject: Test Email with CP-850 Encoding
Date: Thu, 13 Nov 2025 12:00:00 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------=_4987654321-00000000"

This is a multi-part message in MIME format.
------------=_4987654321-00000000
Content-Type: text/plain; charset=cp-850
Content-Transfer-Encoding: quoted-printable

Hallo, dit is een test met een =82 speciale letter.
=
------------=_4987654321-00000000--
```

Would generate:
```
  File "/home/odoo/src/odoo/addons/mail/models/mail_thread.py", line 1398, in message_process
    msg_dict = self.message_parse(message, save_original=save_original)
  File "/home/odoo/src/odoo/addons/mail/models/mail_thread.py", line 1792, in message_parse
    msg_dict.update(self._message_parse_extract_payload(message, msg_dict, save_original=save_original))
  File "/home/odoo/src/odoo/addons/mail/models/mail_thread.py", line 1592, in _message_parse_extract_payload
    content = part.get_content()
  File "/home/odoo/miniconda3/lib/python3.10/email/message.py", line 1096, in get_content
    return content_manager.get_content(self, *args, **kw)
  File "/home/odoo/miniconda3/lib/python3.10/email/contentmanager.py", line 22, in get_content
    return self.get_handlers[maintype](msg, *args, **kw)
  File "/home/odoo/miniconda3/lib/python3.10/email/contentmanager.py", line 67, in get_text_content
    return content.decode(charset, errors=errors)
LookupError: unknown encoding: cp-850
```

### After fix:
`content = part.get_content()` correctly handles the `cp-850` alias

OPW-5171501
OPW-5247486


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

Forward-Port-Of: odoo/odoo#235529

Before this commit:
-------------------------
When printing the delivery slip of a Purchase Order containing products with
different packaging units of measure (UoM), all units of the same product were
aggregated into a single line, regardless of their packaging type.

Steps to reproduce:
-------------------------
1. Install the 'purchase_stock' module.
2. Create Purchase Order.
3. Add 3 move lines for the same product, each with a different packaging UOM:
      - Product 1 - Pack of 2
      - Product 1 - Pack of 4
      - Product 1 - Pack of 6
4. Confirm the PO and click Receive.
5. Validate the receipt.
6. Go to Actions → Print → Delivery Slip.

Cause of the issue
-------------------------
The aggregation logic in _get_aggregated_properties grouped move lines only by
product, ignoring differences in packaging UoM. As a result, product lines with
different packaging types were incorrectly merged into a single line.

After this commit:
-----------------------
- Delivery slips now correctly separate product lines by packaging UoM and move
  lines for the same product but with different packaging are displayed
  individually.
- This provides a clearer and more accurate delivery report.

Task Id: 4879373

Forward-Port-Of: odoo/odoo#227211

Currently, an error occurs when the user clicks the `Create and Enrich Partner` button.

**Error:**
    `ProgrammingError: can't adapt type 'res.partner'`

This error occurs when the user clicks the `Create and Enrich Partner` button. Then it tries to find or 
create the company using IAP. From here [1], it returns the record as company, and here [2], it writes 
this record into the partner as the parent_id. However, since the parent_id is a record instead of an ID, 
when the system tries to browse the partner by this record [3], the error is raised.

This commit ensures that when writing the parent_id of the partner, the actual ID is used instead 
of the record.

[1]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/mail_plugin/controllers/mail_plugin.py#L386

[2]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/mail_plugin/controllers/mail_plugin.py#L52-L53

[3]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/account/models/partner.py#L801

sentry-6831922000

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

Forward-Port-Of: odoo/odoo#235198