`_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#276666
Forward-Port-Of: odoo/odoo#270759

### Overview

The SMS Queue Manager cron throws a traceback in a multi company environment when processing sms's that belong to distinct companies.

### Changes

Before this commit, the _process_queue method tied to the cron was blindly batching sms's belonging to multiple companies without an sms_api context. The error results because the _send method that's called expects a singleton company when it tries to set the sms_api for the record set, but this isn't the case when the selected sms batch is multi company.

After this commit, the _process_queue method now follows the same pattern as the send method, grouping by sms_api / company within the batch, and eliminating the need to check for singleton, as all calls to _send will now have the sms_api context passed in.

### Steps to Reproduce on fresh 19.0 db:
1. Make sure sms / sms_twilio are installed.
2. Create two companies with their own SMS config.
3. Create two sms records, one with each company.
4. Ensure the state of the sms's is 'outgoing'.
5. Execute the SMS Queue Manager Cron. Observe the traceback: ValueError: Expected singleton...

opw-6371272

Forward-Port-Of: odoo/odoo#276426

When the pos_discount module is installed while a session is open (the typical case: the user enables "Global Discounts" in the PoS settings while the PoS is running), `_default_discount_value_on_module_install` skipped the configs having a non-closed session (or any rescue session, even a closed one). Those configs ended up with the Global Discount feature enabled but no `discount_product_id`, and opening the PoS then raised "A discount product is needed to use the Global Discount feature." with no way to recover other than manually re-saving the PoS settings.

The skip was introduced in 13.0 by 4c4adf472453 because, at the time, `pos.config.write()` refused any modification while a session was open, which made the module installation crash. That blanket restriction has since been narrowed to a few specific fields (`module_pos_restaurant`, `payment_method_ids`, `active`), so writing `discount_product_id` on a config with an open session is now perfectly valid.

Remove the obsolete exclusion so that all configs get the default discount product at install time, regardless of their session state.

opw-6385274

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

**Steps to reproduce:**
- Install Contacts app
- Open any record
- Go to the chatter
- Create an activity with a description
- Duplicate the tab
- Go back to the initial tab
- Description doesn't appear anymore
- Refreshing shows it but will remove it from the other tab

**Issue:**
Behavior comes from the broadcasting of activity changes between tabs `new browser.BroadcastChannel("mail.activity.channel");`.

Computed fields are not recomputed on the receiver side after value insertion in `_onActivityBroadcastChannelMessage` (also related components are not (re)mounted, e.g. when a new activity is created the other tab doesn't show it without a refresh).

This means that `isNoteEmpty` keeps its default value `true` (added by `this.toData()`) and the `note` stays hidden here [1]:
```xml
<div t-if="!props.activity.isNoteEmpty" class="o-mail-Activity-note text-break" t-out="props.activity.note"/>
```

**Fix:**
Remove computed fields in activity `serialize` before broadcasting them to ensure they don't force the default value.

(note installing `calendar` in 19.3+ removes this issue due to [2] which overrides the condition on `isNoteEmpty`)

[1] https://github.com/odoo/odoo/commit/eb9f0658c3da1a9fef69f1cc1117c2d44f9d61b1
[2] https://github.com/odoo/odoo/commit/44e2c2c5ca07849fd8964140f3ca61122c47f0c6

opw-6247412

Forward-Port-Of: odoo/odoo#276032
Forward-Port-Of: odoo/odoo#275528

When a push subscription is renewed by the browser (typically every few days), the pushsubscriptionchange event fires and the service worker attempts to re-register the new subscription endpoint via register_devices(). However, the VAPID public key was missing from the request kwargs.

The server-side register_devices() always validates the VAPID key first and raises InvalidVapidError when it is absent. This caused the renewed subscription to never be saved in the database, silently breaking push notifications after the first subscription renewal.

Fix by extracting the applicationServerKey from the new subscription's options and encoding it as a base64url string (without padding) — matching the existing logic in webclient.js _arrayBufferToBase64().

Description of the issue/feature this PR addresses:

Current behavior before PR: Subscriptions don't get renewed causing push notifications to stop eventually.

Desired behavior after PR is merged: Subscriptions get renewed successfully.


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

Forward-Port-Of: odoo/odoo#276085
Forward-Port-Of: odoo/odoo#275217

**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#276158
Forward-Port-Of: odoo/odoo#266700

### Overview

The SMS Queue Manager cron throws a traceback in a multi company environment when processing sms's that belong to distinct companies.

### Changes

Before this commit, the _process_queue method tied to the cron was blindly batching sms's belonging to multiple companies without an sms_api context. The error results because the _send method that's called expects a singleton company when it tries to set the sms_api for the record set, but this isn't the case when the selected sms batch is multi company.

After this commit, the _process_queue method now follows the same pattern as the send method, grouping by sms_api / company within the batch, and eliminating the need to check for singleton, as all calls to _send will now have the sms_api context passed in.

### Steps to Reproduce on fresh 19.0 db:
1. Make sure sms / sms_twilio are installed.
2. Create two companies with their own SMS config.
3. Create two sms records, one with each company.
4. Ensure the state of the sms's is 'outgoing'.
5. Execute the SMS Queue Manager Cron. Observe the traceback: ValueError: Expected singleton...

opw-6371272

Forward-Port-Of: odoo/odoo#276426

In multicompany, it can happen that one company (let's call it company Origin) cannot handle a payment method in their country, so it uses another company's (company MoneyHandler), even if it's in another country. The accounting flows must be then adjusted:

- In company Origin, the invoice must be matched by a clearing entry
- In company MoneyHandler, payment must match its move (if it exists) with a clearing entry. The payment move doesn't exist if `account_accountant` is installed but no Outstanding account is configured on the payment method line.

Same but opposite thing must happen for credit notes in company Origin that match a reimbursement in company MoneyHandler.

Cancellation of a payment must be reflected on the entries: deleting when feasible, reversing when not (unless a lock date/hash is present, which would block the cancellation)

_(To do: testing/review, credit note, cancellation/reversal of the payment)_

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

Forward-Port-Of: odoo/odoo#259197

### Steps to reproduce:

- In the settings enable Multi-Steps route
- Unarchive the MTO route and set its production rule in MTSO
- Create 3 products: P1, P2 and COMP all using the MTO route
- Create 2 BOM's, one for P1 and one for P2: 1 X COMP
- Put 2 units of COMP in stock and add an empty bom (to trigger a child MO creation in case the MTSO route is triggered)
- Create and confirm a sale order for: 1 x P1 and 1 X P2
#### > An MO was generated for both product but P2 also generated a child MO for 1 unit of COMP instead of using the available unit

Cause of the issue:

The issue happens in the `_prepare_procurement_qty` which incorrectly assess that 1 unit of COMP will be required. The issue has been introduced by commit https://github.com/odoo/odoo/commit/e30fb722c00805e7226d2ee9e3e587b3c2204840 which introduced a dictionary to keep track of units of  products that will be used by the confirmation process of other concurrent mtso moves: https://github.com/odoo/odoo/blob/71f0715bd5e29e976a1e8bfa7c4fa6e04735ebd7/addons/stock/models/stock_move.py#L1683-L1689 https://github.com/odoo/odoo/blob/71f0715bd5e29e976a1e8bfa7c4fa6e04735ebd7/addons/stock/models/stock_move.py#L1712-L1715 https://github.com/odoo/odoo/blob/71f0715bd5e29e976a1e8bfa7c4fa6e04735ebd7/addons/stock/models/stock_move.py#L1810-L1814 
While by design this propagates the information used by other mtso moves in a common `_action_confirm` stack, the issue that we encounter is that this quantity is only relevant to be substracted to the free_qty when the unit is not yet reserved and hence already accounted negatively in `free_qty`. However, in the present case, confirming the receipt of P1 and P2 will confirm both moves simultaneously, triggering a common `_run_manufacture` to generate both an MO for P1 and for P2. At this point the dictionary `consumed_from_stock_dict` is shared in both MO's confirmation but since the MO's are confirmed sequentially rather than in batch:
https://github.com/odoo/odoo/blob/71f0715bd5e29e976a1e8bfa7c4fa6e04735ebd7/addons/mrp/models/stock_rule.py#L122-L125
The confirmation of the MO of P1 will update the `consumed_from_stock_dict` for 1 unit of COMP and will also reserve 1 unit of COMP before the MO of P2 is confirmed (and calls the `_prepare_procurement_qty`) to determine how many units of COMP are till available. This leads to the incorrect conclusion that 1 - 1 = 0 units are still available to fulfill the demand of P2.

opw-6370298

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

Forward-Port-Of: odoo/odoo#275539

### Overview

The SMS Queue Manager cron throws a traceback in a multi company environment when processing sms's that belong to distinct companies.

### Changes

Before this commit, the _process_queue method tied to the cron was blindly batching sms's belonging to multiple companies without an sms_api context. The error results because the _send method that's called expects a singleton company when it tries to set the sms_api for the record set, but this isn't the case when the selected sms batch is multi company.

After this commit, the _process_queue method now follows the same pattern as the send method, grouping by sms_api / company within the batch, and eliminating the need to check for singleton, as all calls to _send will now have the sms_api context passed in.

### Steps to Reproduce on fresh 19.0 db:
1. Make sure sms / sms_twilio are installed.
2. Create two companies with their own SMS config.
3. Create two sms records, one with each company.
4. Ensure the state of the sms's is 'outgoing'.
5. Execute the SMS Queue Manager Cron. Observe the traceback: ValueError: Expected singleton...

opw-6371272

Forward-Port-Of: odoo/odoo#276426

The partner credit limit warning on quotations and customer invoices depends on which company the user is currently working in, instead of the company of the document itself.

Steps to reproduce:
- Enable Sale Credit Limit in the settings of My Company (San Francisco)
- Set a Credit Limit of 100 on a customer, e.g. Deco Addict
- Create a draft quotation of 500 for that customer => The credit limit warning banner is displayed, as expected
- Switch the active company to any other company, for example My Company (Chicago), keeping access to both companies
- Open the same quotation again => The warning banner is gone, although neither the quotation nor the
   customer changed

The credit fields used to build the warning are evaluated against the user's active company: credit_limit is a company-dependent field, and credit / credit_to_invoice are computed on the receivables of the current company. When the active company is not the document's company, the warning is checked against the wrong ledger and the wrong limit, so it can disappear on an over-limit customer or show up for a healthy one.

Both computes already contain the line that was meant to handle this, but the result of with_company() was discarded, making it a no-op. Assign it, as every other compute in these files already does, so the warning is always evaluated in the document's company.

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

Forward-Port-Of: odoo/odoo#276308

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#276430
Forward-Port-Of: odoo/odoo#273129

**Purpose of this PR:**

Before this PR, the Voice detection sensitivity indicator in call settings could get stuck showing the last detected level after clicking "Stop" right after "Test". The `AudioWorkletNode`'s port kept receiving tic messages briefly after `disconnect()`, since disconnecting only unroutes the audio graph and does not stop the worklet from posting pending messages.

<img width="546" height="73" alt="voice_test_bug" src="https://github.com/user-attachments/assets/05a10d23-fe60-4a85-b906-bfec6d235ec5" />

Steps to reproduce:

1. Open Voice & Video Settings.
2. Start the Voice detection sensitivity test.
3. Quickly click Stop immediately after clicking Test.
4. It may take a few tries, but eventually the Voice detection sensitivity indicator remains stuck at the last detected level.

> [!NOTE]
>  this is timing-dependent. A tic message must already be in-flight from the worklet thread when `disconnect()` runs, so it won't happen every attempt.

This race condition existed in the `disconnect` callback of `_loadAudioWorkletProcessor` since #66611, but stayed silent until #183969 introduced the Voice detection sensitivity feature in call settings, exposing it.

This PR clears `port.onmessage` before disconnecting so late tic messages can no longer update the Voice detection sensitivity indicator after monitoring has stopped.

Forward-Port-Of: odoo/odoo#275933

Steps to reproduce:
- Create a partner without pincode
- Create a picking and Challan for that partner
- Click print

Will result in the following traceback-
```py
Traceback (most recent call last):
  File "<1103>", line 710, in template_l10n_in_ewaybill_report_ewaybill_1103
  File "<1103>", line 692, in template_l10n_in_ewaybill_report_ewaybill_1103_content
  File "<1103>", line 674, in template_l10n_in_ewaybill_report_ewaybill_1103_t_call_0
  File "<1103>", line 86, in template_l10n_in_ewaybill_report_ewaybill_1103_t_call_1
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 727, in _ewaybill_generate_direct_json
    **self._prepare_ewaybill_base_json_payload(),
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill_stock/models/l10n_in_ewaybill.py", line 289, in _prepare_ewaybill_base_json_payload
    ewaybill_json = super()._prepare_ewaybill_base_json_payload()
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 669, in _prepare_ewaybill_base_json_payload
    **prepare_details(
      ^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 641, in prepare_details
    f"{place}{key}": fun(partner, place) if key == "StateCode" else fun(partner)
                                                                    ^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 674, in <lambda>
    "Pincode": lambda p: int(p.zip) if p.country_id.code == "IN" else 999999,
                         ^^^^^^^^^^
ValueError: invalid literal for int() with base 10: ''
```
In this commit, we resolve the traceback


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

Steps to reproduce:
==================
1. Add a Donation snippet on a page
2. Click "Donate Now"
3. Switch the website language on the payment page

=> Configured amounts/descriptions disappear

Cause:
======
The donation snippet posts its configuration (prefilled amounts, display options, descriptions) in the request body. If the user switches the website language on the payment page, it triggers a page reload via a GET request which drops the original form body (this also applies to a simple page refresh). As a result, the kwargs were empty and the page fell back to the default free-amount input, losing the configured options.

Solution:
=========
Implement Post/Redirect/Get: on POST, redirect to /donation/pay with the options in the query string so any later GET (language switch, refresh, iframe src reload) re-renders a fully configured page without losing data.

Alternative Solution:
=====================
We could also store the options in the session, but the current solution is much simpler and avoids session pollution.

opw-6282391

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

### [FIX] web: fix mocked dates in tests

Dates are mocked in all unit tests by default; either to a default static
value, or to one defined in the test/suite. To do so, the `window.Date`
constructor is overridden to have the arguments auto-filled with the current
mock date paramters.

Before this commit, an additional offset was always added to the given
arguments to reflect:
- the time elapsed from the beginning of the test;
- any virtual offset added by a helper such as 'advanceTime'.

The issue is that the spec of the Date constructor wants that the returned date
object has to match all given arguments, and any omitted argument will be
defaulted to the current date/time. This was not the case in tests, as the
offset was always added, regardless of the given arguments.

With this commit: only the arguments that are NOT given and that have been
defaulted to current (mocked) date/time will be offset by the adequate value.
Furthermore: as these mocked parameters are meant to reflect UTC values, the
offset now also considers the *actual* browser offset to generate a local date
from the mock date parameters.

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

**Steps to reproduce:**
1. Create a Sales Order.
2. Create a 50% down payment invoice.
3. Create a credit note for the down payment invoice.
4. Reset the credit note to Draft and cancel it.
5. Create the final invoice from the Sales Order.

**Issue:**
The final invoice is generated for 100% of the order amount, acting as if the down payment invoice does not exist.

**Expected behavior:**
The final invoice should only include the remaining 50% of the order amount because a valid 50% down payment invoice still exists.

**Why this happens:**
- The `price_unit` on the Sales Order's down payment line is manually updated during `action_post()` based on the sum of posted invoices minus posted credit notes.
- When the credit note is posted, `price_unit` drops to 0. However, when that credit note is subsequently reset to draft and cancelled, it triggers `button_cancel()` which only refreshed the line's display name and failed to recalculate `price_unit`. As a result, `price_unit` remained at 0 even though the credit note was no longer active, causing the final invoice to deduct nothing.

opw-6373578

The partner credit limit warning on quotations and customer invoices depends on which company the user is currently working in, instead of the company of the document itself.

Steps to reproduce:
- Enable Sale Credit Limit in the settings of My Company (San Francisco)
- Set a Credit Limit of 100 on a customer, e.g. Deco Addict
- Create a draft quotation of 500 for that customer => The credit limit warning banner is displayed, as expected
- Switch the active company to any other company, for example My Company (Chicago), keeping access to both companies
- Open the same quotation again => The warning banner is gone, although neither the quotation nor the
   customer changed

The credit fields used to build the warning are evaluated against the user's active company: credit_limit is a company-dependent field, and credit / credit_to_invoice are computed on the receivables of the current company. When the active company is not the document's company, the warning is checked against the wrong ledger and the wrong limit, so it can disappear on an over-limit customer or show up for a healthy one.

Both computes already contain the line that was meant to handle this, but the result of with_company() was discarded, making it a no-op. Assign it, as every other compute in these files already does, so the warning is always evaluated in the document's company.

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

Forward-Port-Of: odoo/odoo#276308