**Steps to reproduce:**
1. Go to Website > Edit a page.
2. Add multiple Badges side by side.
3. Save the page.
4. Switch the website language, click on Edit/Translate and
translate the badges.
5. Save.

**Issue:**
After saving in translate mode, all badge elements are merged into
one.

**Why this happens:**
During save, `cleanForSave` triggers `mergeAdjacentInlines` on a
detached clone of the dirty element. This clone lacks all the css
styling, so `getComputedStyle` returns `""` for all padding/margin
on detached nodes. Consequently, `areSimilarElements` incorrectly
considers sibling `s_badge` spans as identical and merges them.

A recent fix (https://github.com/odoo/odoo/commit/91972ec2bbd85f9cfd7a1af794bbb2385a312f30) applied to `BadgeOptionPlugin` registers
`s_badge` as unsplittable via `unsplittable_node_predicates`,
preventing the merge in normal edit mode. However, translate mode
loads a separate plugin, `BadgeTranslationPlugin`, which was added
in the commit https://github.com/odoo/odoo/commit/cbb2eb2edfeecbc21a70c1a3cba81ad0a7ac9c75 that lacks the same predicate.

opw-6261146

Forward-Port-Of: odoo/odoo#276040
Forward-Port-Of: odoo/odoo#273986

**Steps to reproduce:**
1. Go to Website > Edit a page.
2. Add multiple Badges side by side.
3. Save the page.
4. Switch the website language, click on Edit/Translate and
translate the badges.
5. Save.

**Issue:**
After saving in translate mode, all badge elements are merged into
one.

**Why this happens:**
During save, `cleanForSave` triggers `mergeAdjacentInlines` on a
detached clone of the dirty element. This clone lacks all the css
styling, so `getComputedStyle` returns `""` for all padding/margin
on detached nodes. Consequently, `areSimilarElements` incorrectly
considers sibling `s_badge` spans as identical and merges them.

A recent fix (https://github.com/odoo/odoo/commit/91972ec2bbd85f9cfd7a1af794bbb2385a312f30) applied to `BadgeOptionPlugin` registers
`s_badge` as unsplittable via `unsplittable_node_predicates`,
preventing the merge in normal edit mode. However, translate mode
loads a separate plugin, `BadgeTranslationPlugin`, which was added
in the commit https://github.com/odoo/odoo/commit/cbb2eb2edfeecbc21a70c1a3cba81ad0a7ac9c75 that lacks the same predicate.

opw-6261146

Forward-Port-Of: odoo/odoo#276040
Forward-Port-Of: odoo/odoo#273986

The "bus subscription is refreshed when channel is joined/left" tests were flaky:
- `mockDate` needs 2 digit date/time parts. The format used here didn't always produce them, so it silently fell back to a past date. That was enough to make the "left" test pass even without actually leaving.
- The "left" test never actually left the channel: a confirm dialog blocked it.
- The "join" test never actually joined the channel.
- The tests expected `runAllTimers` to guarantee that every initial subscription was done, but thats not the case, making the number of `subscribe` calls non-deterministic (e.g. flushing calls to `bus_service.add` but not ensuring the worker received them through its message port, and triggered the debounced `updateChannels`).

Fixing the tests exposed a real bug: `memberBusSubscription` is meant to trigger a refresh whenever membership changes relative to the bus start time. As a boolean, "member, no refresh needed" and "not a member" are indistinguishable (both `false`), so leaving a channel joined before the bus started never changed the value and never triggered a refresh.

This PR add a third state so membership and non-membership stay distinguishable regardless of when the bus started.

runbot-941462

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#276066
Forward-Port-Of: odoo/odoo#275938

# How to reproduce
- In Settings, enable Variants & Product Reference Price
- Create a published Product with a Sales Price
- Add 2 variants to the Product
- In the product's variant list, select the first one & set Base Unit Count to 0,
- Set the second variant's Base Unit Count to a value > 0
- Go to the Product's page
- Select the second variant

# The issue
The Reference Price is not displayed for the second variant, even though it should since it has a Base Unit Count > 0. Refreshing the page while being on the second variant will prevent the bug from happening.

# Cause
When loading the product's info, we call `_onChangeCombination`. This method is responsible for, among other things, updating the reference price and hiding it if Base Unit Count  = 0 :
https://github.com/odoo/odoo/blob/68f258e99f42693131a5309b3606c3b95f93d824/addons/website_sale/static/src/js/variant_mixin.js#L277-L289

To do that, it will search for an html element with the `.o_base_unit_price` css class. If it does not find it, the reference price will not be updated. The issue is that this element is behind a condition in the template :
https://github.com/odoo/odoo/blob/68f258e99f42693131a5309b3606c3b95f93d824/addons/website_sale/views/templates.xml#L2083

When the first time the template is loaded, if
`combination_info.get('base_unit_price')` is False, then the Reference Price will never be added to the view and will never be found by `_onChangeCombination`.

Since our first variant has Base Unit Count = 0, then `base_unit_price` will equal 0, so `combination_info.get('base_unit_price')` will be evaluated to false.

opw-6367289

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

Forward-Port-Of: odoo/odoo#275699
Forward-Port-Of: odoo/odoo#274722

**Steps to reproduce:**

- Make a product with a category
- In the category, make the inventory valuation to automated
- Set the income and expense account
- Set a cost for the product
- Make a fiscal position and set it as default for the PoS
- In the Account Mapping tab, map the income and expense to two other accounts
- Go to the PoS
- Make a sale for that product, without invoice
- Close the session and in the backend check the session
- Check the journal entries
- The income account has been mapped to the fiscal position's
- The outcome account stayed the same as in the category's

**Why the fix:**

When we invoice an order, the income and expense accounts are immediately updated, in a different place than if it has not been invoiced.

At the session's closure, we update the accounts for every order that hasn't been invoiced. In this flow, the account mapping defined on the fiscal position was not applied, so we took the one defined on the product's category.
The income account was already mapped as we need to do it earlier than the session closure, so it had already been set as the right one before our flow. For the expense account, we only need it at this specific time, so we can map it as the session's closure.

We now map the account depending on the fiscal position if we are able to find one, otherwise, we use the category's default as we did before.

opw-6171677

Forward-Port-Of: odoo/odoo#275114
Forward-Port-Of: odoo/odoo#266700

…nding

When cash rounding is enabled with "Only for cash payment methods", an order partially paid in cash and completed with an online payment could neither request the correct online amount nor be marked as paid.

Steps to reproduce:
- Enable cash rounding (e.g. 0.05, HALF-UP) with "Only for cash payment methods"
- Create an order with a total of 15.28
- Add a cash payment of 10.00, then an online payment for the remainder

The frontend requests 5.28 for the online payment, but as soon as the order contained a cash payment the server rounded the whole order total: get_and_set_online_payments_data() returned an unpaid amount of 5.30 (15.30 - 10.00), so the validation failed with "Invalid online payments".

Even once the online payment of 5.28 was processed, the order remained stuck in draft with the money captured: _is_pos_order_paid() compared the paid amount (15.28) against the rounded total (15.30).

Only the part of the order actually settled in cash must be rounded: non-cash payments (card, online, ...) always pay their exact share.

- get_amount_unpaid() now returns the exact residual of the order when the rounding only applies to cash payment methods.
- _get_rounded_amount() now only rounds the amount not covered by non-cash payments, resolving its old TODO. Cash-only orders and orders where the cash payment settles the rounded remainder are unaffected.

opw-6314690

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

Forward-Port-Of: odoo/odoo#275305

Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal.

Solution: Extract the basis_qty logic into a helper method so
other localizations can override when needed.

Current behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets incorrectly divided, resulting in negative discounts on the vendor bill.

Expected Behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets parses as the exact unit price with no negative discounts applied.

Task [link](https://www.odoo.com/odoo/project.task/6215466)
task-6215466

Forward-Port-Of: odoo/odoo#273129

Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal.

Solution: Extract the basis_qty logic into a helper method so
other localizations can override when needed.

Current behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets incorrectly divided, resulting in negative discounts on the vendor bill.

Expected Behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets parses as the exact unit price with no negative discounts applied.

Task [link](https://www.odoo.com/odoo/project.task/6215466)
task-6215466

Translatable rows that are identified by a stable key rather than by
their text (e.g. selection option labels in ir.model.fields.selection,
and other module-reflected metadata written through upsert_en()) can
have their English source text changed by a module upgrade while
keeping the same key. For example product.template's selection value
'consu' went from meaning "Consumable" to meaning "Goods" between 17.0
and 18.0, without the stored value itself changing.

In that situation, upsert_en() always refreshes the 'en_US' entry from
the current code, so English is never wrong. But every other language
keeps whatever value it had, since upsert_en() blindly merges the new
'en_US' entry into the existing jsonb without checking whether the
previous 'en_US' value actually changed. When the module's .po file is
later reloaded, TranslationImporter.save() finds a non-empty value
already there for each language and, by design, does not overwrite it
unless explicitly asked to (`overwrite`) on a record that isn't
`noupdate`. That protection is correct when the English text hasn't
changed (it keeps manual translation customizations across upgrades),
but here it ends up protecting a translation of a source string that
no longer exists.

As a result, a value whose meaning changes across versions keeps
showing its old label in every language except English, forever,
unless someone forces a translation overwrite.

Fix this in upsert_en() itself: when the incoming 'en_US' value
differs from the one currently stored, drop every other language
already stored for that row instead of merging into it. Those
translations were made for a source string that no longer exists, so
there is nothing worth protecting. Once dropped, they are simply
missing from the jsonb, so TranslationImporter.save() naturally lets
the freshly (re)loaded translations in on its next run, without needing
to know anything about source drift, and `overwrite`/`noupdate` keep
their exact original meaning for every other case.

Task-6333080


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