Steps to produce:
---
- Install website_sale module without demo.
- Create a new product and publish it.
- From the incognito, go to shop and add that product to cart.
- While doing checkout > fill the address form.
- Add the all details including the company name and valid VAT.
  (ex. BE0477472701)
- Submit the form.

Issue:
---
- When a public or guest user submits a new address with both a contact name
  and a company name along with a valid VAT number, the contact's name was
  being overwritten with the company name.

Root cause:
---
- The _compute_is_company heuristic in res.partner automatically sets
  is_company=True for partners with valid VAT. In [commit]
  `_create_or_update_address`, the condition `elif partner_sudo.is_company:`
  was designed to rename existing companies, but incorrectly caught newly
  created individuals marked as companies due to VAT, causing their name to be
  overwritten instead of creating a parent company.

Solution:
---
- Replaced the is_company check with explicit conditions: the partner
  has no parent_id, has contact-type child_ids.
- This ensures the rename-company branch only fires for actual company
  heads that the logged-in user belongs to, not for individuals that
  happen to have is_company=True due to a valid VAT.

[commit]: https://github.com/odoo/odoo/commit/8f3a32170c842f5f42edc79bf8620276f0da7be4

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

Forward-Port-Of: odoo/odoo#275044

An issue occurs during the database upgrade
From version 19.2 to 19.3.
During the upgrade, the system attempts to update
the `name` and `rounding` configuration of the Cash Rounding account.

If the Cash Rounding record is linked to
an open POS session, the update fails with
the following constraint error:
```
You are not allowed to change the rounding configuration while a POS session using it is already opened.
```

To avoid this traceback during the upgrade,
set the record's noupdate attribute to True so that it is not modified.

```
  File "/home/odoo/src/odoo/saas-19.3/odoo/tools/convert.py", line 485, in _tag_record
    record = model._load_records([data], self.mode == 'update')
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py", line 4566, in _load_records
    data['record']._load_records_write(data['values'])
  File "/tmp/tmpxr_9kp1h/migrations/base/0.0.0/pre-models-load_write.py", line 46, in _load_records_write
    return super()._load_records_write(values)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py", line 4487, in _load_records_write
    self.write(values)
  File "/home/odoo/src/enterprise/saas-19.3/ai_fields/models/models.py", line 57, in write
    res = super().write(vals)
          ^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/enterprise/saas-19.3/ai/models/models.py", line 339, in write
    return super().write(vals)
           ^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py", line 3860, in write
    real_recs._validate_fields(vals, inverse_fields)
  File "/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py", line 1295, in _validate_fields
    check(records)
  File "/home/odoo/src/odoo/saas-19.3/addons/point_of_sale/models/pos_order.py", line 1575, in _check_session_state
    raise ValidationError(
odoo.exceptions.ValidationError: You are not allowed to change the rounding configuration while a pos session using it is already opened.
```

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#281174

Steps to reproduce:
- create a "Buy 2 Take 1" program whose rule and reward both target a product tag containing several products
- in the PoS, add one of the tagged products to the order
- set its quantity to 3 with the numpad

Issue:
The free product is not given. Clicking the product a third time instead of typing the quantity does give it, and so does a program whose reward is a single product.

Cause:
A reward whose products come from a tag is multi_product, so getClaimableRewards never computes its unclaimed quantity and the auto claim of updateRewards skips it: which product to give out is unknown. The only place claiming such a reward is addLineToCurrentOrder, which resolves it with the product that was just added. Setting a quantity does not go through it, hence the difference.

Fix:
Resolve the reward product the same way when auto claiming: the product of the line being worked on, or, failing that, the only reward product the order contains. The reward then follows the quantity of any of the tagged products, not only of the first one added, and the cashier is still asked when the order does not settle the choice.

opw-6430385

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

Forward-Port-Of: odoo/odoo#284777

The stored rrule of a recurrence embeds a DTSTART line based on the recurrence dtstart (the smallest start among its events). When the first occurrence is moved in Outlook, the Odoo dtstart no longer matches that DTSTART, but the stored rrule is not recomputed at that point (it only depends on the pattern fields).

On a later sync touching the seriesMaster (e.g. after adding an attendee to the moved occurrence), the recurrence values are written again and the rrule is reserialized with a DTSTART based on the moved occurrence. _write_from_microsoft() took this new rrule string as a pattern change and reapplied the recurrence: all occurrences were deleted and recreated as copies of the moved one, spreading its specific data (e.g. the newly added attendee) to the whole series.

Ignore the DTSTART line when comparing the rrule before and after the write: a DTSTART-only difference does not reflect any pattern change in Outlook. An actual pattern change (FREQ, UNTIL, INTERVAL, ...) still reapplies the recurrence as before.

Steps to reproduce:
1. In Outlook, create a recurring event
2. In Odoo, run the calendar sync
3. In Outlook, move the first occurrence of the recurrence (shift its start and stop time by 30 minutes)
4. In Odoo, run the sync
5. In Outlook, add an attendee to that same first occurrence
6. In Odoo, run the sync

All the occurrences are deleted and recreated as copies of the first one, and the attendee ends up on every occurrence instead of one.

opw-5129848

Forward-Port-Of: odoo/odoo#284747
Forward-Port-Of: odoo/odoo#269549