**Steps to reproduce:**
- Create a combo, set the free and max to 3
- Create the product combo and set it's price to 50
- Go to PoS, order said combo and chose the same product 3 times
- The price is 49.98 instead of 50

**Problem:**
When ordering a combo and taking the same product multiple times, the method to adjust the price does not work as it should. In this case, the method would subtract too much from the total, leading it to be only 49.98 instead of 50.

**Why the fix:**
This happens because when ordering a combo, each line will get it's price_unit from the combo's price divided by the number of lines.
In the case where we have 3 different products, hence 3 different lines, the first two would have a unit_price of 16.67 and the last line will be adjusted as to make it equal to the combo's price, so the last line would be 16.66, making the sum 50. But in the case where there is only one line, the last line is still adjusted, making all the lines 16.66, introducing this error. 

The solution would be to take the line's qty into account when computing how much we should subtract.
Unfortunalty, doing so will, in some cases, introduce a rounding error. If the new unit_price does not round up well (like in this case where it is 16.666668 before rounding and 16.67 after), the rounding will cause a difference between what's shown in the frontend and what's written on the lines in the backend, as the lines are rounded up again before being saved to the backend.

The introduced solution is to split the lines, and each have a quantity of 1. With this solution, we can have a different price_unit for each line, which resolves our problem, as the first two lines will have 16.67 and the last one will have 16.66 as price_unit. 
This is how it was done up until version 18.0, showing every line with a quantity of 1 instead of grouping them.
As the grouped lines are now single, some rounding with taxes might differ from what it was before, which is why a test was altered.

opw-4931215

Steps to reproduce:
1. Create a db with having 'sale' & 'project' installed in version 16.
2. Create a sale order having linkage to more than single project.
3. Migrate the db to version 19.
4. When clicking on the project stat button the breadcrumb traceability will not be there.

Issue:
-> In v16.4 the target defined for the action `project.open_view_project_all` is removed from [here](odoo/odoo@a92d686)

When migrating a database from v16 to v19 and opening projects from a sale order linked to multiple projects, the stat button triggers `action_view_project_ids`, which in turn calls
`project.open_view_project_all` for records having len('projects_ids') > 1 from [here]
(https://github.com/odoo/odoo/blame/19.0/addons/sale_project/models/sale_order.py#L220) Because the persisted target is `main`, breadcrumb traceability will be lost. The issue will arise in the DBs coming from version 16 or lesser. Therefore, it would be necessary to address this immediately and set correct target for window_action for databases >= v17

This commit explicitly sets the action target to `current` to restore proper breadcrumb behavior and align it with standard odoo record.

OPW-5448916

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

Steps to reproduce on runbot
------------------
Select a product with several variants and a Bill of Materials
(e.g. Stool).

Change the variants order so that their ids are not ordered, this can
be done by modifying the default_code for example (e.g. Internal
Reference for variant "Color: Green" set to "A").

When accessing the BoM report, you won’t be able to switch to one of
the possible variants (in the example the Dark Blue variant).

Why it is happening
------------------
The default variant to be displayed when opening the report is selected
in the backend using the product_variant_id field. This field is
computed as the first element in product_variant_ids as they are
ordered in the model.

We then send this variant’s information to the frontend and a
dictionary containing every variant (key= id and value = display_name).
In the serialization process, the object is reordered based on the
keys. Thus, if the variants were not ordered based on their ids in
python, the order will change.

The displayed variant is correct as it has been passed directly but the
frontend also computes the currentVariant attribute. This is computed
as the first element in the dictionary but in this case, it is not the
one that has been selected in the backend, as the order changed.

As a result, you see the report for a variant A but the frontend
considers you are on the report for variant B so you cannot switch to
variant B as you are supposed to be already on it.

The fix
------------------
I propose to use the explicitly passed id as the currentVariantId.

opw-5409493

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

Forward-Port-Of: odoo/odoo#247664
Forward-Port-Of: odoo/odoo#241603

### Issue:

Due to recent [commit]
(https://github.com/odoo/odoo/commit/06ff5d42e66b800a7e09a52e9abd51b7fb759cc3) , neutralization of the database is hampered and following error is encountered.

Traceback on neutralizing:
```py
odoo.sql_db: bad query: b"-- disable_l10n_pl_edi_integration\n\n-- clear KSeF Credentials\nUPDATE res_company\n   SET l10n_pl_edi_certificate = NULL,\n       l10n_pl_edi_access_token = NULL,\n       l10n_pl_edi_refresh_token = NULL,\n       l10n_pl_edi_session_id = NULL,\n       l10n_pl_edi_session_key = NULL,\n       l10n_pl_edi_session_iv = NULL\n;\n\n-- set test environment parameter\n     INSERT INTO ir_config_parameter (key, value, create_date, write_date)\n          VALUES ('l10n_pl_edi_ksef.mode', 'test', NOW(), NOW())\n     ON CONFLICT (key)\n   DO UPDATE SET value = 'test',\n                 write_date = NOW()\n;"
ERROR: column "l10n_pl_edi_session_key" of relation "res_company" does not exist
LINE 9:        l10n_pl_edi_session_key = NULL,

```

Before this commit:
```sql
test_18_pl=> SELECT column_name
FROM information_schema.columns
WHERE table_name = 'res_company'
  AND column_name LIKE 'l10n_pl_edi%';
        column_name
---------------------------
 l10n_pl_edi_certificate
 l10n_pl_edi_access_token
 l10n_pl_edi_refresh_token
 l10n_pl_edi_session_id
(4 rows)
```

After this commit:
```sql
test_18_pl=> SELECT column_name
FROM information_schema.columns
WHERE table_name = 'res_company'
  AND column_name LIKE 'l10n_pl_edi%';
        column_name
---------------------------
 l10n_pl_edi_certificate
 l10n_pl_edi_session_iv
 l10n_pl_edi_session_key
 l10n_pl_edi_access_token
 l10n_pl_edi_refresh_token
 l10n_pl_edi_session_id
(6 rows)
```

### Solution:

Set attachment=False for the fields `l10n_pl_edi_session_key` and `l10n_pl_edi_session_iv`, ensuring that their columns are created directly on the  res.company model instead of being stored as attachments. Eventually, during [neutralizing]
(https://github.com/odoo/odoo/blob/18.0/addons/l10n_pl_edi/data/neutralize.sql#L4-#L10) there won't be any column missing error.

Ticket [link](https://www.odoo.com/odoo/project.task/5751411)
opw-5751411

Forward-Port-Of: odoo/odoo#247130

**Steps to reproduce:**
- Install Website/Appointment/Sales apps
- Create a new event and set a ticket price
- Create a fiscal position (with specific tax) for a country with `auto_apply` enabled
- Publish the event
- Book an appointment with up-front payment enabled as a anonymous user
- The process bypasses the address form and goes directly to payment
- The resulting sale order will have no fiscal position
- Prices won't be impacted by taxes related to the user billing address

**Issue:**
Address form is skipped before payment for appointment booking of a public user as `_needs_customer_address` is not overwritten properly in some module. This is probably due to a refactoring that changed how the required information is evaluated in the payment flow (see related commit).

**Fix:**
Set _needs_customer_address to True by default to avoid such issues in
dependant modules. Might need to remove this feature in master as the workarounds are
not that clean (geao_ip, check on fiscal position enabled, overwrite everywhere, others ?).

related: https://github.com/odoo/odoo/commit/d43f0423667835512e16c3fd3474328da63a948d

opw-5143124