> This is a backport of the merged https://github.com/odoo/odoo/pull/235565 - with a couple of improvements & adaptations to the test files.

This commit adds helpers and improves on the way we assert XML files in `AccountTestInvoicingCommon` and all accounting test that extend from it. From now on, all accounting test code that assert an XML tree/string to an XML file should call the `assert_xml` helper, and design their test file name/location/etc. around this framework.

This approach has a few major benefits:

Assert / Save XML

When testing XML files, we often need to perform create/read/update operations on the asserted XML to make sure it corresponds to the most updated/intended data. Previously, to save something to an XML, a developer would need to write their own local helpers to save the XML in the right directory. This was cumbersome and error-prone, so we decided to design a helper that allows developer to immediately save AND/OR update the asserted XML: to save/update an XML, we can simply add `SAVE_XML` as an additional test tags.

Better test naming and optional subfolder management

To better organize test files, the `assert_xml` method allows us to write just the test key name (without `.xml`), and the framework will automatically get the XML to assert/save from the `test_files` directory. An optional `subfolder` parameter is also added to allow writing to specific subfolder within `test_files`.

Better `___ignore___` management in assertion XMLs

Sometimes, we want to ignore a few XML node that are not relevant, or have content that are not deterministic (changes on every test run). To handle this, previously, developers would need to modify the assertion XML content by hand or write their own local script to do so.

With this new framework, we just need to add an `ignore_schema.xml` file somewhere in the `test_files` directory. If put inside a subfolder, it will be applied with more priority towards the XML that are put on that specific subfolder.

Save "pure" XML (before applying `___ignore___`) in temporary folder

When calling `SAVE_XML`, before applying the ignore patches, the XML will be saved in a temporary folder (same folder as the screenshots for tours), so that developers can use them in external tests in the future, and for any other saving reasons.

In addition, this commit also:

- add `extra_tags` helper to save all the common tags for EDIs, for a better way to enable `EXTERNAL_MODE` testing inspired by `l10n_mx_edi`
- convert some non-assert XML test helpers into a class method
- canonicalize the XML to ensure consistency of the generated test files following the C14N Version 2 standard. (Deterministic namespaces location, sorted attributes, etc.)

task-4891206

Due to more number of moves during compute it out of memory while getting the country_code per move. So, just pre fetch the country code. So, it won't go for computing that and will be available in memory

records
```
sagu_3267671=> select count(id) from account_move;
  count
---------
 1034179
(1 row)
```

```
File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 102, in determine
return needle(*args)
File "/home/odoo/src/odoo/17.0/addons/l10n_rs_edi/models/account_move.py", line 85, in _compute_l10n_rs_edi_is_eligible
move.l10n_rs_edi_is_eligible = move.country_code == 'RS' and move.is_sale_document() and move.l10n_rs_edi_state in (False, 'sending_failed')
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1219, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1401, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 105, in determine
return needle(records, *args)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in _compute_related
values = [first(value[name]) for value in values]
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in <listcomp>
values = [first(value[name]) for value in values]
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6695, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 2933, in __get__
return super().__get__(records, owner)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1182, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3824, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3874, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3984, in _fetch_query
self.env.cache.insert_missing(fetched, field, values)
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 1135, in insert_missing
field_cache.setdefault(id_, val)
MemoryError
```

upg-3267671
opw-5246681


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

Forward-Port-Of: odoo/odoo#235919

Step to reproduce:
- for Spain localization, in developer mode:
- Go to Balance sheet 
- Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES)
- Click on the parameters button
- Click on the "Accounts Coverage Report"

Observation:
- we receive a traceback
```
psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "%(balance_sheet_11700_account)d"
LINE 1: ...ccount_tag" WHERE ("account_account_tag"."id" IN ('%(balance...
```

Cause:
- few records used a wrong format style for values of `domain_formula`
- These faulty domains were not [evaluated](https://github.com/odoo/odoo/blob/2070e30c540a066fb80851527e5e54e97fb23c4b/addons/account/models/account_report.py#L450-L453), but inserted into database as is.
- when browsing account.tag record using these domain, record ids were expected,
instead we got its string representation , causing traceback 

https://github.com/odoo/enterprise/blob/8fa6fb27d2a79ee299361b281dc82182feee5860/account_reports/models/account_report.py#L5679-L5680

Fix:
- we fix the data file, which is properly evaluated and stored in database.
- Manifest's data file order is changed, so that account tags is loaded first.

opw-5224114

Forward-Port-Of: odoo/enterprise#98745

When using many Viva terminals linked to the same DB, there could be many serialization errors due to concurrent writes to the DB. This is because the webhook controller writes to the
`viva_wallet_latest_response` field of the payment method. The webhook request would be automatically retried later, but this could result in duplicate notifications being sent to the POS, or notifications being handled too late.

This commit stops using the `viva_wallet_latest_response` field, instead sending the information directly via the websocket to the POS. Only the required information is sent to reduce the size of the message.

In addition, there are two other minor fixes:
- In the event that the initial payment request to Viva failed, the POS will no longer poll the payment status (this resulted in a Session ID not found error).
- The webhook controller will now check the event type it receives, and only process the 'Transaction Payment Created' events. This should prevent any unintended behaviour if other webhooks are set up in Viva.

opw-5226966

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

### Steps to reproduce:

- Go to Contacts > Contacts > New
- Change it to "individual" type
#### > The "parent_id" field should have a place holder "Company Name..."

### Cause of the issue:

The `parent_id` field of the res.partner form uses the `res_partner_many2one` widget:
https://github.com/odoo/odoo/blob/58b888992f80a58fecdb92e23fea0050f2178faf/odoo/addons/base/views/res_partner_views.xml#L164-L166 and is therefore relying on the `PartnerAutoCompleteMany2XField`. However, this template tries to recover its placeholder from the `placeholder` attribute of the Component:
https://github.com/odoo/odoo/blob/58b888992f80a58fecdb92e23fea0050f2178faf/addons/partner_autocomplete/static/src/xml/partner_autocomplete.xml#L41-L50 even thought this attribute is not defined and the placeholder should be recovered from its props:
https://github.com/odoo/odoo/blob/60e0529b98098b019ade09aad97cc6e359bc0755/addons/web/static/src/views/fields/relational_utils.xml#L35-L38

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

Steps to Reproduce
===================
1. Upload more than 40+ files in a folder. (One page displays upto 40 docs)
2. Use the checkbox to select all files on the page (this selects only 40 files)
3. Click the 'Select All' button in the control panel to select all 40+ files.
4. Now, try duplicating or moving them to the trash.
=> Only the first 40 selected files (on the single page) are considered for
   action, not all the selected files.

Technical
==========
For documents control panel action we have custom handling for selecting records
and executing action. We use `model.root.selection` which only consider records
in current page, case of select all records from other pages is missed here.

After this PR
==================
- All selected records are considered for the actions
- Added custom `getResIds` method to get filtered `resIds` as per domain.

Note: `getResIds` in DynamicList doesn't have custom domain feature so create
our own as per use case

Task-4700841

To reproduce:
=============
- with `hr_contract` and `helpdesk` installed
- create a user with 2 resources in 2 different companies
- add the user as member of a helpdesk team of company A
- enable auto assignment on the team
- try to create a ticket on that team -> error

Problem:
========
When computing working intervals for resources of the team members,
we were considering all resources of the user, even those not in the same
company as the helpdesk team. Which lead to access errors when trying
to read data from the other company.
This issue was not caught before as we were never reading data from the
resources, until this [commit](https://github.com/odoo/odoo/commit/79a559c9741410ad861c107e395b2fc486da95e8)
where we try reading `employee_id` of the resource.

Solution:
=========
Filter resources to keep only those in the same company as the helpdesk team.

P.S:
====
the removed test was trying to test assigning ticket to user that is not
in the same company as the helpdesk team, which is not correct so the test was removed.

opw-[2749232](https://www.odoo.com/web#id=2749232&view_type=form&model=project.task)

BUG 1:
---------
**steps to reproduce**:
1. Install documents
2. Open any document
3. Go to Action > Rename
4. Rename the document
5. Preview it and read the name showed there

**issue**:
When previewing the document, it still shows the old attachment name.

**observation**:
When renaming a document, only the document name was updated. The attachment name remained unchanged, which caused inconsistencies:

1. In the All Records section, the document name is displayed correctly. https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/views/documents_document_views.xml#L130

2. But in the Preview, the old attachment name was still shown, as it is taken from the attachment:
https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/static/src/views/hooks.js#L373-L383

**solution**:
Use the document name when previewing it

BUG 2:
---------
**steps to reproduce**:
1. Install Documents.
2. Open any document.
3. Rename it via the chatter.
4. Try renaming it again via the details panel.

**issue**:
After renaming a document twice through the details panel, the preview still displayed the old document name.

**cause**:
On the first rename, the [insert](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/core/document_service.js#L96-L129)) method creates a new [store.Document](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/views/hooks.js#L367-L393) record with the updated attachment name. However, The write method (used by chatter) skips reloading the record and linked attachment data on the second rename.

Unlike the Rename button, which uses web_save (and triggers a record reload via web_read), the chatter directly calls write without refreshing the attachment.

**Solution**:
Ensure the preview uses the document name from the document record, keeping it consistent after multiple renames via the details panel.


**Example:** Try to rename a "Invoice.pdf" document to "Invoice_rename.pdf"
<details>
    <summary>Click here to see the results:</summary>
    Before:
    <img src="https://github.com/user-attachments/assets/563b7fb9-709c-4651-8492-032a7f353730"/>
    After:
   <img src="https://github.com/user-attachments/assets/6fc6bdfe-dd1e-4f3c-aaf7-821c44fd135d"/>

</details>

opw-5065433

Steps to reproduce:
-------------------------
1. Install the Accounting module.
2. Create and confirm a Vendor Bill.
3. Click on Pay and create a payment for the bill.
4. Open the created payment using the smart button.
5. Delete the payment or click on Reset to Draft.


Observation:
-------------------------
1. On deleting the payment:
The Vendor Bill still shows the "In Payment" status even after the payment is
deleted.
2. On resetting the payment to draft:
The Vendor Bill also remains in the "In Payment" status instead of reverting to
"Not Paid".

This behavior is not observed for customer invoices, where the payment state
updates correctly in both cases.


Issue:
-------------------------
1. Delete case:
In the `unlink` method,
https://github.com/odoo/odoo/blob/b991f766e28dc71f8627fdfbf2d59589d9707d3a/addons/account/models/account_payment.py#L938-L945
the `linked_invoices` variable only includes invoices that are reconciled
(i.e., their journal items are matched). Since the Vendor Bill is not yet
reconciled, it is excluded from recomputation. Hence, its `payment_state`
remains unchanged.

2. Reset to draft case:
In the `_compute_payment_state` method,
https://github.com/odoo/odoo/blob/b991f766e28dc71f8627fdfbf2d59589d9707d3a/addons/account/models/account_move.py#L1162-L1163
the compute depends on the state of reconciled payments. However, since these
payments are not reconciled, the compute method is not triggered, and the
payment state remains outdated.


Solution:
-------------------------
Added `matched_payment_ids.state` in the depends of the
`_compute_reconciled_payment_ids` method to ensure it recomputes correctly when
payment state changes on setting payment to draft or deleting payment

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

A field on `account.analytic.line` is created for every plan using the `id` of the plan to make the names unique, like `x_plan{id}_id`. The plan that has the ID of the `analytic.project_plan` parameter does not get a dynamic field, it uses `account_id`. If you change the system parameter for analytic.project_plan, the plan with the corresponding value will now use `account_id,` and the plan that corresponds to the previous default value will have no corresponding field on `account.analytic.line`.

So, when the project plan system parameter changes, the dynamic fields that are created for each analytic plan (apart from the project one) do not get updated.

Steps:

1. Set the `analytic.project_plan` system parameter to a value other than `1`
2. Enable `Analytic Accounting` setting under `Accounting > Analytic`
3. Create a sales order with a service product that creates a project.
4. Confirm sales order
5. Traceback: `ValueError: Invalid field account.analytic.line.x_plan1_id in leaf 'x_plan1_id', 'in', [23])`


We now extend the write method on `ir.config_parameter` so that when the value of the analytic.project_plan is changed the dynamic fields on `account.analytic.line` are properly added and removed. This solution always creates a field for the previous value and deletes a field for the new value so that no plan ever has two fields referencing it.  

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

Forward-Port-Of: odoo/odoo#231981