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

Cached functions with `@ormcache` should not return immutable values, yet `_get_parameter_from_code()` could return dicts/sets/lists/etc.

It could lead to very obscure bugs such as:

```python
def some_innocent_code():
    category_dict = self.env["hr.rule.parameter"]._get_parameter_from_code('l10n_be_work_entry_categories')
    incapacity_codes = category_dict['partial_incapacity']
    incapacity_codes |= category_dict['total_incapacity']
    # ... then use incapacity_codes

def print_rule_param():
    print(self.env["hr.rule.parameter"]._get_parameter_from_code('l10n_be_work_entry_categories')['partial_incapacity'])

print_rule_param()  # OrderedSet(['LEAVE281'])
some_innocent_code()
print_rule_param()  # OrderedSet(['LEAVE281', 'LEAVE264', 'LEAVE266', 'LEAVE217', 'LEAVE218', 'LEAVE219', 'MEDIC01'])
```

The solution was to either deepcopy the returned value each time, or to change all the rule parameters to their frozen equivalent. Since we don't have access to frozen objects in rule parameters's xml definitions, we opted for the deepcopy approach.

task-6329380

Forward-Port-Of: odoo/enterprise#124141
Forward-Port-Of: odoo/enterprise#123057

Issue:
----------------------------------------
There is a fiscal regime where the company is actually an individual but is authorized to generate documents.

Steps to reproduce:
----------------------------------------
- Install "l10n_mx_hr_payroll_account_edi"
- Change the current company fiscal regime to '621'
- Add an VAT of length 13 to the current company
- Add a CURP number on the current company
- In Payroll generate a payslip, validate it
- Post the Journal entry
- On the payslip, click "Generate CFDI"
- An error is returned, saying the Emisor:Curp applies to individuals

Cause:
----------------------------------------
An RFC of length 13 means that the sender is an individual. It's intended with the fiscal regime '621'.

We add the curp number in the CFDI XML only when `self.company_id.partner_id.is_company` is `False`. Since saas-19.1, `is_company` is computed to be truely if a VAT is present. So as soon as the VAT is entered, the CURP number is absent from the XML.

Solution:
----------------------------------------
We change the condition to add the CURP number in the XML: A VAT number of length 13 means the contact is an individual (12 for companies). This is what is used to validate the XML: if the vat is of length 13, then the curp number should be present.

opw-6351558

Currently, users encounter a traceback when clicking the "Load a Template" button in the WYSIWYG article helper if the article is linked to an audit report and has no parent article.

Steps to reproduce:
1. Install `accountant_knowledge`.
2. Create and open a new audit report.
3. Delete all content from article (the root).
4. Click the "Load a Template" button in the helper.

=> Crash with `AssertionError: Invalid falsy real id.`

The issue occurs because the method responsible for loading the annex to display (see: `get_suggested_templates`) expects at least one record in the recordset. When the article has no parent, the recordset is empty, causing the method to fail.

Before attempting to load a template, we will check whether the article has a parent article. If no parent exists, no template will be provided to the template picker. In that case, the picker will display a helper message indicating that no article template is available to load.

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

## Steps to reproduce:

1. Install `l10n_br`, `l10n_br_avatax`, and `l10n_br_edi_fiscal_reform`.
2. Ensure that Demo mode is activated if not on Runbot.
3. Navigate to Contacts, then click into "BR Company Customer Estimated Profit".
4. Duplicate this contact, then set the following fields:
   1. Tax Regime set to individual
   2. ICMS Taxpayer Type set to Non-Taxpayer
5. Swtich to the BR Company and go to Accounting / Configuration / Settings.
6. Set up a Sandbox Avalara account and enable logging payload responses.
7. Navigate to Accounting > Customers > Invoices.
8. Create an invoice with:
   1. Customer set to the copy created earlier.
   2. Operation Type set to Sale of Goods
   3. Document Type set to 55
   4. Payment Method Brazil set to Money
   5. Presence set to Present
   6. One sales order line with:
      1. Regular Consumable Product
      2. quantity set to 1
      3. price set to 100.0
9. Confirm the invoice.
10. Navigate back to Accounting > Configuration > Settings to view the response from Avalara. The customer will have the CFOP 6102 instead of CFOP 6108.

Explanation:

PR #97845 introduced `_l10n_br_deep_clean_dict()` to remove falsy values and empty dictionaries from the payload we send to Avalara. This fix was applied as broadly as possible to prevent excessive if statements.

However, if the falsy values in taxSettings of the customer are not communicated, Avalara will assign the customer to an incorrect CFOP.

opw-6085964

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-6215466

Forward-Port-Of: odoo/enterprise#124400
Forward-Port-Of: odoo/enterprise#122313

## Context

When generating a CFE (Comprobante Fiscal Electrónico) that contains both a configured addenda (e.g. bank account details stored in `l10n_uy_edi_addenda_ids`) and terms & conditions from the invoice's `narration` field, the resulting addenda string could end up with unnecessary blank lines between the two sections, causing the addenda to be rendered on a separate page even when the logical content fits within the 6-line threshold.

## Root Cause

`_l10n_uy_edi_get_addenda` joins both parts without stripping whitespace from either of them first, and adds two lines between addendas and terms and conditions:

         addenda = addenda + "\n\n" + term_and_conditions if addenda else term_and_conditions

Two sources independently introduce extra newlines around the separator:

1. **Addenda content** — `_get_legends` returns the raw `content`  field value of each addenda record. These fields commonly end  with a trailing `\n`, so the addenda string already ends with a newline before the `"\n"` separator is concatenated.
2. **`html2plaintext`** — the `narration` field is stored as HTML. When converted to plain text, `html2plaintext` typically wraps paragraph content in leading/trailing newlines.

The combination of the trailing `\n` from the addenda, the explicit `"\n\n"` separator, and the leading/trailing `\n` from `html2plaintext` produces 2–3 consecutive newlines, which `splitlines()` counts as blank lines. 
A realistic 4-line addenda + 1-line narration thus produces **7 lines** instead of the expected 5, crossing the 6-line threshold in `_get_report_params` and triggering `adenda=true` — which forces the addenda onto a separate page unnecessarily.

## Steps to Reproduce

1. Configure a `l10n_uy_edi.addenda` record of type `addenda` with multi-line content (4 lines)
2. Create and confirm an invoice with `narration` set to a short  single-line term 
3. Generate the CFE PDF via Uruware.
4. Observe that the addenda is rendered on a separate page despite the logical content being only 5 lines.

<img width="1042" height="448" alt="image" src="https://github.com/user-attachments/assets/b538211c-5f37-4648-979d-99cd75cf31c2" />


## Fix

Strip leading and trailing whitespace (including newlines) from both parts before joining them. The ternary is also replaced with an explicit `if/else` for clarity:

    def _l10n_uy_edi_get_addenda(self):
        addenda = self.l10n_uy_edi_document_id._get_legends("addenda", self)
        if self.narration:
            term_and_conditions = html2plaintext(self.narration).strip()
            if addenda:
                addenda = addenda.strip() + "\n" + term_and_conditions
            else:
                addenda = term_and_conditions
        return self._l10n_uy_edi_clean_non_ascii_chars(addenda)

This guarantees exactly one `\n` separator between sections regardless of how the content fields were stored or how `html2plaintext` formatted the narration.

The threshold logic in `_get_report_params` is unchanged: addendas that genuinely exceed 6 lines (after wrapping at 140 chars) continue to be printed on a dedicated page.

Result
<img width="1117" height="456" alt="image" src="https://github.com/user-attachments/assets/3a2d942c-8c37-40f6-bc25-470c0bd25b08" />

Forward-Port-Of: odoo/enterprise#119283

Steps to reproduce:
- Go to Website
- Upload an image in the company logo (navbar)
- Open the website editor and click on the logo
- Open the image info panel

Current behavior:

When clicking on the website logo in the editor, the size shown is always a constant number ~5.9kB, regardless of the actual size of the uploaded logo. The correct size is visible in the browser DOM. This gives users the wrong impression that their image is being heavily compressed or losing quality when it isn't.

Reason:

When clicking the logo, the editor tries to find the original, unprocessed version of the image so it can support cropping and other edits. It does this by asking the server to match the image's URL to a stored attachment.

The website logo is served through a dynamic link
(`/web/image/website/<id>/logo/<name>`) that isn't tied to a regular attachment record the way normal content images are, since it isn't uploaded through the usual media picker. Because of this, the server can't find a matching original, and the editor is left without a valid image source to work with.

As a fallback, the editor tries to load a placeholder path instead of a real image. This request fails and silently resolves to Odoo's generic "image not found" placeholder. All further processing (and the size calculation) then happens on this small placeholder image instead of the actual logo, which is why the size shown never changes.

Fix:

When `get_image_info` does not return a usable `original`, `loadImageInfo` now falls back to using the image's own current src as `originalSrc`, instead of leaving it unset. This ensures `loadImage` always receives a valid, resolvable URL, so image processing (and the size shown) reflects the actual logo.

opw-6260496

Forward-Port-Of: odoo/odoo#273542

CertificateAdapter presents a client certificate stored in the database instead of on disk when opening an HTTPS connection (used by the l10n_es EDI modules verifactu, sii and tbai). It loaded that certificate on the connection path of requests 2.31, but requests >= 2.32 changed that path (no longer calls get_connection()), so the step was skipped and the call crashed with: "TypeError: expected str, bytes or os.PathLike object, not certificate"

Odoo pins requests 2.31.0 (max depending on Python version), but online databases can use the version shipped by the OS (2.32.x on recent Ubuntu 26).

Set the certificate up when the adapter is created instead of on that connection call. That step runs the same on every requests version, so the fix works both before and after 2.32.

Steps to reproduce:
  - Spanish company with Veri*Factu and a certificate, on a server
  running requests >= 2.32 (saas-19.3 database for exemple on ubuntu 26)
  - Post a customer invoice and send it to Veri*Factu.
  => TypeError

Reference: https://github.com/psf/requests/blob/f361ead047be5cb873174218582f7d8b9fcd9f49/HISTORY.md?plain=1#L146

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

Forward-Port-Of: odoo/odoo#275324

### Steps to reproduce:

- Open the Todo app
- In the editor, insert the following content: `<p>a</p><div class="oe_unbreakable"><br></div><p>b</p>`
- Double-click the empty unbreakable node
- Open the color picker and hover over a color
- Toolbar and color picker get closed

### Root cause:

- Hovering a color in an empty unbreakable node replaces the `<br>` with a `<font data-oe-zws-empty-inline>` containing a ZWS (`\u200b`). This triggers a selectionchange where `isToolbarVisible()` finds no `<br>` and no visible text, returns false, and closes the toolbar — which reverts the preview, reopens the toolbar, and causes a flicker loop.

### Solution:

- Instead of calling `fillEmpty()` (which inserts a ZWS placeholder) on empty blocks containing `<br>` preserve the `<br>` element by appending it directly inside the `<font>` tag which keeps toolbar open.

task-6312933

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

Forward-Port-Of: odoo/odoo#271507

**PROBLEM**
`_cron_migrate_local_to_cloud_storage()` is used to migrate attachment to a cloud storage. It delete the attachment from the database, rendering it innacessible from the server-side. The problem is it can delete attachment used in business logic.

**STEP TO REPRODUCE**
1. Install and configure cloud_storage + a provider (e.g. cloud_storage_google) and cloud_storage_migration.
2. Install l10n_mx_edi and stamp a customer invoice. The CFDI XML is stored as an ir.attachment that:
  - is referenced by a business Many2one l10n_mx_edi.document.attachment_id (copied into account.move.l10n_mx_edi_cfdi_attachment_id),
  - has res_field = NULL (record attachment, not a field binary),
  - is posted to the chatter → it has a row in message_attachment_rel.
3. Add account.move to cloud_storage_migration_message_models and set a low enough cloud_storage_min_file_size.
4. Run the cron _cron_migrate_local_to_cloud_storage.
5. Open the invoice and trigger any recompute of the EDI chain (e.g. Update Payments, a reconciliation, or re-stamping).

**FIX**
Filters out attachment linked to a model listed by the already existing function `_get_cloud_storage_unsupported_models()`

opw-6347198

Forward-Port-Of: odoo/odoo#275945

Currently, if a discount program has a max discount, this value is not taken into account when computing the amount left to discount.

Steps to reproduce:
-------------------
* Create a loyalty program, it needs a reward as such: 100% discount on product A, maximum discount 100
* Create a discount code program, it needs a reward as such: 15% discount on product A
* Open pos, make an order, add product A, change its price to 1000
* In this order:
  * Add the loyalty program reward (100%)
  > Only 100$ discount since it's the max
  * Add the discount code reward
  > Nothing happens, no reward line added, no message saying the code didn't applied

Why the fix:
------------
When we compute the amount left to discount `getDiscountable` when we try to apply the last reward we have `discount = 1` as the loyalty reward line is set up to a 100% discount. This ends up leaving `remainingAmountPerLine[line.uuid]` to be 0.

The current state of the code does not take into account the maximum discount which, if triggered, means we still have something remaining to discount.

We introduce this discount in a straightforward way for the moment. We simply compare the theoretical discount `remainingAmountPerLine[line.uuid] * discount` to the max.

This is a simple version intended to make this work. In the future we could imagine taking all the lines the discount applies to and compute the proportion that is applied to the specific line. This approach was already discussed in the past for fixed amount discounts and was not implemented as it would make the code more complex (and unreadable) than needed. We're assuming the same approach applies here. We make it work first and see if there's ever a need to complexify it.

opw-6129625

Forward-Port-Of: odoo/odoo#262499

Version:
---------
- 19.0+

Steps to Reproduce:
-----------------------
1. Install sale_management, purchase, stock modules.
2. Create a storable product with Tracking: By Lot,
3. Create two Purchase Orders, each for 10 units.
   Receive PO-1 → 10 units with tagged as lot-1
   Receive PO-2 → 10 units with tagged as lot-2
4. Create two Sale Orders:
   SO-1 → deliver 2 units from lot-1 (validate)
   SO-2 → deliver 4 units from lot-2 (validate)
5. Open Inventory > Reporting > Stock,
   click "Total Value", then check the "Remaining Quantity" column

Issue:
-------
Observed : remaining_qty = 10 for lot-2 receipt, 4 for lot-1 receipt
Expected : remaining_qty = 8 for lot-1 receipt (10−2), 6 for lot-2 receipt (10−4)

Cause:
--------
When the "Remaining Quantity" column is computed, the following call
chain executes:

  stock.move._compute_remaining_qty()
    → calls product.product._get_remaining_moves()
        → calls product._run_fifo_get_stack()   ← HERE is the problem

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L372

`_get_remaining_moves` calls `_run_fifo_get_stack()` with NO lot
argument. Inside `_run_fifo_get_stack`, because no lot is given, it
computes the stack size from the TOTAL product qty across all lots:

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L583

  fifo_stack_size = 14   (10 received lot-1 + 10 received lot-2
                          − 2 delivered lot-1 − 4 delivered lot-2)

It then builds a domain to find incoming moves with NO lot filter:

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L607

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L614-L618

  ```Domain: [('is_in', '=', True), ('product_id', '=', X)]
  ↳ returns both receipts ordered:
      [lot-2 receipt (10 qty), lot-1 receipt (10 qty)]

then walks this list consuming `fifo_stack_size = 14`:
So it take: [move_lot1_receipt(10)]  First Lot

remaining_qty_on_first = min(10, 14) = 10 
after consuming fifo_stack_size →  14−10=4 left → move_lot1 gets 4
```
So back in `_get_remaining_moves`:

  qty_by_move = {
      lot-2 receipt → 10,   ← wrong (should be 6)
      lot-1 receipt →  4,   ← wrong (should be 8)
  }

- The root cause: `_run_fifo_get_stack` is designed for products that
have one shared FIFO stack. For lot-valuated products, each lot is an
independent inventory layer. Running a single combined stack mixes both
lots together, so the deductions (2 from lot-1, 4 from lot-2) are not
attributed to the correct receipt moves — the algorithm just consumes
from the oldest receipts first with no awareness of which lot was
actually delivered.

Fix:
-----
`_run_fifo_get_stack` already accepts a `lot=` argument that:
- sets `fifo_stack_size = lot.product_qty` (correct per-lot qty)
- adds `('move_line_ids.lot_id', 'in', lot.id)` to the domain
  so only the receipts that touched that specific lot are returned
The only missing piece was calling it per lot instead of once globally.

- With the fix, the stack for each lot is built correctly:
  lot-1: fifo_stack_size = 8 → lot-1 receipt remaining_qty = 8  ✓
  lot-2: fifo_stack_size = 6 → lot-2 receipt remaining_qty = 6  ✓

---

opw-6311341

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

Forward-Port-Of: odoo/odoo#272411

**Steps to reproduce:**
Both problem are reproducible on runbot aswell 
but for more clarity (and for empty accounting), 
those steps are on a fresh db with no demo data

Problem 1 : 
- create a new db with stock_account, purchase 
and accountant
- In the companies view, select your company
- in the branch tab, create a branch for your company
- for both the branch and the company, in the settings 
set the valuation as periodic daily

With only the branch company selected:
- create a warehouse for your branch
- create a storable prod with a cost of 10
- validate a receipt for 1 unit of the prod
- open inventory valuation view and check 
that there is variation lines for 10
- open 'scheduled actions' view
- select 'inventory valuation closing' 
- click on 'run manually'

With the main company selected: 
- Open journal items
- click on the journal entry of  any of the move line 
with label 'closing stock variation global for 
company [branch]'
- select the 'other info' tab


Problem 2: 
- create a new db with stock_account, purchase 
and accountant
- create a company 2 
- for both companies, in the settings 
set the valuation as periodic daily

With company 2 selected
- create a warehouse for company 2
- in the settings for fiscal localization set the 
'generic chart of account'
- create a storable product with a cost of 10
- validate a receipt for 1 quantity of the product
- open inventory valuation view and check 
that there is variation lines for 10
- open 'scheduled actions' view
- select 'inventory valuation closing' 
- click on 'run manually'


**Current behavior:**
Problem 1: 
the company of the account move 
is the main company

Problem 2: 
There is a traceback including 
'UserError: Everything is correctly closed'

**Expected behavior:**
Problem 1: 
It should be the branch company

Problem 2: 
Everything is closed in company 1, but 
it shouldn't prevent to generate the entries
for company 2

**Cause of the issue:**
Problem 1: 
Inside _cron_post_stock_valuation
we call action_close_stock_valuation for each company
(if periodic daily or periodic monthly and we're the last 
day of the month)
https://github.com/odoo/odoo/blob/b8e5291d103d9f43bd8db6d2dfe708076a57ea37/addons/stock_account/models/res_company.py#L143-L144

Inside action_close_stock_valuation when creating 
the account move we add a context to be sure that 
the move is created for the main company selected 
https://github.com/odoo/odoo/blob/b8e5291d103d9f43bd8db6d2dfe708076a57ea37/addons/stock_account/models/res_company.py#L72
The fix comes from this PR 
https://github.com/odoo/odoo/pull/263828
and was improved starting from 19.1 
to simply add a the company_id on the moves_vals.

But the problem is that this fix failed to consider 
the case where we come from cron because 
in this case self.env.company is the main company 
of the user, which is a problem because  as we iterate 
through the companies we want each account 
move to be created for its own company.
This other PR https://github.com/odoo/odoo/pull/269152 corrects
this by using self.id instead of self.company.id
but only starting from 19.1.

The fix is essentially a back port of those 2 PR.

Problem 2: 
When you call action_close_stock_valuation from 
_cron_post_stock_valuation for the company 
that has no inventory valuation and thus no 
account move to create we will raise the user
error 
https://github.com/odoo/odoo/blob/b8e5291d103d9f43bd8db6d2dfe708076a57ea37/addons/stock_account/models/res_company.py#L58-L60
This makes sense if the method was called 
from the inventory valuation view. 
But in our case it's called from cron so we might 
also call it on other companies and therefore we 
don't want to raise an exception if there is no 
account move to create on one of the companies.

opw-6144294

Forward-Port-Of: odoo/odoo#275294

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