steps to reproduce:
-------------------
1. Install `l10n_cl`.
2. Create a new company and set Chile as the country.
3. Go to Accounting > Configuration > Journals.
4. Create a journal with type Purchase and enable Use Documents.
5. Go to Accounting > Vendors > Bills and create a bill.
6. Print Invoices / Invoices without payments.

issue:
------
The customer and company data are swapped (interchanged), and It is wrong from vendor bills point of view.

solution:
---------
The l10n_cl reports layout should only be applied to: 
- out_invoice or out_refund
- or when l10n_latam_document_type_id = (46) Electronic Purchase Invoice

**Before:**
<img width="762" height="425" alt="image" src="https://github.com/user-attachments/assets/e042485b-5d82-455f-9f34-03a0a9cdf5cc" />
**After:**
<img width="770" height="624" alt="image" src="https://github.com/user-attachments/assets/c5d09e58-bcf0-48ab-a0ae-0e37c0473a67" />



opw-4937097

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

Forward-Port-Of: odoo/odoo#224454

**Issue:**
- After https://github.com/odoo/odoo/commit/777cb220259e1c1529b960761a6f59ec6115038e we are not able to search for event/track/sponser when we have other language
selected except `en_US`.
- This is because of how `search_type` attribute is set in related templates.
- currently it gets translated as according to  website's language,
for e.g when website's language is `Spanish (AR) / Español (AR)`

'events' get translated to 'eventos' and
'track' get translated to 'sesión'
- hence the parameter for search get altered, failing the search.
https://github.com/odoo/odoo/blob/ac5ea3cbd075db650c8e538d59e24657a0f04bb9/addons/website/static/src/snippets/s_searchbar/000.js#L118-L121

**Step to reproduce:**
- Add another language except en_US, say ,spanish
- install website_event
- open events from website and switch language to spanish
- search for event

**Observation:**
- No search result

**Fix:**
- set the search_type attribute correctly, i.e using `t-valuef`

opw-4972519

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

Before this commit:
-------------------------
- The 'Print' button in the Purchase Order form always triggered the RFQ report,
  regardless of the order state.
- This caused confusion for users expecting the Purchase Order report when the
  order was already confirmed.

Steps to reproduce:
-------------------------
1. Install 'purhcase' module.
2. Confirm a purchase order (move it to the 'Purchase Order' state).
3. Click on 'Print' button .
4. Notice that the RFQ report is printed instead of the PO report.

Cause of the issue
-------------------------
- The print button was hardcoded to always prints the RFQ report—even for
  confirmed purchase orders.

After this commit:
-----------------------
- The system now prints the Purchase Order report when the order is confirmed.
- The Print button behavior dynamically changes based on the order state
- This improves user experience by ensuring the correct document is printed
  according to the current state of the order.

Task Id: 4905350

In _get_datev_account, the l10n_de_datev_main_account_id is determined by identifying a singular debit or credit account used in the journal entry. If there’s no unique account, it falls back to searching for a unique non-tax line among debit or credit lines.

In POS, however, there is the possibility of generating journal entries that break this flow:

- In a single POS session, add product A with tax 19% and product B with tax 7%.
- In the same session, refund product A.
- Close the session to generate the entries.

In the resulting entry, since both sale and refund are present, it is not possible to discriminate using debit and credit amounts alone, and as a result, the field l10n_de_datev_main_account_id is not populated.

Since account 1411 is always the one to be used for l10n_de_datev_main_account_id in this specific case, this commit adds a final fallback filter to select the correct line and ensure the field is populated.

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4915272)
opw-4915272

Forward-Port-Of: odoo/enterprise#92664

Currently, an error occurs when submitting the 'Send Email' form.

Steps to Reproduce:

 - Install the `website` and `web_studio` modules.
 - Go to `website` > `Click on Edit` > `Drag and drop form`.
 - click the form and in actions select the `more models`, and select
   `outgoing mails(mail.mail)` model and `save`.
 - `Submit` the form, and the error appears in the `logs`.

**Error:**
`KeyError: 'website_form_signature'`

**Cause:**
This error occurs when submitting the "Send Email" form from the
 website. By default, the form action is `"Send an E-mail"`, and when 
the user `changes` the form’s model to outgoing mails (mail.mail), 
which also has the action "Send an E-mail," the system checks the 
existing model [1] and retrieves it. Since `shouldRerender` is set to 
false, [2] is not executed, and as a result, the `email_to(hidden field)` 
is not present in the form. And the website_form_signature is added 
from [3], but due to the condition at [4], the code at [3] is not executed. 
When it is accessed at [5], KeyError is raised.

**Fix:**
This commit ensures that when the user changes the model, 
`rerenderXml` is executed so that the `hidden field` is also added.

[1]: https://github.com/odoo/enterprise/blob/359a1c546fc9e4bc113517bf6ea912a70a9ea123/website_studio/static/src/website_form_editor.js#L155-L156

[2]: https://github.com/odoo/enterprise/blob/359a1c546fc9e4bc113517bf6ea912a70a9ea123/website_studio/static/src/website_form_editor.js#L174-L178

[3]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L252

[4]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L236

[5]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/controllers/form.py#L88

sentry-6746753251

Forward-Port-Of: odoo/enterprise#93287