In the post-init stock configuration we update the chart accounts to add stock-related fields using `_load_data`. The values provided by `_get_stock_account_account` only contain partial data meant to enrich accounts created by the chart template.

The update should only be performed on accounts that already exist. Otherwise, the load creates new account records with most fields left null (e.g. account_type), which is not the intention here.

This fix filters the updates to existing accounts only, so the step only enriches accounts created by the chart template and avoids creating incomplete account records.

steps to reproduce:
- Install account app in a odoo 19 db
- Delete account 'stock valuation'
- Install `stock_account` module

```py
File "/home/odoo/src/odoo/19.0/addons/stock_account/__init__.py", line 13, in _post_init_hook
    _configure_stock_account_company_data(env)
  File "/home/odoo/src/odoo/19.0/addons/stock_account/__init__.py", line 79, in _configure_stock_account_company_data
    ChartTemplate._load_data({
  File "/tmp/tmplqo7rmpu/migrations/account/0.0.0/pre-ensure-deferred-accounts.py", line 36, in _load_data
    return super()._load_data(data, *args, **kwargs)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 697, in _load_data
    created_records[model] = self.with_context(lang='en_US').env[model]._load_records(all_records_vals)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5194, in _load_records
    records = self._load_records_create([data['values'] for data in to_create])
  # [...]
  File "/home/odoo/src/odoo/19.0/odoo/sql_db.py", line 433, in execute
    self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "account_type" of relation "account_account" violates not-null constraint
DETAIL:  Failing row contains (2315, null, 1, 1, null, null, null, t, f, f, 2026-02-17 05:53:58.84587, 2026-02-17 05:53:58.84587, no, f, null, null, null
```

opw-5913248
upg-3879881

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

Forward-Port-Of: odoo/odoo#249211

Currently, an error occurs when the user checks the report line errors.

**Steps to Reproduce:**

 - Install the `l10n_hk_hr_payroll_empf` module with demo data.
 - Switch to the `Hong Kong` company.
 - Go to `Payroll` > `Reporting` > `Hong Kong` > `eMPF Contributions`.
 - Create a record by setting the `Scheme` and adding a `contribution line`.
 - Ensure that the employee and payslip fields are empty in the contribution line.
 - Click on `Validate`, then click on the `error icon` on the report line.

`ValueError: Expected singleton: hr.version()`

This error occurs when the user manually adds a line and checks the errors on it.. The system 
attempts to open the employee record from the version [1], but the version is not set [2] on the 
line because there is no employee. And it raise the error [3].

This commit ensures that when checking errors, if the version is not set on the line, a UserError 
is raised, prompting the user to set the employee on the line. It also corrects a typo in the status 
message.

[1]- https://github.com/odoo/enterprise/blob/7889b2b0b3d13b32e6e36e616e20379d8c8f8812/l10n_hk_hr_payroll_empf/model/l10n_hk_empf_contribution_report_line.py#L219

[2]- https://github.com/odoo/enterprise/blob/7889b2b0b3d13b32e6e36e616e20379d8c8f8812/l10n_hk_hr_payroll_empf/model/l10n_hk_empf_contribution_report_line.py#L142-L156

[3]: https://github.com/odoo/odoo/blob/98855c6b70df24500babe6027109aa9e17431ec1/addons/hr/models/hr_version.py#L609-L611

Forward-Port-Of: odoo/enterprise#116607

### Description

`account.full.reconcile` has no `unlink()` override, so when the record is removed PostgreSQL nulls `full_reconcile_id` on the linked `account.move.line` rows via the default `ondelete='set null'` FK rule, but `matching_number` is a plain `fields.Char` that nobody recomputes. The line ends up with a decimal `matching_number` (the id of the deleted full) while `full_reconcile_id` is `False`, no partials point to it and `amount_residual` is the full open amount. The line is rendered as reconciled in the UI even though the reconciliation is gone.

This PR mirrors `account.full.reconcile.create()`'s contract on the unlink path: invoke `_update_matching_number(amls)` after the records are removed, so every previously-linked line is cleaned. The integrity check `_constrains_matching_number` is also extended with `full_reconcile_id` in its `@api.constrains` tuple, so future ORM writes that desync the field surface the inconsistency immediately.

### Steps to reproduce

A single-call reproducer on a vanilla `19.0-all` runbot, no third-party modules:

```python
company = env.ref('base.main_company')                       # USD company
partner = env['res.partner'].create({'name': 'demo'})

# Foreign currency rates with a sharp move so the payment generates an FX diff
env['res.currency.rate'].create([
    {'currency_id': env.ref('base.EUR').id, 'name': '2026-01-15', 'rate': 0.90, 'company_id': company.id},
    {'currency_id': env.ref('base.EUR').id, 'name': '2026-03-15', 'rate': 1.20, 'company_id': company.id},
])

inv = env['account.move'].create({
    'move_type': 'out_invoice', 'partner_id': partner.id,
    'currency_id': env.ref('base.EUR').id,
    'invoice_date': '2026-01-15', 'date': '2026-01-15',
    'journal_id': env['account.journal'].search([('type','=','sale')], limit=1).id,
    'invoice_line_ids': [(0,0,{'name':'x','quantity':1,'price_unit':1000.0})],
})
inv.action_post()

env['account.payment.register'].with_context(
    active_model='account.move', active_ids=inv.ids
).create({'payment_date': '2026-03-15'}).action_create_payments()

recv = inv.line_ids.filtered(lambda l: l.display_type == 'payment_term')
full = recv.full_reconcile_id
assert full and recv.matching_number == str(full.id)

full.unlink()                                                # the bug detonator
recv.invalidate_recordset()
assert recv.matching_number is False                         # FAILS without this PR
assert not recv.full_reconcile_id
```

Before the PR `recv.matching_number` keeps the decimal id of the deleted `account.full.reconcile`. After the PR it is cleared together with `full_reconcile_id`.

### Diagnostic query

```python
env['account.move.line'].search([
    ('matching_number', '!=', False),
    ('matching_number', 'not like', 'P%'),
    ('matching_number', 'not like', 'I%'),
    ('full_reconcile_id', '=', False),
])
```

Returns lines in the orphan state on any database.

### Impact

Observed on a real production database: 142 `account.move.line` records in this orphan state accumulated over ~13 days of normal accounting activity, on receivable, payable and bank accounts. All those lines display as reconciled in the UI while the underlying reconciliation is gone. Empty `account.full.reconcile` rows are also left behind.

### Tests

`addons/account/tests/test_account_move_reconcile.py::TestAccountMoveReconcile::test_full_reconcile_unlink_clears_matching_number`

### Linked

* Bug report: closes #264790

The change is a single-file 13-line `unlink()` override plus a one-character extension to an existing `@api.constrains` tuple. No data migration is needed for new databases; existing orphans on databases that hit the bug before the fix lands can be cleaned with a one-off:

```python
env['account.move.line'].search([
    ('matching_number', '!=', False),
    ('matching_number', 'not like', 'P%'),
    ('matching_number', 'not like', 'I%'),
    ('full_reconcile_id', '=', False),
]).write({'matching_number': False})

env['account.full.reconcile'].search([
    ('reconciled_line_ids', '=', False),
    ('partial_reconcile_ids', '=', False),
]).unlink()
```

Forward-Port-Of: odoo/odoo#264805

The delivery transfer for a product tracked by serial number is not linked to the POS order when there is no available stock. When validating a POS delivery in real time, stock can split the transfer into a completed picking and a backorder (e.g. one line fully delivered with lots, another serial-tracked line with no stock and no serial number).

Steps to reproduce:
-------------------
* Setup two products: one tracked by qunatity with some quantity on-hand an other tracked by SN but no quantity on-hand
* Open Pos
* Sell in one order, both products without providing SN
* Validate payment
* Open Inventory: two deliveries sould exist under Inventory Overview of PoS Orders

> Observation:
The first picking shows the POS order as Source Document but the backorder has no source document and is not linked to the POS order.

Why the fix:
------------
Pos Origin (Source Document, POS order, session) was only written on the pickings returned by `_create_picking_from_pos_order_lines`, which did not include pickings created during `_action_done()`. Extend the write to the initial pickings and their backorders so every transfer stays tied to the originating `pos.order`.

opw-6090606

Forward-Port-Of: odoo/odoo#266111
Forward-Port-Of: odoo/odoo#259370

# How to reproduce
- Install the Events, Porject & CRM apps
- Create two event A & B with tickets that can be purchased
- Go to Events > Configuration > Lead Generation
- Create a Lead Generation Rule with :
	- Create : Per Order
	- When : Attendees are created
	- Event : None
- Create a new quotation with two lines :
	- Product : Even Registration for event A 1st, then B
- Confirm the SO

# The problem
A traceback will appear

# Cause of the issue
When confirming the SO, we create `event.registrations`s that will check for
lead generation rules and create or update `crm.lead`s accordingly :
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_registration.py#L35

We will then group the registrations by leads & grouping model :
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_lead_rule.py#L166

For all groups, if the lead does not exist, we create one :
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_lead_rule.py#L184-L187

`_get_lead_values()` works fine with multiple `event.registrations`s, but crashes
when those registrations does not have all the same event, which is our case :
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_registration.py#L170

# Proposed solution
Since we have multiple events and leads are associated to a single event :
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/crm_lead.py#L11

We group the registrations by event and create multiple leads accordingly

opw-6167518

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

Forward-Port-Of: odoo/odoo#265017

Before this commit, for DBs with a very large number of products it was possible for the thread to run out of memory when importing an invoice or a bill.
The reason is that the name on product.product is non stored and computed. This leads to tons of recomputes, which in turn leads to reads and stores in cache of the underlying `product.product`, which down the line uses up all of the available memory for the thread.

The proposed method uses batches instead of a `search_fetch` as the latter would not solve the recompute problem and hence the underlying memory problem.
Another alternative approach could be going straight for the `product.template.name`, but that approach might introduce a loss of precision or functionality when searching for products at invoice import.

Here is the memory graph from memray before the fix:
<img width="1106" height="450" alt="opw-6168737-memray-pre-fix" src="https://github.com/user-attachments/assets/f971dc4d-aa09-41e3-a8c5-e5ca53f9786d" />

And here is the same graph after the fix:
<img width="1106" height="450" alt="opw-6168737-memray-post-fix" src="https://github.com/user-attachments/assets/0a784cdc-9b40-498b-bbcb-89114eec1ec9" />

We can see a much lower peak memory usage after the fix. We an also observe that the memory complexity shifts from `O(n)` to `O(1)`, with `n` being the number of `product.product` records stored in the DB.

For both presented graphs, the same, unaltered database was tested. The database contains 389 467 `product.product` records.

opw-6168737

Forward-Port-Of: odoo/odoo#265639
Forward-Port-Of: odoo/odoo#262591

**Steps to reproduce:**
- create a new company A
- in the branch tab, create a new branch A for this company
- create a warehouse for the company A and a warehouse for 
the branch A
- from the company A, in settings for the 'fiscal localization' set 
Package : Generic Chart of account, if not already set
(to have account journals).

From the branch A:
- create a storable product with standard perpetual category
- set a cost of 10
- confirm a PO for 10 and validate delivery
- navigate to 'inventory valuation'

Make sure the branch A is the main company, but 
both branch A and company A are selected: 
- click on generate entry
- click on the 'Other Info' tab

**Current behavior:**
The company of the account move is the parent company
(Company A)

**Expected behavior:**
It should be the branch A. 
(As it is the case if only branch A is selected when clicking 
on "Generate entry")
IAs a consequence, f you click on 'Inventory Valuation' on the 
top left to go back to the view, you will have an access error. 

**Cause of the issue:**
When computing the company_id on the account move, 
move.journal_id.company_id will be the parent company because 
the journal_id of the branch is the one of the parent company 
(by default).
So we will call _accessible_branches() on the parent company.
https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/addons/account/models/account_move.py#L878-L881
Inside __accessible_branches(), 'accessible' will be based on 
self.env.companies 
https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/odoo/addons/base/models/res_company.py#L430-L439
(which is based on 'allowed_company_ids' in the context.
https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/odoo/orm/environments.py#L266)
So the return value of __accessible_branches()
will be a list with 2 ids, the one of the parent 
company and the one of the branch. 
And we will use the first element of this list,
which will be the parent company_id, in _compute_company_id
to set the company of the account move.

**fix:**
When fetching the data for the inventory valuation view, 
only the data from the main company selected matters,
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/report/stock_valuation_report.py#L13

Therefore, when creating the account move the company
of the move should be the main company.
We already did something very similar in this PR
https://github.com/odoo/odoo/pull/262776 where we 
modified the context in action_close_stock_valuation()
before calling _action_close_stock_valuation()
https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/stock_account/models/res_company.py#L56

opw-6144294

Forward-Port-Of: odoo/odoo#263828

**PROBLEM**
In some case, because of rounding issues, the withholding base amount can be bigger than the total amount of the invoice, which should not be the case.

**STEP TO REPRODUCE**

1. Install l10n_pe_edi
2. Create an invoice with those 2 lines: qty: 300, unit_price: 0.481936, tax: VAT 18% + 3% IGV Withholding qty: 300, unit_price: 0.747376, tax: VAT 18% + 3% IGV Withholding
3. Confirm the invoice, and send the xml (if this fail, you may have to change the name of the invoice, using odoo inspector or other means).
4. Open the xml, and notice the base amount for the allowance on the document level is 435.18 which is bigger than the invoice payable amount.

**CAUSE**
We exclude the withholding taxes to compute the invoice taxInclusiveAmount. When computing this amount, we round the line base and the tax total of the VAT 18% tax leading to the result of 435.17. When creating the allowance node for the Withholding taxes, the base used for the withholding taxes is the sum of the line base, and the tax total of previous tax NOT rounded. There is no easy way to change the withholding tax computation, so we just limit the base to not be bigger than the invoice total when there is rounding issues.

opw-6010388

Forward-Port-Of: odoo/enterprise#113689