Issue Before This PR:

When clearing the Date field in the WIP Accounting Entry wizard, an error was raised during the re-computation of dependent fields. This prevented from temporarily emptying the date field while editing the wizard.

Steps to Reproduce:

- Open the list view of Manufacturing Orders.
- Open the Post WIP Accounting Entry wizard by either:
- Selecting one or more Manufacturing Orders and choosing Actions ,click Post WIP Accounting Entry
- Or, opening a Manufacturing Order form and selecting Post WIP Accounting Entry from the Actions & Reports menu.
- Clear the Date field.
- Observe that an error is raised.

Cause of the Issue:

The compute methods _compute_reversal_date() and _compute_line_ids() assumed that wizard.date was always set. When the Date field was cleared, its value became False, but the compute logic still attempted to compare or use the date, resulting in an error.

With This PR:

The compute methods now verify that wizard.date is set before performing date-dependent computations. This prevents errors when the Date field is temporarily cleared, allowing the wizard to behave correctly during user input.

Issue reference: https://github.com/odoo/odoo/issues/246547

Forward-Port-Of: odoo/odoo#273002

Issue:
Replacing an icon removes style classes applied to the original icon,
such as `rounded`, `rounded-circle`, `shadow`, or `img-thumbnail`.

This issue was introduced by [commit], which stopped preserving
image-specific classes when replacing an image with an icon. This
behavior is appropriate in the backend editor, where icons do not
support these styling options. However, the same logic also affected the
website builder, where icons support the same styling options as images.
As a result, these classes were unnecessarily removed when replacing an
icon.

Steps to reproduce:
1. Add an icon with style classes such as `rounded`, `rounded-circle`,
   `shadow`, or `img-thumbnail`.
2. Replace the icon.
3. Notice that the style classes are removed from the new icon.

Fix:
Preserve these style classes when replacing icons in the website
builder, allowing the newly selected icon to retain the existing visual
styling.

[commit]: https://github.com/odoo/odoo/commit/8638dbc21a7a3ebb3c9cc195d2249b4eb5c264ab
task-[6200832](https://www.odoo.com/odoo/project/974/tasks/6200832)

Forward-Port-Of: odoo/odoo#273598
Forward-Port-Of: odoo/odoo#265496

**Description of the issue/feature this PR addresses:**
When branch companies are involved, currency conversion goes through the branch instead of its root company. Because currency rates in Odoo only ever live on the root company, resolving a rate through a branch is incorrect. Furthermore, when two sibling branches are active at the same time, it makes the computed company a multi-record set, breaking the reconciliation process with an "Expected singleton" error.

This is grounded in how the rest of res.currency already behaves by design:

res.currency._get_rates() looks up rates with company_id in (False, company.root_id.id).

res.currency.rate._check_company_id() forbids setting a rate on a company that has a parent_id.

Therefore, rates are, by design, only ever meant to live on the root company. The only place that still passed the raw company (branch included) into with_company() was res.currency._get_conversion_rate().

**Current behavior before PR:**
_get_conversion_rate() forwarded the received company untouched to from_currency.with_company(company). As a result, Odoo looked up the conversion rate through the branch rather than its parent.

When more than one branch of the same parent is active at the same time (resulting in a recordset of 2+ branches), company.currency_id inside _compute_current_rate() was no longer a singleton, causing the code to crash with ValueError: Expected singleton: res.company(...) — even though every branch shares the exact same currency and rate defined on their common root company.

**Steps to reproduce:**
1) Enable multi-company and branches.
2) Create a parent company P (e.g., using ARS as main currency).
3) Create two branches under P: B1 and B2 (branches inherit P's currency).
4) On the parent company P, define a currency rate for a foreign currency, e.g., USD (Accounting > Configuration > Currencies > USD > Rates).
5) Log in with a user that has P, B1, and B2 all selected as active companies (all three checked in the top-right company switcher).
6) In branch B1, create a customer invoice in USD.
7) In branch B2, register a customer payment in USD.
8) Open the Auto-reconcile tool or try to reconcile the journal items directly.

Result: A ValueError: Expected singleton is raised during the reconciliation because the conversion rate is resolved against the multi-company recordset B1 + B2 instead of P.

**Desired behavior after PR is merged:**
_get_conversion_rate() now resolves the company to its root_id before computing the rate. Branches will correctly fallback to their parent company, and multiple active sibling branches will collapse to a single root company, ensuring that company.currency_id remains a singleton.

With the same steps described above, the invoice and the payment now reconcile normally, safely using the single USD rate defined on the parent root company. Non-branch (standalone) companies remain unaffected since a root company's root_id is itself.

**video**
https://drive.google.com/file/d/14NGTTzP28CgSiYFQdFZ6juHSsib_MDd9/view
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#273758

similar fix: https://github.com/odoo/odoo/pull/181220

- On a kanban view, click "New" to open a quick create record;
- On a many2one field, type a value and click "Create and edit...";
- A dialog opens to create the related record;
- From that dialog, open another many2one field the same way, so a second dialog opens on top of the first one;
- Change tab in the browser.

Before this commit, the quick create's `beforeVisibilityChange` handler unconditionally validated and closed itself as soon as the tab became hidden, with no regard for what was happening around it. Since the "Create and edit" dialogs are owned by the field widgets living inside the quick create (`useOwnedDialogs`), closing the quick create also close those dialogs, with no action from the user.

This reuses the `formInDialog` counter already relied on by `FormController` for the same kind of issue: the quick create now listens to the same `FORM-CONTROLLER:FORM-IN-DIALOG` bus events, and only validates/closes itself on visibility change once every dialog opened from it has been closed.

opw-6357255

Forward-Port-Of: odoo/odoo#274054

Steps to reproduce:
------------------------------------
1. Install Rental(sale_renting) module and activate Pricelist.
2. Go to Rental > Products > Pricelists.
3. Open an existing pricelist or create a new one.
4. Add a pricelist rule and set:
   - Apply To: Category
   - Configure the rule (e.g. select a category).
5. Save and close the rule, then save the pricelist.
6. Reopen the pricelist rule.

Observation:
------------------------------------
The "Apply To" option is no longer set to Category. Instead, it default value to Product, and the selected category is not saving correctly.

Issue:
------------------------------------
After [This Commit](https://github.com/odoo/odoo/commit/d2648b1d983927b5df7260a16d6d1d33c213ddeb), 'display_applied_on' is used to control the visibility of uom_id but is not defined in the list view. As a result, field parsing marks it as readonly, so its updated value is not saved.

This causes the "Apply To" option to fall back to its default value ('Product') when the pricelist rule is reopened.

Solution:
------------------------------------
Include the display_applied_on field in the pricelist item list view so the selected "Apply To" option is preserved when saving the pricelist.

opw-6346422

Forward-Port-Of: odoo/odoo#273596

Version:
----------
- 18.0+

Steps to reproduce:
----------------------
1. Install `mrp`, create two warehouses A and B.
2. Create a storable product with Track Inventory True.
3. Create a Manufacturing Order for 10 qty with(Miscellaneous tab):
   - Components location = Warehouse A (raw materials)
   - Finished product Location = Warehouse B
4. Confirm the MO.
5. Open the Forecast report for the product.

Issue:
-------
- Warehouse B forecast shows the MO under the replenishment detail
  lines (correctly, via `location_dest_id`) but the header displays
  "0 Incoming", "0 Outgoing", "0 Forecasted".
- Warehouse A forecast incorrectly shows "10 Incoming" in the header,
  even though no finished product is going there.

Cause:
-------
- When we create MO for finished Product move is created
if there no `location_final_id` then it set mo.warehouse_id.lot_stock_id` 
as the `location_final_id`.

https://github.com/odoo/odoo/blob/f958a323fd652af9251215b1b5a2fadc3bccba42/addons/mrp/models/stock_move.py#L466-L467

which is introduce in this [commit](https://github.com/odoo-dev/odoo/commit/95ce0ed97a160e3465c313ed6b9bef938d61586b)

- The problem is that `mo.warehouse_id` is a related field computed from
`mo.location_src_id.warehouse_id`

https://github.com/odoo/odoo/blob/f958a323fd652af9251215b1b5a2fadc3bccba42/addons/mrp/models/mrp_production.py#L110

- this warehouse that supplies the **raw materials** (Warehouse A). 
When the user sets `location_dest_id`
to Warehouse B's stock, `mo.warehouse_id` is still Warehouse A, so
`location_final_id` is stamped with Warehouse A's stock location.

- `product.incoming_qty` (used by the forecast header) evaluates non-done
moves using `location_final_id` first (if set), falling back to
`location_dest_id` only when `location_final_id` is False:

https://github.com/odoo/odoo/blob/f958a323fd652af9251215b1b5a2fadc3bccba42/addons/stock/models/product.py#L331-L335

- Because `location_final_id` is set (to WH-A) and non-False, the
second clause (which would pick up `location_dest_id` = WH-B) is never
evaluated. The result: the move is counted as incoming in Warehouse A
and ignored in Warehouse B.

- The forecast detail *lines* use only `location_dest_id` to classify
moves, so they correctly show the MO as incoming for Warehouse B —
producing the inconsistency the user observes.

https://github.com/odoo/odoo/blob/f958a323fd652af9251215b1b5a2fadc3bccba42/addons/stock/report/stock_forecasted.py#L42-L46

Fix:
----
- Replace `mo.warehouse_id.lot_stock_id.id` with `mo.location_dest_id.id`:

- `location_final_id` is meant to track where the product ultimately
ends up when the immediate destination is intermediate. The correct
"final" location for a finished-product move is exactly what the user
chose as `location_dest_id` on the MO — not the stock location of the
warehouse that happens to supply the raw materials.

- For the standard single-warehouse case, `mo.location_dest_id` equals
`mo.warehouse_id.lot_stock_id`, so the behaviour is unchanged. For
cross-warehouse MOs (destination = WH-B), `location_final_id` is now
stamped with WH-B's stock, making `product.incoming_qty` and the
forecast header consistent with the detail lines.

----

opw-6294479

Forward-Port-Of: odoo/odoo#270089

Issue Before This PR:

When clearing the Date field in the WIP Accounting Entry wizard, an error was raised during the re-computation of dependent fields. This prevented from temporarily emptying the date field while editing the wizard.

Steps to Reproduce:

- Open the list view of Manufacturing Orders.
- Open the Post WIP Accounting Entry wizard by either:
- Selecting one or more Manufacturing Orders and choosing Actions ,click Post WIP Accounting Entry
- Or, opening a Manufacturing Order form and selecting Post WIP Accounting Entry from the Actions & Reports menu.
- Clear the Date field.
- Observe that an error is raised.

Cause of the Issue:

The compute methods _compute_reversal_date() and _compute_line_ids() assumed that wizard.date was always set. When the Date field was cleared, its value became False, but the compute logic still attempted to compare or use the date, resulting in an error.

With This PR:

The compute methods now verify that wizard.date is set before performing date-dependent computations. This prevents errors when the Date field is temporarily cleared, allowing the wizard to behave correctly during user input.

Issue reference: https://github.com/odoo/odoo/issues/246547

Forward-Port-Of: odoo/odoo#273002

Issue:
Replacing an icon removes style classes applied to the original icon,
such as `rounded`, `rounded-circle`, `shadow`, or `img-thumbnail`.

This issue was introduced by [commit], which stopped preserving
image-specific classes when replacing an image with an icon. This
behavior is appropriate in the backend editor, where icons do not
support these styling options. However, the same logic also affected the
website builder, where icons support the same styling options as images.
As a result, these classes were unnecessarily removed when replacing an
icon.

Steps to reproduce:
1. Add an icon with style classes such as `rounded`, `rounded-circle`,
   `shadow`, or `img-thumbnail`.
2. Replace the icon.
3. Notice that the style classes are removed from the new icon.

Fix:
Preserve these style classes when replacing icons in the website
builder, allowing the newly selected icon to retain the existing visual
styling.

[commit]: https://github.com/odoo/odoo/commit/8638dbc21a7a3ebb3c9cc195d2249b4eb5c264ab
task-[6200832](https://www.odoo.com/odoo/project/974/tasks/6200832)

Forward-Port-Of: odoo/odoo#273598
Forward-Port-Of: odoo/odoo#265496

**Description of the issue/feature this PR addresses:**
When branch companies are involved, currency conversion goes through the branch instead of its root company. Because currency rates in Odoo only ever live on the root company, resolving a rate through a branch is incorrect. Furthermore, when two sibling branches are active at the same time, it makes the computed company a multi-record set, breaking the reconciliation process with an "Expected singleton" error.

This is grounded in how the rest of res.currency already behaves by design:

res.currency._get_rates() looks up rates with company_id in (False, company.root_id.id).

res.currency.rate._check_company_id() forbids setting a rate on a company that has a parent_id.

Therefore, rates are, by design, only ever meant to live on the root company. The only place that still passed the raw company (branch included) into with_company() was res.currency._get_conversion_rate().

**Current behavior before PR:**
_get_conversion_rate() forwarded the received company untouched to from_currency.with_company(company). As a result, Odoo looked up the conversion rate through the branch rather than its parent.

When more than one branch of the same parent is active at the same time (resulting in a recordset of 2+ branches), company.currency_id inside _compute_current_rate() was no longer a singleton, causing the code to crash with ValueError: Expected singleton: res.company(...) — even though every branch shares the exact same currency and rate defined on their common root company.

**Steps to reproduce:**
1) Enable multi-company and branches.
2) Create a parent company P (e.g., using ARS as main currency).
3) Create two branches under P: B1 and B2 (branches inherit P's currency).
4) On the parent company P, define a currency rate for a foreign currency, e.g., USD (Accounting > Configuration > Currencies > USD > Rates).
5) Log in with a user that has P, B1, and B2 all selected as active companies (all three checked in the top-right company switcher).
6) In branch B1, create a customer invoice in USD.
7) In branch B2, register a customer payment in USD.
8) Open the Auto-reconcile tool or try to reconcile the journal items directly.

Result: A ValueError: Expected singleton is raised during the reconciliation because the conversion rate is resolved against the multi-company recordset B1 + B2 instead of P.

**Desired behavior after PR is merged:**
_get_conversion_rate() now resolves the company to its root_id before computing the rate. Branches will correctly fallback to their parent company, and multiple active sibling branches will collapse to a single root company, ensuring that company.currency_id remains a singleton.

With the same steps described above, the invoice and the payment now reconcile normally, safely using the single USD rate defined on the parent root company. Non-branch (standalone) companies remain unaffected since a root company's root_id is itself.

**video**
https://drive.google.com/file/d/14NGTTzP28CgSiYFQdFZ6juHSsib_MDd9/view
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#273758

### Issue:
When creating a website through the configurator and selecting the
website type 'an eCommerce', the shop feature is not preselected as
expected.

### Steps to reproduce:
- Ensure that the eCommerce module is not installed.
- Navigate to Website > Configuration > Settings.
- Click on the "New Website" button to create a new website.
- Select the "eCommerce" option as the website type and proceed to the
  next step.
- On the "Add Pages and Features" screen, observe that the "Shop" option
  is not selected by default.

### Reason:
0cb45457 renamed the website type from `online_store` to `eCommerce`,
but the related feature was not updated and still references the old
name. As a result, the preselection is not triggered.

### Fix:
Restore the eCommerce website type's internal name to `online_store` in
the configurator. This matches the value already stored in the database
for existing installations, allowing the shop feature preselection to
work for existing users as well, without requiring a data update.

task-[6284263](https://www.odoo.com/odoo/project/974/tasks/6284263)

[1]:https://github.com/odoo/odoo/pull/223724

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

Forward-Port-Of: odoo/odoo#268829

similar fix: https://github.com/odoo/odoo/pull/181220

- On a kanban view, click "New" to open a quick create record;
- On a many2one field, type a value and click "Create and edit...";
- A dialog opens to create the related record;
- From that dialog, open another many2one field the same way, so a second dialog opens on top of the first one;
- Change tab in the browser.

Before this commit, the quick create's `beforeVisibilityChange` handler unconditionally validated and closed itself as soon as the tab became hidden, with no regard for what was happening around it. Since the "Create and edit" dialogs are owned by the field widgets living inside the quick create (`useOwnedDialogs`), closing the quick create also close those dialogs, with no action from the user.

This reuses the `formInDialog` counter already relied on by `FormController` for the same kind of issue: the quick create now listens to the same `FORM-CONTROLLER:FORM-IN-DIALOG` bus events, and only validates/closes itself on visibility change once every dialog opened from it has been closed.

opw-6357255

Forward-Port-Of: odoo/odoo#274054

### Commit 1:

[FIX] website: prevent CSRF error by blocking duplicate form submission

Before this commit: Clicking the logout button from the website
preview triggered two simultaneous logout requests:

1. The browser performed the default form submission with a valid
   `csrf_token`, destroying the session afterward.
2. During the same click event, `setupClickListener()` intercepted
   the click using `closest('[action]')`, found the parent
   `/web/session/logout` form, and triggered a second POST request
   using `odoo.csrf_token`.

Since the session was already destroyed by the first request, the
second request resulted in a "CSRF validation failed" error.

This commit prevents the default form submission before triggering
the manual POST request, ensuring that only one request is sent.

Runbot-940403

--------------------------------------------------------------------------------------------------------------------------------

### Commit 2:

[FIX] website: enable free sign up setting in test_auth_forms_warning

Steps to reproduce:
1. Install any website related module (e.g. `website`, `website_event`).
2. Keep the default configuration and do not manually enable
   'Free sign up' in Settings.
3. Run `test_auth_forms_warning`.

Before this commit: The test did not programmatically enable the
'Free sign up' setting. As a result, it failed unless a developer
manually navigated to the setting and enabled it beforehand.

After this commit: This commit explicitly enables the "Free sign up"
configuration during test execution, allowing public access to the
`/web/signup` page and ensuring the test passes without any manual
setup.

runbot-940394

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

Forward-Port-Of: odoo/odoo#272020

after commit [1] we are not able to open pos session, if we have installed only
point_of_sale

[1] https://github.com/odoo/odoo/commit/f20b2d22dbec2e6a5e682539489ab94d9c96fb21

Traceback

```py
File "odoo/saas-19.3/addons/point_of_sale/models/pos_session.py", line 161, in load_data
    response[model] = self.env[model]._load_pos_data_search_read(response, self.config_id)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/codebase/odoo/saas-19.3/addons/point_of_sale/models/pos_load_mixin.py", line 24, in _load_pos_data_search_read
    return self._load_pos_data_read(records, config)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/codebase/odoo/saas-19.3/addons/point_of_sale/models/pos_load_mixin.py", line 55, in _load_pos_data_read
    records = records._filtered_access("read").read(fields, load=False)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/codebase/odoo/saas-19.3/odoo/orm/models.py", line 2760, in read
    self._origin.fetch(fields)
  File "odoo/codebase/odoo/saas-19.3/odoo/orm/models.py", line 3062, in fetch
    fields_to_fetch = self._determine_fields_to_fetch(field_names, ignore_when_in_cache=True)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/codebase/odoo/saas-19.3/odoo/orm/models.py", line 3141, in _determine_fields_to_fetch
    raise ValueError(f"Invalid field {field_name!r} on {self._name!r}") from e
ValueError: Invalid field 'removal_strategy_id' on 'product.category'

```

cause:
- field `removal_strategy_id` comes from stock and from saas-19.3 point_of_sale
is not dependent on stock.

FIx:
- correct module should be `pos_stock`

opw-6364126

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

Issue Before This PR:

When clearing the Date field in the WIP Accounting Entry wizard, an error was raised during the re-computation of dependent fields. This prevented from temporarily emptying the date field while editing the wizard.

Steps to Reproduce:

- Open the list view of Manufacturing Orders.
- Open the Post WIP Accounting Entry wizard by either:
- Selecting one or more Manufacturing Orders and choosing Actions ,click Post WIP Accounting Entry
- Or, opening a Manufacturing Order form and selecting Post WIP Accounting Entry from the Actions & Reports menu.
- Clear the Date field.
- Observe that an error is raised.

Cause of the Issue:

The compute methods _compute_reversal_date() and _compute_line_ids() assumed that wizard.date was always set. When the Date field was cleared, its value became False, but the compute logic still attempted to compare or use the date, resulting in an error.

With This PR:

The compute methods now verify that wizard.date is set before performing date-dependent computations. This prevents errors when the Date field is temporarily cleared, allowing the wizard to behave correctly during user input.

Issue reference: https://github.com/odoo/odoo/issues/246547

Forward-Port-Of: odoo/odoo#273002

Issue:
When an invoice (sales journal) uses "Switzerland" localization and the invoice is issued to a customer outside Switzerland/Liechtenstein, no payment reference is generated. This causes the invoice PDF to hide payment communication and bank account details.

Other localizations like Belgian companies, uses Belgian references, the reference is always generated regardless of customer country.

Steps to reproduce:
- Configure a Swiss company with a QR IBAN bank account
- Set the sales journal Communication Standard to Switzerland
- Create and confirm an invoice for a non swiss customer (US, BE)
- Observe in the pdf and in the other info tab -> no payment reference or payment details

Cause:
`get_l10n_ch_qrr_number()` was using on `l10n_ch_is_qr_valid()`, which conflicts QR-bill printability (partner country, currency) with payment reference generation. When the customer is outside CH/LI, `l10n_ch_is_qr_valid()` is False and no QRR reference is generated.

Solution:
Decouple QRR reference generation from QR bill printability. The Swiss communication standard now generates a QRR format reference when a QR-IBAN is configured, regardless of customer's country or currency.

opw-6222417

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

Forward-Port-Of: odoo/odoo#266861

**Description of the issue/feature this PR addresses:**
When branch companies are involved, currency conversion goes through the branch instead of its root company. Because currency rates in Odoo only ever live on the root company, resolving a rate through a branch is incorrect. Furthermore, when two sibling branches are active at the same time, it makes the computed company a multi-record set, breaking the reconciliation process with an "Expected singleton" error.

This is grounded in how the rest of res.currency already behaves by design:

res.currency._get_rates() looks up rates with company_id in (False, company.root_id.id).

res.currency.rate._check_company_id() forbids setting a rate on a company that has a parent_id.

Therefore, rates are, by design, only ever meant to live on the root company. The only place that still passed the raw company (branch included) into with_company() was res.currency._get_conversion_rate().

**Current behavior before PR:**
_get_conversion_rate() forwarded the received company untouched to from_currency.with_company(company). As a result, Odoo looked up the conversion rate through the branch rather than its parent.

When more than one branch of the same parent is active at the same time (resulting in a recordset of 2+ branches), company.currency_id inside _compute_current_rate() was no longer a singleton, causing the code to crash with ValueError: Expected singleton: res.company(...) — even though every branch shares the exact same currency and rate defined on their common root company.

**Steps to reproduce:**
1) Enable multi-company and branches.
2) Create a parent company P (e.g., using ARS as main currency).
3) Create two branches under P: B1 and B2 (branches inherit P's currency).
4) On the parent company P, define a currency rate for a foreign currency, e.g., USD (Accounting > Configuration > Currencies > USD > Rates).
5) Log in with a user that has P, B1, and B2 all selected as active companies (all three checked in the top-right company switcher).
6) In branch B1, create a customer invoice in USD.
7) In branch B2, register a customer payment in USD.
8) Open the Auto-reconcile tool or try to reconcile the journal items directly.

Result: A ValueError: Expected singleton is raised during the reconciliation because the conversion rate is resolved against the multi-company recordset B1 + B2 instead of P.

**Desired behavior after PR is merged:**
_get_conversion_rate() now resolves the company to its root_id before computing the rate. Branches will correctly fallback to their parent company, and multiple active sibling branches will collapse to a single root company, ensuring that company.currency_id remains a singleton.

With the same steps described above, the invoice and the payment now reconcile normally, safely using the single USD rate defined on the parent root company. Non-branch (standalone) companies remain unaffected since a root company's root_id is itself.

**video**
https://drive.google.com/file/d/14NGTTzP28CgSiYFQdFZ6juHSsib_MDd9/view
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#273758

### Issue:
When creating a website through the configurator and selecting the
website type 'an eCommerce', the shop feature is not preselected as
expected.

### Steps to reproduce:
- Ensure that the eCommerce module is not installed.
- Navigate to Website > Configuration > Settings.
- Click on the "New Website" button to create a new website.
- Select the "eCommerce" option as the website type and proceed to the
  next step.
- On the "Add Pages and Features" screen, observe that the "Shop" option
  is not selected by default.

### Reason:
0cb45457 renamed the website type from `online_store` to `eCommerce`,
but the related feature was not updated and still references the old
name. As a result, the preselection is not triggered.

### Fix:
Restore the eCommerce website type's internal name to `online_store` in
the configurator. This matches the value already stored in the database
for existing installations, allowing the shop feature preselection to
work for existing users as well, without requiring a data update.

task-[6284263](https://www.odoo.com/odoo/project/974/tasks/6284263)

[1]:https://github.com/odoo/odoo/pull/223724

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

Forward-Port-Of: odoo/odoo#268829

similar fix: https://github.com/odoo/odoo/pull/181220

- On a kanban view, click "New" to open a quick create record;
- On a many2one field, type a value and click "Create and edit...";
- A dialog opens to create the related record;
- From that dialog, open another many2one field the same way, so a second dialog opens on top of the first one;
- Change tab in the browser.

Before this commit, the quick create's `beforeVisibilityChange` handler unconditionally validated and closed itself as soon as the tab became hidden, with no regard for what was happening around it. Since the "Create and edit" dialogs are owned by the field widgets living inside the quick create (`useOwnedDialogs`), closing the quick create also close those dialogs, with no action from the user.

This reuses the `formInDialog` counter already relied on by `FormController` for the same kind of issue: the quick create now listens to the same `FORM-CONTROLLER:FORM-IN-DIALOG` bus events, and only validates/closes itself on visibility change once every dialog opened from it has been closed.

opw-6357255

Forward-Port-Of: odoo/odoo#274054

In a multi-company setup with a website per company, the unsubscribe link in mass mailing emails could send recipients to the login page instead of the unsubscribe confirmation page.

### Steps to reproduce

1. Enable multi-company and create a second company `Company B`.
2. Create two websites with different domains, one per company:
   - `Website A` on the main company, domain `http://website-a.test`
   - `Website B` on `Company B`, domain `http://website-b.test`
3. Set the system parameter `web.base.url` to `http://website-a.test`. System parameters are global, so this value applies to the whole database regardless of the company you switch to.
4. Create a contact and set its `Company` field to `Company B`.
5. In Email Marketing, create a mailing with recipient model `Contact`, target the contact above, pick any template with an unsubscribe link, and send it.
6. Open the email in an incognito window and click the unsubscribe link: you land on the login page instead of the unsubscribe page.

### Cause

Mass mailing builds the unsubscribe link in two steps.

First, each email body is rendered for its recipient. While rendering, relative URLs like `/unsubscribe_from_list` are turned into absolute URLs by prepending a base URL. That base URL comes from the recipient record itself: `recipient.get_base_url()`. The `website` module overrides this so that, when the record has a company, it returns that company's website domain. For a contact in `Company B`, the body ends up with `http://website-b.test/unsubscribe_from_list`.

Second, right before sending, `mail_mail._prepare_outgoing_list` replaces that placeholder URL with a per-recipient signed URL pointing to `/confirm_unsubscribe`. It does this by plain string replacement: it looks for `{base_url}/unsubscribe_from_list` in the body and swaps it. The `base_url` used here came from `self.mailing_id.get_base_url()`. A mailing has no company, so its base URL falls back to the global `web.base.url`, which in our setup is `http://website-a.test`.

The two base URLs no longer match. The body contains the website B URL, but the replacement code searches for the website A URL. The search fails, the placeholder stays in the email, and the recipient clicks a link to `/unsubscribe_from_list`. That route only redirects to `/mailing/my`, which requires being logged in, so the user lands on the login page.

### Fix

Compute the base URL from the recipient record (the same record used when rendering the body) instead of the mailing. The two URLs then agree and the replacement works. Fall back to the mailing's base URL if there is no recipient model on the mail.

opw-4914203

Forward-Port-Of: odoo/odoo#273888
Forward-Port-Of: odoo/odoo#264055

The below test sometimes fail for an incorrect reason and leads to a false 
positive:
https://github.com/odoo/odoo/blob/6dbeac3a42f46b42c638c05aea8285452c944c3f/addons/stock_dropshipping/tests/test_purchase_order.py#L21

Here is another way to reproduce the issue with a higher probability of 
false positive (and it is actually easier to read and understand what the 
test is doing and what's wrong). It needs to edit the following test:
https://github.com/odoo/odoo/blob/ec58c5e12987401659ea0d75d3be2905ad1d807d/addons/purchase_stock/tests/test_create_picking.py#L953
With the below diff:
```diff
--- a/addons/purchase_stock/tests/test_create_picking.py
+++ b/addons/purchase_stock/tests/test_create_picking.py
@@ -965,6 +965,7 @@ class TestCreatePicking(ProductVariantsCommon):
             'price': 500.0,
             'discount': 10,
         })]
+        self.product_id_1.standard_price = 1.0
         po = self.env['purchase.order'].create(self.po_vals)  # create a PO for 5 units
         po.button_confirm()
         with Form(po) as po_form:
```
It will lead to:
```
Traceback (most recent call last):
  File ".../test_create_picking.py", line 976, in test_average_cost_updated_after_po_with_discount
    self.assertEqual(self.product_id_1.standard_price, 450.0)
AssertionError: 1.0 != 450.0
```

Here are the explanations: when receiving an AVCO product, at some point, we 
recompute its standard price. To do so, among several operations, we take 
the last manual update, and we ignore all previous SM:
https://github.com/odoo/odoo/blob/2dbd88657395da965125c8f085da93e04c9c8f0a/addons/stock_account/models/product.py#L463-L465

This is an issue when things are done too quickly. See the pattern:
```py
self.product_a.standard_price = 5.0 # -> define valuation_from_date
po.confirm() # with another cost
receipt.button_validate() # -> define move.date
``` 
In case of a fast execution, both dates will be equal. We therefore ignore 
the SM and rely on the manual update to define the standard price, which is 
not expected. This explains the above `AssertionError`.

Fixing the codebase is quite tricky since the opposite use case could also
happen, aka first processing a receipt and only then modifiying the standard
price.

Tests side, a more important solution should probably be implemented to ease
their redaction and avoid this basic pattern. Yet, a WIP task is changing
the valo for Odoo 20, so the whole logic may change. Second, the current
issue is impacting a lot of builds, so we need to move forward. For both
reason, the commit only "fixes" the current test.

runbot-939955

Forward-Port-Of: odoo/odoo#273078

Issue:
Replacing an icon removes style classes applied to the original icon,
such as `rounded`, `rounded-circle`, `shadow`, or `img-thumbnail`.

This issue was introduced by [commit], which stopped preserving
image-specific classes when replacing an image with an icon. This
behavior is appropriate in the backend editor, where icons do not
support these styling options. However, the same logic also affected the
website builder, where icons support the same styling options as images.
As a result, these classes were unnecessarily removed when replacing an
icon.

Steps to reproduce:
1. Add an icon with style classes such as `rounded`, `rounded-circle`,
   `shadow`, or `img-thumbnail`.
2. Replace the icon.
3. Notice that the style classes are removed from the new icon.

Fix:
Preserve these style classes when replacing icons in the website
builder, allowing the newly selected icon to retain the existing visual
styling.

[commit]: https://github.com/odoo/odoo/commit/8638dbc21a7a3ebb3c9cc195d2249b4eb5c264ab
task-[6200832](https://www.odoo.com/odoo/project/974/tasks/6200832)

Forward-Port-Of: odoo/odoo#265496

**Description of the issue/feature this PR addresses:**
When branch companies are involved, currency conversion goes through the branch instead of its root company. Because currency rates in Odoo only ever live on the root company, resolving a rate through a branch is incorrect. Furthermore, when two sibling branches are active at the same time, it makes the computed company a multi-record set, breaking the reconciliation process with an "Expected singleton" error.

This is grounded in how the rest of res.currency already behaves by design:

res.currency._get_rates() looks up rates with company_id in (False, company.root_id.id).

res.currency.rate._check_company_id() forbids setting a rate on a company that has a parent_id.

Therefore, rates are, by design, only ever meant to live on the root company. The only place that still passed the raw company (branch included) into with_company() was res.currency._get_conversion_rate().

**Current behavior before PR:**
_get_conversion_rate() forwarded the received company untouched to from_currency.with_company(company). As a result, Odoo looked up the conversion rate through the branch rather than its parent.

When more than one branch of the same parent is active at the same time (resulting in a recordset of 2+ branches), company.currency_id inside _compute_current_rate() was no longer a singleton, causing the code to crash with ValueError: Expected singleton: res.company(...) — even though every branch shares the exact same currency and rate defined on their common root company.

**Steps to reproduce:**
1) Enable multi-company and branches.
2) Create a parent company P (e.g., using ARS as main currency).
3) Create two branches under P: B1 and B2 (branches inherit P's currency).
4) On the parent company P, define a currency rate for a foreign currency, e.g., USD (Accounting > Configuration > Currencies > USD > Rates).
5) Log in with a user that has P, B1, and B2 all selected as active companies (all three checked in the top-right company switcher).
6) In branch B1, create a customer invoice in USD.
7) In branch B2, register a customer payment in USD.
8) Open the Auto-reconcile tool or try to reconcile the journal items directly.

Result: A ValueError: Expected singleton is raised during the reconciliation because the conversion rate is resolved against the multi-company recordset B1 + B2 instead of P.

**Desired behavior after PR is merged:**
_get_conversion_rate() now resolves the company to its root_id before computing the rate. Branches will correctly fallback to their parent company, and multiple active sibling branches will collapse to a single root company, ensuring that company.currency_id remains a singleton.

With the same steps described above, the invoice and the payment now reconcile normally, safely using the single USD rate defined on the parent root company. Non-branch (standalone) companies remain unaffected since a root company's root_id is itself.

**video**
https://drive.google.com/file/d/14NGTTzP28CgSiYFQdFZ6juHSsib_MDd9/view
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#273758

When multiple talent records share the same information, opening the Talent Pools smart button from a matching application will trigger a traceback.

Steps to reproduce the error:
- Install ``hr_recruitment`` module with demo data
- Go to Recruitment > Applications > Talent Pools > Create a new pool
- Go to Recruitment > Applications > All Applications > Create a new application with valid email >
  Click Add to Pool > Select the Talent Pool > Add to Pool
- Duplicate the created talent record
- Create another application with the same email > save > click Talent Pools

Traceback:
```py
ValueError: Expected singleton: hr.applicant(2, 1)
```

https://github.com/odoo/odoo/blob/d4e76a5663223a2a2c6e50d1701fabbdcaf32405/addons/hr_recruitment/models/hr_applicant.py#L857-L859
Here, the talent is searched using matching applicant information.
When a matching talent has been duplicated, the search returns multiple records.
Assigning a multi-records to the many2one field ``pool_applicant_id`` then raises a singleton error.

Solution:
Restrict the duplication of talent.

sentry-7556261128

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

Forward-Port-Of: odoo/odoo#273301
Forward-Port-Of: odoo/odoo#270827

### Steps to reproduce:
- Download 'Sales' and 'Timesheets' apps
- Create a service product invoiced on delivered quantities with timesheet tracking
- Create and confirm a SO for quantity 1
- Log 20h on timesheets
- Invoice the SO
- Create a credit note for 11 hours => only 9 hours are invoiced
- Log 5h more on timesheets
- Back to the SO > create invoice again
> All the 25hrs are to invoiced, although 9 of them were invoiced before

### Cause of Issue:
When generating the new invoice, `_recompute_qty_to_invoice` calls `_get_delivered_quantity_by_analytic` which retrieves the analytic values for the SO line.

The values retrieved are later used to determine the delivered quantity, which is later assigned to be `line.qty_to_invoice` without taking into account the already invoiced hours. https://github.com/odoo/odoo/blob/7a6518e39d34575a3977e7c4a0053a45223e203c/addons/sale_timesheet/models/sale_order_line.py#L176-L186

### Fix:
Ensures that hours that have already been completely invoiced are deducted from the quantity to invoice.

opw-6253650

Forward-Port-Of: odoo/odoo#273156
Forward-Port-Of: odoo/odoo#268025

### Steps to reproduce:

- Have two companies: company1 and company2
- Create a producct P available in both company1 and company2
- with company1, create a kit bom for a product P
- with company2, create and confirm a sale order for 1 unit of P
- with company1, change the bom type of P from kit to manufature
#### > UserError: As long as there are some sale order lines that must be delivered/invoiced and are related to these bills of materials, you can not remove them.

### Cause of the issue:

Changing the bom type from a kit (phantom type) to a non kit will launch a call of the `_ensure_bom_is_free` in order to ensure data integrity if the kit bom was used by a relevant sale order line: https://github.com/odoo/odoo/blob/f4c76be062bec47b68ee42505d7d42fed31ac0f2/addons/sale_mrp/models/mrp_bom.py#L15-L18
https://github.com/odoo/odoo/blob/f4c76be062bec47b68ee42505d7d42fed31ac0f2/addons/sale_mrp/models/mrp_bom.py#L24-L42
However, this check does not take the company of the bom into account and in the present flow, the company of the bom is different from the company of the supposedly problematic sol.

opw-6290304

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

Forward-Port-Of: odoo/odoo#273839
Forward-Port-Of: odoo/odoo#271119

Issue Before This PR:

When clearing the Date field in the WIP Accounting Entry wizard, an error was raised during the re-computation of dependent fields. This prevented from temporarily emptying the date field while editing the wizard.

Steps to Reproduce:

- Open the list view of Manufacturing Orders.
- Open the Post WIP Accounting Entry wizard by either:
- Selecting one or more Manufacturing Orders and choosing Actions ,click Post WIP Accounting Entry
- Or, opening a Manufacturing Order form and selecting Post WIP Accounting Entry from the Actions & Reports menu.
- Clear the Date field.
- Observe that an error is raised.

Cause of the Issue:

The compute methods _compute_reversal_date() and _compute_line_ids() assumed that wizard.date was always set. When the Date field was cleared, its value became False, but the compute logic still attempted to compare or use the date, resulting in an error.

With This PR:

The compute methods now verify that wizard.date is set before performing date-dependent computations. This prevents errors when the Date field is temporarily cleared, allowing the wizard to behave correctly during user input.

Issue reference: https://github.com/odoo/odoo/issues/246547

Forward-Port-Of: odoo/odoo#273002

The below test sometimes fail for an incorrect reason and leads to a false 
positive:
https://github.com/odoo/odoo/blob/6dbeac3a42f46b42c638c05aea8285452c944c3f/addons/stock_dropshipping/tests/test_purchase_order.py#L21

Here is another way to reproduce the issue with a higher probability of 
false positive (and it is actually easier to read and understand what the 
test is doing and what's wrong). It needs to edit the following test:
https://github.com/odoo/odoo/blob/ec58c5e12987401659ea0d75d3be2905ad1d807d/addons/purchase_stock/tests/test_create_picking.py#L953
With the below diff:
```diff
--- a/addons/purchase_stock/tests/test_create_picking.py
+++ b/addons/purchase_stock/tests/test_create_picking.py
@@ -965,6 +965,7 @@ class TestCreatePicking(ProductVariantsCommon):
             'price': 500.0,
             'discount': 10,
         })]
+        self.product_id_1.standard_price = 1.0
         po = self.env['purchase.order'].create(self.po_vals)  # create a PO for 5 units
         po.button_confirm()
         with Form(po) as po_form:
```
It will lead to:
```
Traceback (most recent call last):
  File ".../test_create_picking.py", line 976, in test_average_cost_updated_after_po_with_discount
    self.assertEqual(self.product_id_1.standard_price, 450.0)
AssertionError: 1.0 != 450.0
```

Here are the explanations: when receiving an AVCO product, at some point, we 
recompute its standard price. To do so, among several operations, we take 
the last manual update, and we ignore all previous SM:
https://github.com/odoo/odoo/blob/2dbd88657395da965125c8f085da93e04c9c8f0a/addons/stock_account/models/product.py#L463-L465

This is an issue when things are done too quickly. See the pattern:
```py
self.product_a.standard_price = 5.0 # -> define valuation_from_date
po.confirm() # with another cost
receipt.button_validate() # -> define move.date
``` 
In case of a fast execution, both dates will be equal. We therefore ignore 
the SM and rely on the manual update to define the standard price, which is 
not expected. This explains the above `AssertionError`.

Fixing the codebase is quite tricky since the opposite use case could also
happen, aka first processing a receipt and only then modifiying the standard
price.

Tests side, a more important solution should probably be implemented to ease
their redaction and avoid this basic pattern. Yet, a WIP task is changing
the valo for Odoo 20, so the whole logic may change. Second, the current
issue is impacting a lot of builds, so we need to move forward. For both
reason, the commit only "fixes" the current test.

runbot-939955

Forward-Port-Of: odoo/odoo#273078

Issue Before This PR:

When clearing the Date field in the WIP Accounting Entry wizard, an error was raised during the re-computation of dependent fields. This prevented from temporarily emptying the date field while editing the wizard.

Steps to Reproduce:

- Open the list view of Manufacturing Orders.
- Open the Post WIP Accounting Entry wizard by either:
- Selecting one or more Manufacturing Orders and choosing Actions ,click Post WIP Accounting Entry
- Or, opening a Manufacturing Order form and selecting Post WIP Accounting Entry from the Actions & Reports menu.
- Clear the Date field.
- Observe that an error is raised.

Cause of the Issue:

The compute methods _compute_reversal_date() and _compute_line_ids() assumed that wizard.date was always set. When the Date field was cleared, its value became False, but the compute logic still attempted to compare or use the date, resulting in an error.

With This PR:

The compute methods now verify that wizard.date is set before performing date-dependent computations. This prevents errors when the Date field is temporarily cleared, allowing the wizard to behave correctly during user input.

Issue reference: https://github.com/odoo/odoo/issues/246547

Forward-Port-Of: odoo/odoo#273002

When a live chat channel has no operators configured and the chatbot
script ends with a Forward to operator step, triggering that step
causes a traceback.

Steps to reproduce the error:
- Install ``im_livechat`` module with demo data
- Go to Live Chat > Configuration > Chatbots > Create a new chatbot >
  Add script > Step Type: Question > Set answers > Save >
  Add script > Step Type: Forward to operator >
  Only If: Set one of the above answers > Save
- Go to Live chat > Channel > Click the configure channel on YourWebsite.com > Remove the operators > Save
- Go to the chatbot > test > select the configured answer

Traceback:
```py
StopIteration
```

https://github.com/odoo/odoo/blob/8791cdcd89ea3cb56b1fac63b3e2ffbd2956a912/addons/im_livechat/controllers/chatbot.py#L65-L70
When the chatbot script reaches a Forward to operator step while no operator
is configured in the live chat channel, no chatbot message is created.
As a result, the generator iterates over an empty iterator, and
the ``next()`` call raises a ``StopIteration`` exception, causing a traceback
during the conversation.

sentry-7435424405

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

Forward-Port-Of: odoo/odoo#261726

**Problem:**
On a round-the-clock (0h-24h) working schedule, shifts created from a shift template that spans more than one day get one extra minute added to their allocated time: an 8-hour shift shows 08:01.

**Steps to reproduce:**
1. Create a working schedule with a 00:00 -> 24:00 attendance for every day (24h/day, "Full Day").
2. Assign an employee to that schedule.
3. Create a multi-day-span shift template (e.g. 16:00 -> 00:00, 2 days).
4. Plan a shift for that employee using the template.
5. Observe the Allocated Time shows one minute more than expected (08:01).

**Current behavior:**
Allocated Time is one minute too long (e.g. 08:01 instead of 08:00), which throws off the customer's planning reports.

**Expected behavior:**
Allocated Time matches the template duration exactly (08:00).

**Cause of the issue:**
In `_calculate_start_end_dates`, the end of a multi-day-span shift is computed with `resource.calendar_id.plan_days(...)`. On a 0h-24h calendar each day ends at `time.max` (23:59:59.999999), so `plan_days` returns an end datetime carrying those stale seconds. The following `end.replace(hour=..., minute=...)` overwrites only the hour and minute, leaving `second=59, microsecond=999999`. The slot is therefore ~1 minute longer than intended, and `allocated_hours` rounds that up to 08:01.

**Fix:**
Resetting seconds and microseconds when rebuilding the end datetime keeps the slot aligned to the template's whole-minute boundary, regardless of how the underlying calendar represents the end of day. The hour/minute already come from the template, so the leftover sub-minute precision from `plan_days` is never meaningful and is what produces the drift.

opw-6265238

Forward-Port-Of: odoo/enterprise#122157
Forward-Port-Of: odoo/enterprise#120219

Steps to reproduce
1. Create two customer invoices that share the same VAT tax, with a payment term granting an early payment discount.
2. Create one bank statement line whose amount equals the sum of both invoices' discounted totals.
3. From the bank reconciliation widget, select both invoices and validate in a single batch reconciliation.
4. Open Accounting > Reporting > Tax Return, switch the variant to "Group by: Account > Tax".

Issue
The cash-discount expense row shows a Net base column equal to twice the real
discount base. The Tax column is correct.

The bank-statement reconciliation paths (set_line_bank_statement_line,
set_batch_payment_bank_statement_line, _reconcile_payments) loop over each
invoice and call _apply_early_payment_discount one invoice at a time. Each
call writes one discount base line and one discount tax line on the resulting
bank entry, so when two invoices share the same tax the bank entry ends up
with two pairs carrying the same (account, partner, currency,
tax_repartition_line_id, tax_ids).

The SQL that feeds the tax report at
https://github.com/odoo/odoo/blob/d7d0efd39a65bfb6fee307b661cd2523a6b8231d/addons/account/models/account_move_line_tax_details.py#L100
matches every base line of a tax with every tax line of that tax inside the
same move. With two pairs sharing one tax that turns two rows into four, and
SUM(base_amount) doubles. The Tax column does not double because the same SQL
redistributes each tax line's recorded amount across its matched rows so the
totals still add back to the original tax.

The payment register flow does not have this problem because it calls
_get_invoice_counterpart_amls_for_early_payment_discount once with every
invoice, and that helper already collapses duplicates with the merge key at
https://github.com/odoo/odoo/blob/f3b317310b84edb073009f7d15d7fec002f3ccf0/addons/account/models/account_move.py#L5082-L5093

opw-6199906

Forward-Port-Of: odoo/enterprise#122747
Forward-Port-Of: odoo/enterprise#117743

`_l10n_tr_nilvera_add_pdf_to_invoice` writes the response from `client.request('GET', '.../pdf')` directly into `ir.attachment.raw`. The Nilvera client sets `Accept: application/json` on the session and calls `response.json()` by default, so the returned value is a Python `str` holding the base64-encoded PDF body, not raw binary bytes.

The previous code wrote to the base64-aware `datas` field, which auto-decoded its input. An earlier fix switched to `raw` to work around a `binascii.Error` from Python 3.14's stricter base64 validation in the `datas` auto-decode path. That switch silently changed what ends up on disk (`datas` decodes its input, `raw` does not)

Storing that string in the binary `raw` field encodes it as UTF-8, so the file on disk ends up as the literal ASCII of the base64 text. The attachment is served as `application/pdf` but the browser receives base64 ASCII and cannot preview or download the PDF.

Call `b64decode(response)` before storing so the attachment contains the actual PDF bytes.

OPW-6302803

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

**Steps to reproduce:**

- Make a quotation with 2 products
- Product A with a unit price of 5503.26 with 15% taxes
- Product B with a unit price of 4058.04 with 15% taxes
- Order 7 of A and 2 of B, the total is 53634.73
- Go to the pos, make a downpayment for 100% of the price
- The total is 53634.74, which is one cent more than it should

**Why the fix:**

When importing this order, we calculate the price again, to do it we compute the price unit and the taxes for it, then we will multiply it by the qty and add it all to a downpayment line and add it to the order.
When we have multiple qty like this, we run the risk of having a rounding issue, as the price unit is rounded before being multiplied by the tax and the quantity of said line.

Unfortunately in this exemple, we either have a price without the taxes of 46638.89 which gives a total of 53634.72 once multiplied or we have 46638.90 which gives a total of 53634.74
So with a decimal of 2 there is no way we could have the right amount with only one line, which is why we split it in 2 lines to get more precision when importing the sale order.

The way it worked before this commit is to take the sum of all lines and to calculate the downpayment based on it. We now split it into multiple smaller lines to avoid rounding issues because that's how it's done on the Sale Order in the backend. By splitting the down payment into multiple lines we replicate the per-line rounding behavior, preventing 1-cent discrepancies.

This is fixed in 18.3 onwards by using the accounting helper functions, but they are not yet implemented in 18.0 and it will be too big of a change for 18.0 so this solution is suggested.

opw-6222937