### Issue before this commit:
When reverting a Guatemalan invoice (creating a credit note), the XML node FechaEmisionDocumentoOrigen incorrectly reports the EDI document's technical certification date instead of the original invoice's emission date. This causes the SAT to reject the document.

### Steps to reproduce the issue:
1. Download Accounting and l10n_gt
2. Revert an invoice (credit note) inserting a different date than the one of the invoice
3. See that FechaEmisionDocumentoOrigen report the date of the credit note instead of the one of the invoice

### Cause of the issue:
The _l10n_gt_edi_add_reference_values method extracted the date from original_document.datetime (the technical timestamp of when the XML was generated) rather than using the actual accounting date of the original invoice.

### Reason to introduce the fix:
SAT validation rules strictly require the reference date to match the exact commercial emission date of the original invoice. Fetching invoice_date directly ensures compliance, avoids timezone conversion errors, and prevents the XML from being rejected.
Source: https://www.lawinsider.com/es/contracts/dJXl4Vo79L2

<img width="730" height="205" alt="2026-07-17_10-19" src="https://github.com/user-attachments/assets/802e7bb3-fcf9-48db-b86f-227b494001b6" />

opw-6394409

**Description of the issue/feature this PR addresses:**

When adding a custom field (e.g., via Studio) to the Documents list view, clicking the cell directly does not trigger inline edit mode. The user has to first click a standard editable field (like "Owner") to put the row into edit mode before they can modify the custom field.

This occurs because we use a hardcoded whitelist (`editableColumns`) of standard fields allowed to trigger edit mode. Custom fields (`x_`) are missing from this static list.

This commit resolves the issue by dynamically injecting visible, non-readonly custom fields into the `editableColumns` whitelist. This allows user-created fields to be edited inline as expected.

**Steps to reproduce:**

- Documents > Studio > List view > Add any field that accepts user input (e.g. Text/char) > save/exit
- In the same Documents list view > select a row > click the cell belonging to the newly created field > observe that the row does not enter edit mode
- In the same Documents list view > select a row > click a standard editable cell, then click the cell belonging to our newly created field > observe that this then allows us to edit our field

**Current behavior before PR:**

- Custom fields do not trigger inline edit mode

**Desired behavior after PR is merged:**

- Custom fields trigger inline edit mode

opw-6378102

#### Description of the issue/feature this PR addresses:
On Thai-language documents, `res.currency.amount_to_text` (used e.g. for `account.move.amount_total_words` on invoice reports) renders amounts with satang as "หนึ่งร้อยห้าสิบ Baht และ ยี่สิบห้า Satang". Thai financial wording never uses the conjunction "และ" ("and") between the Baht and Satang parts — the standard format (cheques, tax invoices, Excel's BAHTTEXT) is "หนึ่งร้อยห้าสิบบาทยี่สิบห้าสตางค์". Confirmed by an Odoo translator on opw-6347437.

#### Current behavior before PR:
The Thai translation of the amount_to_text template keeps the English conjunction as "และ", producing incorrect Thai monetary wording such as "หนึ่งร้อยห้าสิบ Baht และ ยี่สิบห้า Satang".

#### Desired behavior after PR is merged:
The Thai msgstr no longer contains " และ ", so 150.25 THB renders as "หนึ่งร้อยห้าสิบ Baht ยี่สิบห้า Satang" (with native labels: "หนึ่งร้อยห้าสิบบาทยี่สิบห้าสตางค์"). The source term and all other languages are unchanged. Includes a regression test asserting Thai output has no "และ" and that English output keeps "and".

opw-6347437

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

Before this commit, when adding a line without a product to an invoice or credit note, `_get_most_frequent_account_for_partner` picked the partner's most-used account, filtered to an income or expense account depending on `get_inbound_types` and `get_outbound_types`.

Those helpers classify move types by cash-flow direction which is correct for choosing a receivable and payable account but wrong for choosing an income ro expense account: they group `in_refund`  with `out_invoice` as "inbound", and `out_refund` with `in_invoice` as "outbound".

As a result, a Vendor Credit Note line with no product would be filtered to income accounts instead of expense accounts, and a Customer Credit Note line to expense accounts instead of income accounts. This only surfaced for contacts who are both customer and vendor, since the query needs matching history to return a result; otherwise it silently falls back to the journal's default account, masking the bug for ordinary contacts.

This commit uses `get_sale_types` and `get_purchase_types` instead, which classify by document side, sale vs. purchase rather than cash-flow direction, matching the classification already used for product-based lines `is_sale_document` and `is_purchase_document`

opw-6373124



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

Forward-Port-Of: odoo/odoo#276846

**Issue**
A credit note created before returning any stock may compute an incorrect COGS value.

**Steps to reproduce**
- Create a product valued with AVCO and a standard price of 10
- Create and confirm a SO for 2 units
- Create and post the invoice
- Change the product's standard price to 20.
- Create a credit note without returning the delivered stock
-> The cogs value on the credit note is 40 instead of 20

**Cause**
While posting the credit note:
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/sale/models/account_move.py#L62
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/account/models/account_move.py#L5580
COGS lines are created:
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/stock_account/models/account_move.py#L46
which needs to compute the unit_price:
https://github.com/odoo/odoo/blob/f715337f70bf7eaa8f084da6cd42d674d7a4bfe0/addons/stock_account/models/account_move.py#L132
which is initially computed from the original invoice line:
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/stock_account/models/account_move.py#L308-L317
However, the `sale_stock` override recomputes that value whenever the invoice line is linked to a sales order:
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/sale_stock/models/account_move.py#L173
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/sale_stock/models/account_move.py#L212-L213
This computation will give the standard price since:
- `is_returned` is True but no return move, which means there won't be any candidate:
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/stock_account/models/product.py#L921-L923
- As a result, `qty_valued` is zero:
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/stock_account/models/product.py#L933-L936
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/stock_account/models/stock_valuation_layer.py#L172-L173
- The computation therefore falls back to the current standard price:
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/stock_account/models/product.py#L938-L946

opw-6369550

Issue
-----
Branch companies can have quants of a product limited to their parent company, but they don't show in the per location report.

Steps to reproduce
-----
- Create a branch company
	- Create a WH for the branch
- Create a tracked product
	- Company set to parent only
- Switch to the branch company
	- Add a quant of the product in branch stock
- Open Inventory > Reporting > Locations

> The product is not shown although there is a quant in the branch

Cause
-----
The menu button triggers `action_view_quants`

https://github.com/odoo/odoo/blob/03a3662212f094158f885ae6545009fd0a74d3cb/addons/stock/views/stock_quant_views.xml#L493-L495

https://github.com/odoo/odoo/blob/03a3662212f094158f885ae6545009fd0a74d3cb/addons/stock/models/stock_quant.py#L399-L402

The problem here comes from the fact that in `_get_quants_action`, we limit the products to those of only the active companies, instead of allowing to view those of parent companies aswell.

https://github.com/odoo/odoo/blob/03a3662212f094158f885ae6545009fd0a74d3cb/addons/stock/models/stock_quant.py#L1330

Such a change works because the domain is specifically for the product's (`product_id.company_id`) and not the location's.

-----
Ticket:
opw-6131525

When a bus process restarts, every client on every database it serves loses its websocket at the same instant and immediately schedules a reconnection. Each database that comes back triggers a registry recompute server-side, so a tight reconnection window makes all of those recomputes land together and pile up on the freshly started process.

The jitter added to each reconnection delay was only one second, far too narrow to break up that wave. Widen it to thirty seconds so the retries of the many clients fan out over a much wider window and the registry recomputes spread over time instead of colliding.

Raise the ceiling on the retry delay to two minutes to match that wider spread, and drop the exponential growth factor: with a thirty-second jitter accumulating on every attempt, the delay already climbs on its own, so scaling it further only pushed clients toward the ceiling sooner without spreading them any better.

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