Currently when the user does manual replenishment no notification is displayed.

## Steps to produce:
- Install Inventory and Purchase
- Create a product `Chocolate Icecream` and Enable `Track Inventory`
- Purchase > Add a Vendor `Ice cream man`
- Reordering rules > Create a new reordering rule and save:
  - Trigger: Manual
  - Min: 5
  - Max:10
- Press the `Order` button

## Observed Behavior:
No notification is displayed about the newly created purchase order.

## Root cause:
When the Order button is pressed, the `action_replenish` method is called. This method invokes `_procure_orderpoint_confirm` at [1].

The `_procure_orderpoint_confirm` function is responsible for creating procurements from orderpoints. During this process, it retrieves the procurement values using `_prepare_procurement_values` that are later used at [2].

However, `_prepare_procurement_values` only includes the orderpoint in the procurement values when the orderpoint's trigger is set to automatic, and not when it is manual, as shown at [3].

These procurement values are then used by `_run_buy` to create a purchase order and purchase order line at [4].

Since the orderpoint is not linked to the purchase order line in this case, no matching order is found at [5], which leads to the reported issue.

**Which commit caused this unintentional behavior?**
This behavior was unintentionally introduced by this [commit](https://github.com/odoo/odoo/commit/2a0d2c64d0027f540101447289b4c1a10cb3ecdf) . That commit fixed an issue where purchase order lines were not being merged for temporary manual orderpoints that are created dynamically based on product demand.

[1]-
https://github.com/odoo/odoo/blob/c076281dedeed2e25844c43c49ec17511434e3fc/addons/stock/models/stock_orderpoint.py#L342-L349 
[2]-
https://github.com/odoo/odoo/blob/c076281dedeed2e25844c43c49ec17511434e3fc/addons/stock/models/stock_orderpoint.py#L737-L741 
[3]-
https://github.com/odoo/odoo/blob/c076281dedeed2e25844c43c49ec17511434e3fc/addons/stock/models/stock_orderpoint.py#L687-L701 
[4]-
https://github.com/odoo/odoo/blob/c076281dedeed2e25844c43c49ec17511434e3fc/addons/purchase_stock/models/stock_rule.py#L156-L165 
[5]-
https://github.com/odoo/odoo/blob/c076281dedeed2e25844c43c49ec17511434e3fc/addons/purchase_stock/models/stock.py#L276-L296 

[6]-
https://github.com/odoo/odoo/blob/c076281dedeed2e25844c43c49ec17511434e3fc/addons/stock/models/stock_orderpoint.py#L365 
[7]-
https://github.com/odoo/odoo/blob/6a84d3e519892be333552e2e0ebf8da87e0a760c/addons/purchase_stock/models/purchase_order_line.py#L380-L384

## Solution:
Instead of removing the orderpoint ID from the procurement values, we reuse the same conditions used to identify temporary orderpoints for cleanup at [6]. Based on this, we determine how purchase order lines should be merged in the `_run_buy` method.

With the previous implementation, no orderpoint was included in the procurement values. As a result, the condition at [7] checking for orderpoints always evaluated to True, causing the system to identify an existing purchase order line for the same product as a merge candidate.

This solution allows us to retain that fix as well as avoid the error of notifications not showing up.


opw-6311520

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

`avatar.mixin._avatar_generate_svg()` generates an auto-initial SVG avatar for any record without a real uploaded image (used by `res.partner`, `res.users`, and anything else inheriting `avatar.mixin`). The generated SVG opens with a single-quoted XML declaration: `<?xml version='1.0' encoding='UTF-8' ?>`.

When this content is served via `/web/image/...`, `guess_mimetype()` needs to determine its Content-Type since it's a computed value with no stored attachment metadata. On systems where the installed `libmagic` library classifies that specific single-quoted byte pattern as `text/xml` rather than `image/svg+xml`, the wrong Content-Type reaches the browser.

**Current behavior before PR:**

On affected `libmagic` versions/databases, an auto-generated avatar (a contact or user with no uploaded photo) gets served with `Content-Type: application/octet-stream` (or `text/xml`) instead of `image/svg+xml`. Browsers can't render that inline as an image, so instead of showing the colored-initial avatar, the browser downloads it as an unrecognized file. This affects any place these avatars are displayed: contact/user form and kanban views, chatter message authors, Discuss, etc.

Confirmed reproducible with `libmagic` 538 (`python-magic`), where the single-quoted declaration is classified as `text/xml`, while the exact same content with double-quoted attributes is correctly classified as `image/svg+xml`.

**Desired behavior after PR is merged:**

`_avatar_generate_svg()` now generates its markup with double-quoted attributes throughout, which is correctly sniffed as `image/svg+xml` regardless of the installed `libmagic` version. Auto-generated avatars render inline in the browser as intended.

No other code depends on the exact quoting of this generated SVG - `res_users.py` and `hr_employee.py` both only assign the returned bytes to an image field without inspecting their content. Avatar fields are computed and non-stored, so nothing needs to be migrated - every record gets the corrected markup on its very next read, with no backfill required.

Updated the two existing `test_avatar_mixin.py` tests that asserted the exact (single-quoted) SVG string, and added `test_generated_partner_avatar_mimetype` to assert the generated avatar is actually sniffed as `image/svg+xml`, so this can't silently regress. Ran locally: all 6 tests in `TestAvatarMixin` pass.

## Problem
If multiple valuation/variation accounts are used, the Inventory Valuation report will not show the balance of accounts attached to products that have 0 quantity available if a different account has quantity.

## Solution
In order to maintain the performance improvements intended by the commit that introduced the `qty_available != 0` filter, we will avoid calculating `total_value` for products with 0 quantity. We will still run `stock_accounting_value` on these products in order to capture interim accounting value on the Inventory Valuation report.

## Steps to Reproduce (Runbot v19)
(defer to the test for more info)
1. Create an extra set of valuation/variation accounts
2. Create a product, avco perpetual accounting the default valuation/variation accounts
3. Create a second product, avco perpetual accounting the new valuation/variation accounts
4. Purchase 1 unit of each of the products and receive, bill both
5. Sell 1 unit of the product attached to the new valuation/variation
6. Go to Accounting > Review > Inventory Valuation, and note that the new valuation/variation accounts are not present. If you click Generate Entry, you will see that these accounts need to be balanced

opw-6473319

When recomputing overtime, attendances overlapping the affected day are retrieved based on their check-in and check-out.

An attendance whose check-out is exactly at the start of the following day is currently considered to overlap that day because the domain uses an inclusive lower bound on `check_out`.

This can cause overtime from the previous day to be recomputed using an incomplete set of attendances.

### Steps to reproduce:

* Configure an employee with a daily quantity overtime rule based on the expected hours from the contract.
* On the first day, create multiple attendances, with the last one ending exactly at midnight.
* Ensure the total worked hours on that day result in overtime.
* On the following day, create another attendance.
* Observe that recomputing the second day's overtime also retrieves the attendance ending at midnight.
* The previous day's overtime is then recomputed without the other attendances from that day, resulting in an incorrect overtime value.
* Regenerating the overtime ruleset restores the correct value.

For example, with 8.4 expected hours:

```
Day 1:
    09:30 - 11:30
    14:30 - 18:19
    21:00 - 00:00

Day 2:
    create/update an attendance
```

The `21:00 - 00:00` attendance is incorrectly included in Day 2's recomputation because its check-out equals the start of Day 2. The other Day 1 attendances are not included, so Day 1 is recomputed from only 3 hours of work.

To fix the issue we treat `check_out` as an exclusive interval boundary when determining overlap. An attendance ending exactly at the start of a day does not overlap that day, while attendances actually crossing midnight continue to be included.

opw-5474120


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

`_get_most_frequent_accounts_for_partner` filtered suggestions to
income/expense using `get_inbound_types` and `get_outbound_types`,
classify by cash-flow direction, not by income vs expense. This
grouped `in_refund` with `out_invoice` and `out_refund` with
`in_invoice`, so a Vendor Credit Note could suggest an income account
and a Customer Credit Note an expense account.

This function backs two things: the default account on a product-less
invoice/credit note line, and the "Suggested" account in the account
field's search. The bug hit both, and also made the suggestion
inconsistent with `name_search`'s own filter (`_get_name_search_account_types`),
so a suggested account could vanish as soon as you started typing.

This commit filters using `_get_name_search_account_types` instead, so
both code paths agree on which accounts are valid for a given move
type.

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#277951
Forward-Port-Of: odoo/odoo#276846

**Issue**
If a move's package is already reserved, relocating that move raises an AccessError.

**Steps to reproduce**
- Activate the "Packages" feature in Inventory settings.
- Activate track localization in settings
- Create a new storable product.
- Using an inventory adjustment, add some quantity of that product in Stock, in a new package X.
- Create a sales order for that product and confirm it, so the quantity in Stock gets reserved.
- Go to Inventory > Reporting > Locations.
- Select the quant and try to relocate it, e.g. to WH/Input.
-> Raises an AccessError: "Failed to write field stock.package.picking_ids"

**Cause**
Relocating a quant creates a move:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/addons/stock/models/stock_quant.py#L1531
which creates a new move line without a `picking_id`:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/addons/stock/models/stock_quant.py#L1276-L1287

Since both move lines (the new one and the one linked to the SO delivery) share the same `result_package_id`,
in `_compute_picking_ids`, both move lines are grouped:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/addons/stock/models/stock_package.py#L174-L176
Thus, two "pickings" end up associated with the package: the SO's, and `None`.
While setting those pickings on the package, it tries to access them:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/addons/stock/models/stock_package.py#L182
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/odoo/orm/fields_relational.py#L1497-L1503
And since `self` isn't just `None`, this check won't be skipped:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/odoo/orm/models.py#L4152
This eventually raises an AccessError since `None` gets filtered out by `filtered_domain`:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/odoo/orm/models.py#L4154-L4156
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/odoo/orm/fields_relational.py#L1504-L1505

opw-6427070

> Replaces https://github.com/odoo/odoo/pull/282286, which GitHub closed automatically after a bad force-push on my side: the branch was pushed from a shallow clone and its head lost its parent commit, leaving no common ancestor with 18.0. A PR in that state cannot be reopened, so this one continues from a clean branch with the exact same change. The review discussion is in that PR, and the rename asked for there is included here.

### Steps to reproduce

1. Go to `Accounting > Customers > Invoices` and create an invoice on a given journal, leaving it in draft. For the clearest case, leave it with no invoice line.
2. Go to `Accounting > Configuration > Journals`, open that journal and archive it.
3. `_check_auto_post_draft_entries` raises: *"You can not archive a journal containing draft journal entries. To proceed: 1/ click on the top-right button 'Journal Entries' from this journal form 2/ then filter on 'Draft' entries 3/ select them all and post or delete them through the action menu"*.
4. Follow those steps: click the `Journal Entries` smart button on the journal form.

### Current behaviour

The list comes up empty, so the user concludes the error message is wrong, while the draft entries do exist.

The instructions cannot be followed:

- The smart button opens `action_account_moves_all_a`, which is named **"Journal Items"** and targets **`account.move.line`**, not `account.move`. The label of the button and the name of the action it opens do not match.
- That action defaults to `search_default_posted: 1`, so no draft record is listed.
- Draft entries with **no line at all** — commonly created through the incoming mail alias of a journal — have no `account.move.line`, so they stay invisible in that view even after switching the filter.
- The action menu of a move line list offers no way to post or delete the entries, and the action sets `create: 0`.
- The filter is labelled **"Unposted"**, not "Draft".

The offending entries are only reachable through `Accounting > Accounting > Journal Entries`, filtering by journal and by "Unposted".

### Expected behaviour

The error should point to a view where the records blocking the archiving are actually listed and actionable.

### This PR

Two changes, the validation itself is unchanged:

- The error message now points to `Accounting > Accounting > Journal Entries` and uses the real filter name, "Unposted".
- The smart button of the journal form is renamed to **"Journal Items"**, so its label matches the action it opens and no longer suggests it lists journal entries. This was asked for in the review of the previous PR.

Targeted at 18.0 because that is where the misleading message is being hit in practice; it is identical on 19.0 and master. If a translatable string change does not qualify for the stable series, tell me and I will retarget to master.

Forward-Port-Of: odoo/odoo#282956

_get_all_addr() feeds the postal address block of generated pain.001
payment files, but does not return the partner's state nor the second
street line. The beneficiary state/province and street complement
(suite, unit, ...) therefore never appear in the generated file, even
when they are set on the partner, and there is no way to fix it from
the record. Some North American banks reject wire transfers whose
beneficiary address lacks the state/province, so those payments fail
regardless of how complete the vendor record is.

Return the state code and street2 alongside the other address
components, from the partner for the base implementation and from the
employee private address for the hr one, so the payment engine can
write them in the PstlAdr block.

Steps to reproduce:
- Install Accounting and enable a generic ISO 20022 payment method on
  a bank journal
- Create a vendor located in the US or Canada with a complete address,
  including the state and a second street line
- Register a vendor payment, add it to a batch and generate the
  pain.001 file
- The creditor PstlAdr has no state/province, and its street line only
  carries the first street field: the street2 part is dropped


Companion enterprise PR emitting the state in the generated file: odoo/enterprise#127958

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

Forward-Port-Of: odoo/odoo#282620
Forward-Port-Of: odoo/odoo#282518

Currently, an error occurs when user tries to pay on a vendor bill and removes the currency.

Steps to replicate:
- Install `l10n_account_withholding_tax`and activate multiple currencies.
- Open Invoicing > Vendors > Bills and create a new bill and add a vendor and bill date.
- Add a product and tax `2% WTH`.
- From the Cog menu > Click Pay > Remove the Currency.

Error:
```
  File '/home/odoo/src/odoo/saas-19.4/addons/l10n_account_withholding_tax/models/account_withholding_line.py', line 208, in _compute_original_amounts
    line.original_base_amount = line_curr.round(base_amount * rate)
  File '/home/odoo/src/odoo/saas-19.4/odoo/addons/base/models/res_currency.py', line 264, in round
    self.ensure_one()
  File '/home/odoo/src/odoo/saas-19.4/odoo/orm/models.py', line 5342, in ensure_one
    raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: res.currency()
```

Cause:
- As the user removed currency, the `comodel_currency_id`is received as false.
- Later when we call `round()` on the empty res.currency recordset causes this error to occur.

Solution:
- Added the company currency as a fallback value when `currency_id` is removed by user, since `currency_id` is a required field user will need to select a currency when saving.

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

Forward-Port-Of: odoo/odoo#277507

The following commit resets qty_invoiced to zero on sale order lines paid by a POS order when that order is refunded.
https://github.com/odoo/odoo/commit/ac39aa4f68dfc77011c39e468e3f60e0338a3c69

However, it does not handle the sale order line created for a refunded POS down payment. That line keeps `qty_invoiced` = -1, which causes the refunded amount to be included again when settling or invoicing the sale order.

Steps to reproduce:
- Create a sale order.
- Pay a down payment through the POS.
- Refund the down payment order from the POS.
- Settle the remaining amount from the POS or invoice the sale order from the backend.

Result:
- The generated invoice includes the sale order total plus the refunded down payment.
- Sale order `amount_invoiced` will be the down payment amount.

Fix:
- Delete the refunded downpayment to match the sale flow.
- Include refunded down payments in the amount_invoiced computation.

opw-6378891

Forward-Port-Of: odoo/odoo#282998
Forward-Port-Of: odoo/odoo#278011

**Issue**
Cost of SO might be wrong with MTO+Manufacture product

**Steps to reproduce**
- Activate margin in settings
- Create 2 products: 
  - product A: MTO + Manufacture, 1 qty onHand, standard price to 10 with avco valuation 
  - product B with a standard price of 5
- Create a BOM with the product B as comp
- create and confirm a SO for 1 unit of product A
- Go to the associated MO and produce all
- confirm the delivery linked to the SO -> The cost on the SO is 6.25, while the standard price remains 7.5

**Cause**
While confirming the MO, it linked the producing move (which has a unit value of 5), to the SO: https://github.com/odoo/odoo/blob/a6f22922a97399265c04855b5d9b18ac7ac609a0/addons/sale_mrp/models/mrp_production.py#L41-L48

While confirming the delivery, it triggers `_compute_purchase_price` since the picking state changes: https://github.com/odoo/odoo/blob/a6f22922a97399265c04855b5d9b18ac7ac609a0/addons/sale_stock_margin/models/sale_order_line.py#L10-L11 which will eventually takes all the moves links to the sale order to compute the price: https://github.com/odoo/odoo/blob/a6f22922a97399265c04855b5d9b18ac7ac609a0/addons/sale_stock_margin/models/sale_order_line.py#L21 https://github.com/odoo/odoo/blob/a6f22922a97399265c04855b5d9b18ac7ac609a0/addons/stock_account/models/stock_move.py#L701-L714

Which gives an averaging between 5 and 7.5 -> 6.25. Indeed, the unit value of the out move is the standard price: https://github.com/odoo/odoo/blob/8387c28423e8208e53939da3ef5a074c072d33a6/addons/stock_account/models/stock_move.py#L353

opw-6418948

**Steps to reproduce:**

-  Install the Serbian EDI module `l10n_rs_edi`.
-  Configure eFaktura credentials on the company.
-  Create and confirm a Serbian customer invoice.
-  Send the invoice to eFaktura.

**Observed Behavior:**

When the eFaktura API returns an HTTP error, Odoo only displays the generic exception generated by `requests`, for example an HTTP 400/500 error.

The actual error information returned by eFaktura in the response body is not shown to the user, making it difficult to understand why the invoice was rejected.

**Cause:**

`_l10n_rs_edi_send` catches `HTTPError`, `Timeout`, and `ConnectionError`, but the error message is built only from the Python exception.

For HTTP errors, the eFaktura API may return a response containing more precise information such as:

```json
{
    ErrorCode: ...,
    Message: ...
}
```

This response was not being used when displaying the error in Odoo.

**Fix:**

When an HTTP response is available and contains an eFaktura error payload, use the returned `ErrorCode` and `Message` as the error displayed on the invoice. Fallback to the existing connection/HTTP exception message when no usable API response is available.

opw - 6453653

Forward-Port-Of: odoo/odoo#281490

**Steps to reproduce:**
 - Install l10n_din5008 and accountant.
 - Enable Snailmail from Accounting → Settings.
 - Create a German customer (Fiscal Country: Germany).
 - Create and post a customer invoice using the DIN5008 report layout.
 - Select Send by Post.
 - Enable Developer Mode and navigate to `Settings → Technical → Email → Snailmail Letters`.
- Open the generated letter and send it.

**Current behavior:**
The letter fails to be sent to Pingen with the following error: An error occurred when sending the document by post.
Error: ` The attachment of the letter could not be sent. Please check its content and contact the support if the problem persists.`

**Cause:**
For Snailmail documents, Pingen validates that the recipient address is located within the DIN5008 address window. The current l10n_din5008 report renders additional document information instead of the address in the address area, preventing the compliance validation to fail.

**Fix:**
When rendering the report for Snailmail, ensure that only the recipient address is displayed in the DIN5008 address window while suppressing the additional information that would otherwise occupy this area. This preserves the standard DIN5008 layout for regular reports while generating a Snailmail-compliant PDF that passes Pingen’s validation.

**Reference:** [Pignen Recipient Address Validation Rule](https://help.pingen.com/en/fix-and-enhance-letters/issue-with-recipient-address#040201)

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

Forward-Port-Of: odoo/odoo#280320

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

Two related Nilvera e-invoice issues affecting Turkish companies:
- The "Fetch Nilvera PDF" button appeared for every company, not just Turkish ones.
- Sending/fetching e-invoices (or fetching the PDF) as a non-admin Invoicing user raised an
  AccessError, because the company's Nilvera API key field is restricted to System/Settings users
  and several call sites read it without `.sudo()`.

## Current behavior before PR:

- The PDF-fetch button shows on both the list view and form view of `account.move` regardless of
  the company's country.
- An Invoicing-only user (no System/Settings access) gets an AccessError when sending/fetching
  e-invoices or fetching the PDF, because `_get_nilvera_client` reads
  `company.l10n_tr_nilvera_api_key` without `.sudo()`.

## Desired behavior after PR is merged:

- Both buttons are only visible for Turkish companies (the list-view button has no bound record, so
  its gate is driven by a new `l10n_tr` session_info/JS context injection instead of a direct field
  reference).
- Invoicing users can send/fetch e-invoices and fetch the PDF without hitting an AccessError.

## Things to add on forward-port

### 19.2
- [ ] Fix e-Dispatch sending access error (sudo `_get_nilvera_client`)
- [ ] Fix e-Dispatch status-refresh access error (sudo `_get_nilvera_client`)

### 19.4
- [ ] Fix e-Dispatch/e-Receipt fetch access error (sudo `_get_nilvera_client`)
- [ ] Fix e-Dispatch/e-Receipt fetch gate-check access error (sudo the API-key check)
- [ ] Fix e-Dispatch PDF-fetch cron access error (sudo `_get_nilvera_client`)
- [ ] Fix Commercial invoice accept/reject access error (sudo `_get_nilvera_client`)

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

### Issue before this commit:
When using the "Reverse and Create Invoice" feature on a posted invoice with a foreign currency and Cash Basis enabled, the expected Exchange Difference and Cash Basis tax entries are not generated upon the automatic reconciliation. The credit note is successfully created and reconciled with the original invoice, but the P&L exchange difference and the cash basis transition lines are completely missing. Currently, the only workaround is to manually reset the generated credit note to draft and re-post it, which forces the system to correctly calculate the currency rate differences and generate the missing entries.

### Steps to reproduce the issue:
1. Download Accounting
2. Go to Settings > Cash basis. Tick it and set as 'Base Tax Received Account' an account like 201000 Current Liabilities
3. Go to Chart of Accounts > search your account (ex. 201000 Current Liabilities) and be sure the flag of 'Allow Reconciliation' is on
4. Go to Taxes > 15% sales > set 'Tax Exigibility' as Based on Payment and 'Cash Basis Transition Account' always as 201000 Current Liabilities
5. Go to Currencies and set a new currency like MXN inserting tax rates as:
	1. 1 july 2026: 20$
	2. 15 july 2026: 15$
6. Create a new invoice with price 100 and 15% tax, set MXN as currency for the journal, set the date as 1 july and confirm it
7. Click on 'Credit Note', then 'Reverse and Create Invoice' and confirm it
8. go back to the invoice and see that after the total amount there is a new line 'Reversed on...'
9. After that line there should also be the line with the Exchange Difference since the tax rates for MXN currency were different at the moment of the invoice and at the moment of the credit note. This is only created by resetting to draft the credit note and confirm it again.

### Cause of the issue:
In the account.move.reversal wizard, when is_modify = True (Reverse and Create), the system triggers _reverse_moves with cancel=True. At the end of the _reverse_moves method, the newly created reverse moves are automatically posted and reconciled. However, this automatic posting is executed with move_reverse_cancel=True injected into the context: reverse_moves.with_context(move_reverse_cancel=cancel)._post(soft=False). When the reconciliation engine (_reconcile_plan_with_sync and _create_exchange_difference_moves) detects this specific context key, it intentionally bypasses the creation of both the exchange difference P&L moves and the cash basis entries, treating the reversal as a pure administrative cancellation rather than a financial operation with currency fluctuations.

### Reason to introduce the fix:
To ensure financial accuracy and compliance, especially when cash basis and multi-currency are involved, a reversal on a different date must reflect the actual exchange rate fluctuations and properly trigger cash basis rules. By removing the move_reverse_cancel context injection during the automatic posting of the reverse moves, we allow the native reconciliation engine to evaluate the newly computed balance (based on the credit note's date) against the original invoice. This ensures that exchange differences and cash basis journal entries are automatically and accurately generated on the first attempt.

opw-6399867

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

Forward-Port-Of: odoo/odoo#281498

### Steps to reproduce:

- Enable Multi-Steps Routes, subcontracting and unarchive the MTO route
- Create 3 products: Final Product (FP), Subcontracted Component (SB), Component (COMP) and put SB in MTO
- Create a BOM for FP: 1 x SB
- Create a subcontracted BOM for SB: 1 x COMP
- Create and confirm an MO for 1 unit of FP
> This generates a subcontracted MO for 1 unit of SB
- Confrim the subcontracted PO and go back to the MO of FP
#### > The component move forecast appears "Available" even if the SB unit is neither received nor 'pre-reserved' (the quantity of the move raw is still 0).

### Cause of the issue:

The `forecast_widget` displays an available status in case the demand of the move is expected to be fulfilled and there is no `forecastExpectedDate`:
https://github.com/odoo/odoo/blob/a46cdcd9d0b575eb668ed738565637f346bbdf7b/addons/stock/static/src/widgets/forecast_widget.xml#L1-L19 https://github.com/odoo/odoo/blob/4fbd88ad3ac2d92b47b024b96f1c40ed4b3f97e3/addons/stock/static/src/widgets/forecast_widget.js#L15-L26 Now, the issue is that this `forecastExpectedDate` is currently unreliable in this use case as the `forecast_expected_date` of the SB component move is incorrectly computed to be False rather than matching its subcontracted receipt counter part. To be more precise, the `forecast_expected_date` is computed based on the report lines: https://github.com/odoo/odoo/blob/8b8b99e371fcf214b9c55fb2fbfca20f2ee66f53/addons/stock/models/stock_move.py#L579-L581 https://github.com/odoo/odoo/blob/8b8b99e371fcf214b9c55fb2fbfca20f2ee66f53/addons/stock/models/stock_move.py#L2701 The component move is an out move of SB from Stock to Production and is linked to the finished subcontracted move of SB from Production to Subcontracting. In particular, this finished subcontracted move (which is assigned) contributes to the 'reserved' out qties on the get go and leads to an already reserved out quantity of 1.0 even thought the move is purely external and linked to the subcontractor process: https://github.com/odoo/odoo/blob/ef89bc530ffae93a553003559ca9078b7a9d0653/addons/stock/report/stock_forecasted.py#L241-L268
In turn, the `demand_out` matched its `reserved_out` (even thought this reserved_out should be 0) so that no `in_transit` move is provided to provide an `expected_date`:
https://github.com/odoo/odoo/blob/ef89bc530ffae93a553003559ca9078b7a9d0653/addons/stock/report/stock_forecasted.py#L426-L435

opw-6445209

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

Steps to reproduce:
-------------------
1. Install `stock` module.
1. Enable the "Storage Locations" from setting.
2. Create an internal location and enable `replenish_location` on it and set warehouse(WH) as Parent.
3. Create a storable product track by quantity with no on-hand quantity.
4. Create an internal transfer from the warehouse stock location to the new internal location.
5. Confirm the transfer.
6. Open the Replenishment report.

Issue:
------
No manual reordering rule is created for the product at the source location, although 
the confirmed transfer makes its forecasted quantity negative.

If `replenish_location` is disabled on the destination, the expected reordering rule is created.

Cause:
------

When both the source and destination have `replenish_location=True`, Odoo considers both locations 
inside the same replenishment area. Therefore, the internal transfer is not counted as either
incoming or outgoing, and no replenishment is created for the source location.

Code Flow: 

Opening the Replenishment report calls
`stock.warehouse.orderpoint.action_open_orderpoints()`, which delegates the report preparation to `_get_orderpoint_action()`:

https://github.com/odoo/odoo/blob/12a66c6931d81e1cce18f676836aca0b32090d16/addons/stock/models/stock_orderpoint.py#L324-L326

`_get_orderpoint_action()` first obtains every location that must be monitored for replenishment through `_get_orderpoint_locations()`:

https://github.com/odoo/odoo/blob/12a66c6931d81e1cce18f676836aca0b32090d16/addons/stock/models/stock_orderpoint.py#L520

`_get_orderpoint_locations()` returns all locations whose `replenish_location` field is enabled:

https://github.com/odoo/odoo/blob/12a66c6931d81e1cce18f676836aca0b32090d16/addons/stock/models/stock_orderpoint.py#L799-L800

All these locations are passed together to
`product.product._get_domain_locations_new()`:

https://github.com/odoo/odoo/blob/12a66c6931d81e1cce18f676836aca0b32090d16/addons/stock/models/product.py#L396-L464

This method treats the provided locations and their descendants as a set. Its move domains are equivalent to:

- incoming: destination is inside the set and source is outside;
- outgoing: source is inside the set and destination is outside.

Consider the following sibling locations:

    WH
    ├── Stock
    └── Replenish Location

and the transfer:

    Stock -- 3 units --> Replenish Location

When `replenish_location` is disabled on the destination, the considered location set contains only `Stock`:

    considered location set = {Stock}

The source is inside the set and the destination is outside:

    source inside       = True
    destination outside = True

The transfer therefore matches the outgoing domain:

    source inside AND destination outside
    True          AND True
    = True

It is included in `moves_out`, and the preliminary forecast for `Stock` becomes:

    0 on hand + 0 incoming - 3 outgoing = -3

https://github.com/odoo/odoo/blob/12a66c6931d81e1cce18f676836aca0b32090d16/addons/stock/models/stock_orderpoint.py#L552

The negative quantity is detected and a manual orderpoint is created.

When `replenish_location` is enabled on the destination, both sibling locations belong to the considered location set:

    considered location set = {Stock, Replenish Location}

Both ends of the transfer are now inside:

    source inside       = True
    destination inside  = True
    destination outside = False
    source outside      = False

The transfer matches neither aggregate domain:

    incoming:
    destination inside AND source outside
    True               AND False
    = False

    outgoing:
    source inside AND destination outside
    True          AND False
    = False

The transfer is considered internal to the considered location set and is therefore absent from both `moves_in` and `moves_out`:

https://github.com/odoo/odoo/blob/12a66c6931d81e1cce18f676836aca0b32090d16/addons/stock/models/stock_orderpoint.py#L530-L540

This aggregate treatment conflicts with the next step, where `_get_orderpoint_action()` computes the quantity separately for each replenishment location:

https://github.com/odoo/odoo/blob/12a66c6931d81e1cce18f676836aca0b32090d16/addons/stock/models/stock_orderpoint.py#L549-L552

When `Stock` is evaluated separately, the internal transfer has already been discarded. Its calculated outgoing quantity is consequently zero:

    0 on hand + 0 incoming - 0 outgoing = 0

As the quantity is not negative, the product is not scheduled for the final `virtual_available` computation and no manual orderpoint is created.

Fix:
----
Also retrieve moves whose source and destination are both inside the aggregate replenishment-location set.

Include these internal moves in both the incoming and outgoing grouped queries. The existing per-location path filtering then assigns each side correctly:

- the source replenishment location counts the move as outgoing;
- the destination replenishment location counts it as incoming.

For the reported transfer, this produces:

    Stock:
    0 on hand + 0 incoming - 3 outgoing = -3

    Replenish Location:
    0 on hand + 3 incoming - 0 outgoing = 3

This is correct because the report creates replenishment propositions per location, even though the initial move query is performed for all replenishment locations together.

---

opw-6462608


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

Duplicated subcontracting pickings inherit `reference_ids` from the original record, causing multiple destination moves to be linked to a single subcontracting order's finished move due to the new move being picked up by `_assign_picking()`. This can cause a multitude of problems, like causing the received quantity & on hand quantity to drastically fluctuate, or a traceback error.

**Reproduction Steps:**

- Install Purchase & Manufacturing apps, enable the Subcontracting setting
- Configure two products (a manufactured product and another product to use in its BoM) and a Vendor, create the BoM and set to Subcontracting
- Make & confirm a Purchase Order for the manufactured product (ex. quantity of 100)
- Click on the Receipts smart button and duplicate the generated picking
- Confirm the duplicate receipt by clicking "Mark as Todo"
- Click "Subcontracting Productions" and decrease the quantity of the production order
- Go back to the picking and try to validate; whether you create a backorder or not, you get a traceback. If there were any backorder moves linked to this purchase order, the quantity received & and the on-hand quantity

**Fix:**

Override the copy_data() function in stock_picking.py to explicitly catch duplicated stock moves that have copied reference_ids and remove them to force them to create new references.

**Video:**

https://drive.google.com/file/d/13kxhfcIesV1u2zwnY_N0eJWyUm2asCiP/view?usp=drive_link

Related ticket: opw-6431842

When updating mail notifications during `mail.mail._send()`,

a `SerializationFailure` raised while flushing the notification recordset leaves the current transaction in an aborted state.

As `_send()` continues handling the exception, accessing fields:
 - https://github.com/odoo/odoo/blob/127f1316540ec6cc6880ea3515e6923ba3903bc7/addons/mail/models/mail_mail.py#L816

So, any subsequent SQL query fails with

`InFailedSqlTransaction`, masking the original concurrency error.

Avoid accesing to `mail.message_id` with aborted cursor, preserving the original `SerializationFailure`.

A regression test is added to simulate a concurrency failure during

`flush_recordset()` and verify that the cursor is no longer used dirty

The logger for the unittest without the fix is the following:

```log
During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "odoo/addons/mail/models/mail_mail.py", line 719, in _send
    notifs.flush_recordset(['notification_status', 'failure_type', 'failure_reason'])
  File "<string>", line 3, in flush_recordset
  File "unittest/mock.py", line 1139, in __call__
    return self._mock_call(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "unittest/mock.py", line 1143, in _mock_call
    return self._execute_mock_call(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "unittest/mock.py", line 1204, in _execute_mock_call
    result = effect(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/addons/test_mail/tests/test_message_post_concurrent.py", line 93, in mocked_mail_notification_flush_recordset
    return original_flush_recordset(self, *vals, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/models.py", line 6788, in flush_recordset
    self._flush(fnames)
  File "odoo/odoo/models.py", line 6852, in _flush
    model.browse(some_ids)._write_multi(vals_list)
  File "odoo/odoo/models.py", line 4938, in _write_multi
    self.env.execute_query(SQL(
  File "odoo/odoo/api.py", line 993, in execute_query
    self.cr.execute(query)
  File "odoo/odoo/sql_db.py", line 371, in execute
    res = self._obj.execute(query, params)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.SerializationFailure: could not serialize access due to concurrent update

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "odoo/addons/test_mail/tests/test_message_post_concurrent.py", line 107, in test_mail_send_dirty_cursor
    mails.send()
  File "odoo/addons/mail/models/mail_mail.py", line 652, in send
    self.browse(batch_ids)._send(
  File "odoo/addons/mail/models/mail_mail.py", line 818, in _send
    mail.id, mail.message_id)
             ^^^^^^^^^^^^^^^
  File "odoo/odoo/fields.py", line 1309, in __get__
    self.compute_value(recs)
  File "odoo/odoo/fields.py", line 1491, in compute_value
    records._compute_field_value(self)
  File "odoo/odoo/models.py", line 5302, in _compute_field_value
    fields.determine(field.compute, self)
  File "odoo/odoo/fields.py", line 113, in determine
    return needle(records, *args)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/fields.py", line 710, in _compute_related
    record[self.name] = self._process_related(value[self.related_field.name], record.env)
                                              ~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/models.py", line 7083, in __getitem__
    return self._fields[key].__get__(self)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/fields.py", line 1272, in __get__
    recs._fetch_field(self)
  File "odoo/odoo/models.py", line 4120, in _fetch_field
    self.fetch(fnames)
  File "odoo/addons/mail/models/mail_message.py", line 756, in fetch
    return super().fetch(field_names)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/models.py", line 4158, in fetch
    fetched = self._fetch_query(query, fields_to_fetch)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/models.py", line 4245, in _fetch_query
    rows = self.env.execute_query(query.select(*sql_terms))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/api.py", line 993, in execute_query
    self.cr.execute(query)
  File "odoo/odoo/sql_db.py", line 371, in execute
    res = self._obj.execute(query, params)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.InFailedSqlTransaction: current transaction is aborted, commands ignored until end of transaction block
```

Real error in production:

```log
2023-04-15 10:43:14,978 106451 ERROR my_db odoo.sql_db: bad query: UPDATE "mail_notification" SET "failure_reason" = "__tmp"."failure_reason"::text, "failure_type" = "__tmp"."failure_type"::VARCHAR, "notification_status" = "__tmp"."notification_status"::VARCHAR FROM (VALUES (4426629, 'Error without exception. Probably due to concurrent access update of notification records. Please see with an administrator.', 'unknown', 'exception')) AS "__tmp"("id", "failure_reason", "failure_type", "notification_status") WHERE "mail_notification"."id" = "__tmp"."id" ERROR: could not serialize access due to concurrent update
```

```log
2023-04-14 10:43:14,978 106451 ERROR my_db odoo.sql_db: bad query: UPDATE "mail_mail" SET "failure_reason"='Error without exception. Probably due do sending an email without computed recipients.',"headers"='{''X-SMTPAPI'': ''{"ip_pool": "Transactional"}'', ''X-Odoo-Objects'': ''sale.order-1436960''}',"state"='exception',"write_uid"=1,"write_date"=(now() at time zone 'UTC') WHERE id IN (2548540)
ERROR: current transaction is aborted, commands ignored until end of transaction block
```

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:


# UPDATE 2026-07-22

The reviewer requested to remove the large docstring

For record, the docstring was

```python
    """Reproduces a concurrency scenario where `mail_mail._send()` fails with a PSQL SerializationFailure after
        flushing `mail.notification` records. After such a failure, the cursor is left in an aborted
        (`InFailedSqlTransaction`) state, so any further SQL access (e.g. reading `mail.message_id` like
        https://github.com/odoo/odoo/blob/127f1316540ec6cc68/addons/mail/models/mail_mail.py#L816)
        would raise a new error masking the original SerializationFailure.

        Setup:
        - Uses a separate `cursor()` to create and commit a message with its `mail.mail` and `mail.notification`
        records, so they are visible to a second, concurrent transaction.

        Concurrency simulation:
        - `MailNotification.flush_recordset` is patched so that, right before the real flush runs, a second cursor
        updates the same `mail.notification` records (`failure_reason`). This forces PSQL to raise a
        SerializationFailure when the original transaction tries to flush those rows.

        Assertions:
        - `SerializationFailure` is raised confirming the concurrency conflict.
        - `mail_mail._send()` logs the expected error message containing the mail `id` and `message-id`

        Cleanup: created records are unlinked in `finally`
        """
```

# UPDATE 2026-07-23

The reviewer requested to remove the unittest

For record, the unittest was

```diff
diff --git a/addons/test_mail/tests/test_message_post.py b/addons/test_mail/tests/test_message_post.py
index 53dd5b9eec52..46a3958a5bff 100644
--- a/addons/test_mail/tests/test_message_post.py
+++ b/addons/test_mail/tests/test_message_post.py
@@ -7,17 +7,21 @@ from datetime import datetime, timedelta
 from freezegun import freeze_time
 from itertools import product
 from markupsafe import escape, Markup
+from psycopg2.errorcodes import SERIALIZATION_FAILURE as SERIALIZATION_FAILURE_CODE
+from psycopg2.errors import SerializationFailure
 from unittest.mock import patch
 
-from odoo import tools
+from odoo import SUPERUSER_ID, api, tools
 from odoo.addons.base.tests.test_ir_cron import CronMixinCase
-from odoo.addons.mail.tests.common import mail_new_test_user, MailCommon
+from odoo.addons.mail.models.mail_notification import MailNotification
+from odoo.addons.mail.tests.common import mail_new_test_user, MailCommon, MockEmail
 from odoo.addons.test_mail.data.test_mail_data import MAIL_TEMPLATE_PLAINTEXT
 from odoo.addons.test_mail.models.test_mail_models import MailTestSimple
 from odoo.addons.test_mail.tests.common import TestRecipients
 from odoo.api import call_kw
 from odoo.exceptions import AccessError
-from odoo.tests import tagged
+from odoo.modules.registry import Registry
+from odoo.tests import TransactionCase, get_db_name, tagged
 from odoo.tools import mute_logger, formataddr
 from odoo.tests.common import users
 
@@ -2244,3 +2248,49 @@ class TestMessagePostLang(MailCommon, TestRecipients):
                                     self.assertIn('html lang="es_ES"', email['body'])
                                 else:
                                     self.assertIn('html lang="en_US"', email['body'])
+
+
+@tagged('database_breaking')
+class TestMessagePostConcurrent(MockEmail, TransactionCase):
+    """Mail concurrency edge cases that require real, separately committed transactions
+    instead of the usual rollback-based TransactionCase isolation.
+    """
+
+    def test_mail_send_dirty_cursor(self):
+        """Reproduces SerializationFailure `mail_mail._send()` fails,
+        the cursor is left in an aborted state, so any further SQL access would raise a new error
+        (e.g. reading `mail.message_id` like
+        https://github.com/odoo/odoo/blob/127f1316540ec6cc68/addons/mail/models/mail_mail.py#L816)
+        """
+        original_flush_recordset = MailNotification.flush_recordset
+
+        def mocked_mail_notification_flush_recordset(self, *args, **kwargs):
+            with Registry(get_db_name()).cursor() as cr:
+                cr.execute('UPDATE mail_notification SET failure_reason = %s WHERE id IN %s', ('Forced Concurrent Update', tuple(self.ids)))
+            return original_flush_recordset(self, *args, **kwargs)
+
+        recs2unlink = []
+        with Registry(get_db_name()).cursor() as cr:
+            env = api.Environment(cr, SUPERUSER_ID, {})
+            partner = env.ref('base.user_admin').partner_id
+            try:
+                message = partner.message_post(body='Hello', message_type='comment', partner_ids=[partner.id], mail_auto_delete=False, force_send=False)
+                notifs = env['mail.notification'].search([('notification_type', '=', 'email'), ('mail_mail_id', 'in', message.mail_ids.ids)])
+                self.assertTrue(notifs)
+                mails = message.mail_ids
+                recs2unlink.extend([notifs, mails, message])
+                cr.commit()
+
+                mails = self.env[mails._name].browse(mails.ids)
+                with (
+                    mute_logger('odoo.sql_db'), self.assertRaises(SerializationFailure) as exc, self.mock_mail_gateway(),
+                    patch(f'{MailNotification.__module__}.{MailNotification.__name__}.flush_recordset', autospec=True, side_effect=mocked_mail_notification_flush_recordset),
+                    self.assertLogs('odoo.addons.mail.models.mail_mail', level='ERROR') as log_capture,
+                ):
+                    mails.send()
+            finally:
+                for rec2unlink in recs2unlink:
+                    env[rec2unlink._name].browse(rec2unlink.ids).unlink()
+
+            self.assertEqual(exc.exception.pgcode, SERIALIZATION_FAILURE_CODE)
+            self.assertIn(f'Exception while processing mail with ID {mails.id} and Msg-Id \'{mails.message_id}\'.', [record.message for record in log_capture.records])

```

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

Forward-Port-Of: odoo/odoo#279897
Forward-Port-Of: odoo/odoo#274089

The PstlAdr block written into pain.001 files never contains the
partner's state/province nor the second street line, even when they
are set on the record: _get_all_addr() now returns them, but
_get_PstlAdr() also needs to write them out. Some North American banks
reject wire transfers whose beneficiary address lacks the
state/province, so those payments fail regardless of how complete the
vendor record is.

Emit CtrySubDvsn when the address has a state, before Ctry as required
by the element order of the PostalAddress schema, and append street2
to the street address line.

Steps to reproduce:
- Install Accounting and enable a generic ISO 20022 payment method on
  a bank journal
- Create a vendor located in the US or Canada with a complete address,
  including the state and a second street line
- Register a vendor payment, add it to a batch and generate the
  pain.001 file
- The creditor PstlAdr has no state/province, and its street line only
  carries the first street field: the street2 part is dropped


Requires odoo/odoo#282518, which makes _get_all_addr() return the state and street2.

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

Forward-Port-Of: odoo/enterprise#128021
Forward-Port-Of: odoo/enterprise#127958

### Issue:
When an invoice has an image as its main attachment added via a log note, any non-admin user who did not create the attachment gets an `AccessError` when exporting the Datev ATCH zip

### Cause:
Since commit `e7c93e5a6f`, attachments uploaded via certain flows can be "orphaned" — their `res_model` is set to `False` and `res_id` to `0` via `_fix_attachments_on_record_from_files_data`
This allows the attachment to appear in the chatter without being linked to the move's attachment list

However, `_message_set_main_attachment_id` can still set such an orphaned attachment as `message_main_attachment_id`
When a user without system rights tries to read it, the ORM access check uses `res_model=False` and `res_id=0`, which does not match the move the user has access to, raising an `AccessError`

### Steps to reproduce:
- Install `l10n_de_reports` and switch to the DE company
- Create and confirm an Invoice (any lines, any customer)
- Add a Log Note with an image
- Set Demo user's Accounting rights to `Invoicing & Banks`
- Log in as Demo
- Open the General Ledger
- In the cog menu, choose `Datev ATCH (zip)`

Before the fix, an `AccessError` is raised

opw-6397804

Forward-Port-Of: odoo/enterprise#127787

Steps to reproduce:
1. Install Documents
2. In the Documents list view, select a document to display the inspector.
3. Edit a field such as Owner or Customer which uses a Many2one widget.
4. In the field dropdown, click "Search More..." to open a modal dialog.
5. Click inside the "Search More..." modal (e.g., to sort columns or resize headers).

Issue:
- The modal dialog immediately closes, and the contact cannot be selected.

Root cause:
- When an inspector field is edited, the record row is put into edit mode. While in edit mode, the documents list renderer listens for global clicks. Clicking inside the "Search More..." modal dialog targets elements that have `.o_list_renderer` (since the modal dialog renders a list view). Because the click target is within a list renderer but is not a document row, `DocumentsListRenderer.onGlobalClick` executes and clears the selection of the main list view. Clearing the selection unmounts the edited field in the inspector, thereby destroying the modal dialog stack.

Solution:
- Modify DocumentsListRenderer.onGlobalClick to scope click handling to the current Documents list renderer.
Ignore clicks outside this.root.el, so interactions in nested UI such as Search More... do not clear
the main selection and destroy the inspector field.


opw-6253360

Forward-Port-Of: odoo/enterprise#127557
Forward-Port-Of: odoo/enterprise#119262

**Steps to reproduce:**
* Install the **United Kingdom - BACS** (`l10n_uk_bacs`) module.
* Create a vendor and add a bank account using local UK details (Account Number: `12345678`, Sort Code: `20-30-40`) without an IBAN.
* Go to **Accounting → Vendors → Payments**, create a payment using **BACS Direct Credit** and select the local vendor bank account.
* Try to post the payment.

**Observed behavior:**
* A `ValidationError` is raised: *"The selected vendor account needs to be a valid UK IBAN"*.
* BACS payment generation is blocked entirely for vendors who only have local UK bank details, even though BACS payments are commonly processed using sort code + account number.
* The same error occurs when validating a BACS Direct Debit Instruction (`action_validate_ddi`) with a local account.

**Cause:**
* `_check_bacs_bank_account` in `account.payment` unconditionally requires the partner bank account to be of type `iban` with a `GB` prefix.
* `validate_batch` in `account.batch.payment` applies the same strict IBAN check on the journal's bank account.
* `action_validate_ddi` and `action_print_ddi` in `bacs.ddi` enforce an identical IBAN-only restriction on the DDI's debtor account.
* `_validate_account_journal_id` in `bacs.ddi` rejects journals whose bank account is not a GB IBAN.
* The BACS file generation in `account.journal` extracts the sort code and account number exclusively via `get_iban_part()`, which fails for non-IBAN accounts.

**Fix:**
* Add `_is_valid_uk_bank_account()` to `res.partner.bank`: accepts either a valid GB IBAN **or** a local account with an 8-digit account number and a correctly formatted sort code stored in `clearing_number`.
* Replace every hard IBAN check in `account.payment`, `account.batch.payment`, and `bacs.ddi` with `_is_valid_uk_bank_account()`.
* Update `_create_dc_payments` and `_create_dd_payments` in `account.journal` to extract sort code and account number from `clearing_number` when the partner bank is not an IBAN, so the generated BACS file contains the correct values regardless of account type.
* The journal-side requirement (company bank account) is intentionally left unchanged; this fix only relaxes the partner/vendor-side constraint.

REF PR(19.1) : https://github.com/odoo/enterprise/pull/89504/changes/1d7dda45b4b29d08177fdcd0ba2316f1d60943db

opw-6462413

Steps to reproduce:
- Set up a company in Kenya with eTIMS.
- Sell an order from the POS and send it to eTIMS.
- Refund that order and send the refund to eTIMS.

Cause of the issue:
When we build the JSON for eTIMS, the "orgInvcNo" field (the KRA invoice number of the order we are refunding) was always set to `self.sequence_number`, which is just the order's own number in its session. This is wrong for a refund: eTIMS then can't find the item on "the original invoice" (since it's looking at the wrong invoice), and also can't check the amounts, since it's comparing them to the wrong order. eTIMS then rejects the refund with a 910 error, like "item sequence ... does not exist on the original invoice" or "amount is incorrect for item ...".

The invoice-based flow (account_move.py) already does this the right way, using `reversed_entry_id.l10n_ke_oscu_invoice_number`, but the POS order flow was not doing the same thing.

Solution:
For a refund order, use the KRA invoice number of the refunded order (`refunded_order_id.l10n_ke_oscu_order_number`) instead of the refund's own sequence number. Normal sales keep working like before.

opw-6445174

### Issue before this commit:
When generating a SEPA Credit Transfer batch using the German XML format (pain.001.001.03), the <LEI> tag is erroneously included in the exported file if an LEI is configured on the company. This invalidates the XML, causing banks to reject the file.

### Steps to reproduce the issue:
1. Download Accounting and l10n_de
2. Go to Settins > Vendor Payments > SEPA Credit Transfer / ISO20022 and set Name Identification as 529900T8BM49AURSDO55 and Issuer as LEIMAN
3. Go to companies and set 529900T8BM49AURSDO55 as LEI in the DE company
4. Go to Accounting dashboard and click the 3 dots of the bank group, go to Configuration and set the Account Number and be sure in the Outgoing Payments tab XML Format is German
5. Create a new German company from Contacts with:
	1. Country as Germany
	2. VAT
	3. Account Number in the Bank Accounts by adding one line:
		1. example Account Number: DE65100500007201811026
		2. example Bank: BNP Paribas
		3. activate the Send Money button
7. Then go to Vendor > Payments and create a new one with Payment Method as SEPA Credit Transfer for the German company created
8. Go back and select the new payment from the list and click create batch and print it
9. In the XML of pain.001.001.03.(DE) file, the LEI tag should not be included.

### Cause of the issue:
The XML generation logic does not filter out the <LEI> element for older schema versions like pain.001.001.03, which do not support this tag.

### Reason to introduce the fix:
To ensure strict schema compliance and prevent bank rejections. The <LEI> element is now properly omitted from pain.001.001.03 files and restricted only to newer formats (e.g., pain.001.001.09) where it is valid.

opw-6428150

Forward-Port-Of: odoo/enterprise#127758