## Pull Request HOOT (PRHOOT) - part 18

Part 1: https://github.com/odoo/odoo/pull/152930
Part 2: https://github.com/odoo/odoo/pull/153018
Part 3: https://github.com/odoo/odoo/pull/153023
Part 4: https://github.com/odoo/odoo/pull/153203
Part 5: https://github.com/odoo/odoo/pull/153425
Part 6: https://github.com/odoo/odoo/pull/153700
Part 7: https://github.com/odoo/odoo/pull/154054
Part 8: https://github.com/odoo/odoo/pull/154579
Part 9: https://github.com/odoo/odoo/pull/155073
Part 10: https://github.com/odoo/odoo/pull/155639
Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135
Part 12: https://github.com/odoo/odoo/pull/156869
Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019
Part 14: https://github.com/odoo/odoo/pull/158916
Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971
Part 15.5: https://github.com/odoo/odoo/pull/166463
Part 16: https://github.com/odoo/odoo/pull/166311
Part 17: https://github.com/odoo/odoo/pull/168328

Enterprise: https://github.com/odoo/enterprise/pull/65657

This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details.

Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk.

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

**Steps to reproduce the bug:**
- Enable multi-step routes in the general settings.
- Go to the warehouse settings:
    - Select 3 steps for Outgoing Shipments.
- Create a storable product “P1”.
- Create a sales order with the following details:
    - Customer: Azure Interior
    - Product: 3 units of P1
- Confirm the sales order

- Go to the pick picking
- Set the quantity to 1 unit
- Validate the pick and create a backorder
- Go to the pack step and validate it

- Return to the pick backorder and validate it for 2 units
- Create a return from this backorder
- Validate the return
- Go back to the sales order

**Problem:**
The delivered quantity is set to -2 instead of 0. When the return is validated, the “_compute_qty_delivered” function is triggered, which uses both outgoing and incoming moves. The “_get_outgoing_incoming_moves” method is called to retrieve these moves. However, for return moves, we only check if the `location_dest` is not set to customer usage and if `move.to_refund` is not false, without verifying that the source location is from the customer.

opw-3962062

Currently, you cannot merge partners if they have bank accounts linked to payments.

### Steps to reproduce

* Install the `account` module.
* Create two partners having the same bank account number.
* Create and post payments for each of those partners.
* Attempt to merge those partners.

You should be met with the following message:
```
The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead.

Model: Journal Entry (account.move)
Constraint: account_move_partner_bank_id_fkey
```

### Cause
When merging partners, the system attempts to update all foreign keys referencing the partners being merged. In certain circumstances, this update violates unicity constraints. In such cases, the system simply deletes the records that can't be updated.

In our case, the `res_partner_bank` table has the following unicity constraint: `unique(sanitized_acc_number, partner_id)`. When we merge the two partners and the system attempts to update the `partner_id` field on `res_partner_bank`, the constraint is violated because both partners originally had the same account number. The system then tries to delete those bank accounts, but it fails because they are linked to payments (with an `ondelete restrict` clause).

### Fix

Identify the bank accounts that are duplicated between the source and destination partners, and merge them before merging the partners.

opw-3925952

Before this PR, redirecting the user to a page that would then be
rewritten according to the user's preferred language would make the
chatbot loop.

Steps to reproduce:
- Install website_helpdesk_livechat
- Install another language and translate the website
- Modify the /contactus rule to use the helpdesk live chat
- Create a question step that redirects the user to `/helpdesk/customer-
care-1`
- Navigate to the contactus page and change the website language to the
newly installed language
- Start the chatbot and proceed to the redirect step
- The chatbot gets stuck in a loop

This happens because the chatbot checks if the redirect link and the
URL are the same to determine if the redirection was already done.
However, since the URL is rewritten, it assumes it wasn't done and
redirects once again.

When a page is reloaded, the chatbot starts where it left off.
However, it should check that the step was not already processed
beforehand. This PR fixes this issue by skipping the already done
step.

opw-3987426

When you access the journal items list view with a `search_default_account_id` and try to modify the account on a line that has an analytic distribution, a validation error occurs.

### Steps to Reproduce

1. Install `account_accountant`.
2. Create an invoice with a line that has an analytic account and an account A.
3. Open the trial balance and access the journal items of account A using the three-dots menu.
4. Select the line from the invoice you created.
5. Attempt to change its account.

You will encounter the following validation error:

```
The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead.

Model: Analytic Line (account.analytic.line)
Constraint: account_analytic_line_account_id_fkey
```

### Cause

When accessing the journal items from the Trial Balance report, the `search_default_account_id` context key is automatically applied to filter the accounts you selected. However, using `search_default_` with a relational field also creates a `default_` context key for that field. Here, `default_account_id` is added to the context.

When changing the account on a move line that has analytic accounts, the system deletes the existing related analytic items and creates new ones. Analytic items have an `account_id` field. Due to the `default_account_id` context key intended for the journal items, the same key is erroneously applied to the newly created analytic item, leading to a validation error because of a foreign key constraint.

### Fix

I was thinking about cleaning the context but after discussing with JOL, we decided to only get rid of the problematic default key.

opw-3958980

Forward-Port-Of: odoo/odoo#168329

In commit [1], the "Themes Options" have been reorganized to make them
easier to find. With this relayout, the buttons style options have also
been modified in order to have a third choice "Flat", in addition to
"Fill" and "Outline". However, the way it was done causes some issues.

Indeed, it wrongly sets the `btn-(primary|secondary)-(outline|flat)` CSS
variables to `'True'` instead of the `true` boolean, and to `null`
instead of `false`, which is not correct. This happens because
`customizeButtonStyle` now sends boolean values to the `_makeSCSSCusto`
function, instead of strings representing these booleans. This results
in the backend RPC call setting the variables to the Python boolean
`True`, or to `null` in the falsy case because of the `"null"` default
value.

While it does not seem to break anything in general, there are issues
when using themes that redefine these variables (e.g. "Avantgarde",
"Enark", "Cobalt",...). Indeed, it is impossible to set the buttons
corresponding style to "Fill". This happens because choosing "Fill" is
supposed to set both variables to `false`, but because of the boolean
values being sent to `_makeSCSSCusto`, the value that is in fact set is
`"null"`. This therefore makes them fallback to the value defined in the
theme, forcing them to `true` and preventing the "Fill" style from being
applied.

This commit fixes these issues by properly giving string values to
`_makeSCSSCusto`. For already existing databases, all the variables that
have been set to `'True'` will have their value replaced by `true`,
thanks to the `o-map-omit` SCSS function. Note that the `'False'` case
is also added, in order to be consistent.

[1]: https://github.com/odoo/odoo/commit/388e4bb2bfcaebdd4ff30277fb49a034592d7086

opw-3957157

Forward-Port-Of: odoo/odoo#170015

Issue:
======
Image and icons changes and dropped snippets are not autosaved, changes
are lost when you switch tab.

Steps to reproduce the issue:
=============================
For Image and icon:
- Go to email marketing
- Choose a template with an image
- Update the image and click on another tab directly (A/B tests for
  example)
- Go back to mail body tab, the changes are not saved

For dropped snippets:
- Go to email marketing
- Choose any template
- Click on another tab (A/B tests for example)
- Go back to meil body tab
- Add snippet click directly on another tab
- Go back to mail body tab , the changes are not saved

Origin of the issue:
====================
For Image and Icon:
When we open the image media dialog, `_onWysiwygBlur` is called which
means we lost the focus from the editable view. Old updates are saved
because we call `commitChanges` but the updates after the change of the
image are not since we lost the focus of the wysiwyg. Switching to another
tab will not trigger `blur` event again so we loose the changes. (same
flow for icon change).

For dropped snippets:
The first switch of tabs will trigger the blur event and will commit
changes. When we switch again to the mail body tab, the focus isn't
on the editable, we drop the snippet , still no focus on the editable
so no `blur` event is called and we loose the changes again.

We call `commitChanges` on `onWillUnmount` but we don't pass the
paremeters from `mass_mailing_html_field` to its parent class so we
loose the `urgent` flag which is responsible to save the data before
destroying the component. Passing just the args in `commitChanges` will
produce another issue about `Component is destroyed`. To have a minimal
change in stable we just refocus on the wysiwyg on the mentioned 2 cases
so the updates will be applied when blurring the `wysiwyg`

Solution:
=========
Put the focus again in the editor's window.

Forward-Port-Of: odoo/odoo#167753

Currently we are unable to pay using viva wallet as the terminalID is not sent during the request.

Steps to reproduce:
-------------------
* Go to **Point of Sale**
* Under **Configuration**, select **Payment Methods**
* Create a new payment method and configure it for viva wallet
* In the shop setting, add this payment method
* Open shop session
* Make an order and try to pay with viva wallet
> Observation: There are some issues between us and Viva Wallet, try again
later. [{'type': 'missing', 'loc': ['body', 'terminalId'], 'msg': 'Field required', 'input': {'sessionId': '00007-001-0001 - c9a31bfb-b517-4e65-a1ee-b00a1d86731b', 'cashRegisterId': 'Mitchell Admin', 'amount': 206885, 'currencyCode': 978, 'merchantReference': '00007-001-0001 - c9a31bfb-b517-4e65-a1ee-b00a1d86731b/7', 'customerTrns': ' ', 'preauth': False, 'maxInstalments': 0, 'tipAmount': 0}, 'url': 'https://errors.pydantic.dev/2.6/v/missing'}]

Why the fix:
------------
As the error states, the request is missing the information about the terminal ID. That is due to the fact that starting from saas-17.1 parameters are loaded through the function `_load_data_params` and not `_loader_params_(...)`.

opw-3983997

Forward-Port-Of: odoo/odoo#170531

…nents

- In the Inventory app, go to Lots/Serial Numbers;
- Open any record;
- Click on the Traceability stat button;
- reload the page;

Before this commit, the message "No operation made on this lot." was
shown, even if there are operations. This occurs because the
TraceabilityReport lost the current model at reload (active_model).

Since [1] a new prop (a function called updateResId) was give to the
controllers components of the window actions to update the resId on the
action state and url, when needed. For instance, the form view after
saving a new record, will update the state and the url with the newly
created id.

Since [2], the prop was also given to the controllers components of the
client actions to update the resId.

There is a need to update more than the resId. This PR will introduce a
new prop with the aim to update the action state (updateActionState).
This props will allow the controller components to update the state and
push the new state to the router (updating the url).

In practical, this allows to push a new state in the url, keeping the
action service in sync. This synchronization between the router and the
action service allows the browser back/forward/reload to work as
expected.

Now, the TraceabilityReport can update the state, to add the
active_model to the url (as a query param), and be able to restore the
full state at reload.

[1]: https://github.com/odoo/odoo/commit/c63d14a0485a553b74a8457aee158384e9ae6d3f
[2]: https://github.com/odoo/odoo/commit/3ad4fd65387f60b524e5f786556963ead8ae9dfe

Forward-Port-Of: odoo/enterprise#65681
Forward-Port-Of: odoo/enterprise#65284

Currently, an error occurs while editing the customer form view when the '281.50' contact tag is not available

Step to produce:

- Install the 'l10n_be_reports' module.
- Go to the list view of 'Contact Tags' and delete the '281.50' record.
- Open the customer form view and try to edit it.

Stack Trace :

```
KeyError: ('ir.model.data', <function IrModelData._xmlid_lookup at 0x7fb69b00be20>, 'l10n_be_reports.res_partner_tag_281_50')
  File "odoo/tools/cache.py", line 103, in lookup
    r = d[key]
  File "<decorator-gen-5>", line 2, in __getitem__
  File "odoo/tools/func.py", line 87, in locked
    return func(inst, *args, **kwargs)
  File "odoo/tools/lru.py", line 34, in __getitem__
    a = self.d[obj]
ValueError: External ID not found in the system: l10n_be_reports.res_partner_tag_281_50
  File "odoo/http.py", line 2250, in __call__
    response = request._serve_nodb()
  File "odoo/http.py", line 1759, in _serve_nodb
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2055, in dispatch
    result = endpoint(**self.request.params)
  File "odoo/http.py", line 756, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "home/odoo/src/custom/default/saas_worker/controllers/main.py", line 2305, in smtp
    proxy.message_process(None, message)
  File "addons/mail/models/mail_thread.py", line 1369, in message_process
    routes = self.message_route(message, msg_dict, model, thread_id, custom_values)
  File "home/odoo/src/custom/trial/saas_trial/models/mail.py", line 369, in message_route
    return super(MailThread, self).message_route(message, message_dict, model=model, thread_id=thread_id,
  File "addons/mail/models/mail_thread.py", line 1093, in message_route
    self._routing_handle_bounce(message, message_dict)
  File "addons/mail/models/mail_thread.py", line 754, in _routing_handle_bounce
    rec_bounce_w_email._message_receive_bounce(bounced_email, bounced_partner)
  File "addons/mail/models/mail_thread_blacklist.py", line 104, in _message_receive_bounce
    record.message_bounce = record.message_bounce + 1
  File "odoo/fields.py", line 1376, in __set__
    records.write({self.name: write_value})
  File "home/odoo/src/enterprise/saas-17.2/l10n_be_reports/models/res_partner.py", line 26, in write
    tag_281_50 = self.env.ref('l10n_be_reports.res_partner_tag_281_50')
  File "odoo/api.py", line 584, in ref
    res_model, res_id = self['ir.model.data']._xmlid_to_res_model_res_id(
  File "odoo/addons/base/models/ir_model.py", line 2185, in _xmlid_to_res_model_res_id
    return self._xmlid_lookup(xmlid)
  File "<decorator-gen-43>", line 2, in _xmlid_lookup
  File "odoo/tools/cache.py", line 110, in lookup
    value = d[key] = self.method(*args, **kwargs)
  File "odoo/addons/base/models/ir_model.py", line 2178, in _xmlid_lookup
    raise ValueError('External ID not found in the system: %s' % xmlid)
```

An error occurs when the system tries to retrieve an external ID of the contact
tag  '281.50'at [1],  but it is not available.

link [1]: https://github.com/odoo/enterprise/blob/77c76fecda9b63e2fc17431a4cd3623650f93724/l10n_be_reports/models/res_partner.py#L26

To handle this issue, add 'raise_if_not_found=False' if the contact tag  '281.50' is
 not available.

sentry-5499490971

Forward-Port-Of: odoo/enterprise#64878

Impacted versions:

 - 17.0

Steps to reproduce:
 1. Install l10n_mx_edi module.
 2. Go to Company ESCUELA KEMPER URGATE.
 3. Go to Settings / Automatic Currency Rates.
 4. Run manually the currency rates.
 5. Go to Accounting / Customers / Invoices.
 6. Create a new invoice with the next values:
    - Customer: "INMOBILIARIA CVA"
    - Currency: USD - Product: Any but set the UNSPSC Category (any)
 7. Confirm the invoice.
 8. Click send and print.
 9. Check CFDI and click on Click send and print.
 10. Open the generated xml

Current behavior:
 - TipoCambio have many variations depending of product and currency value:

Example: June 17th: have:
| Product                   | Quantity | TipoCambio |
|---------------------------|----------|------------|
| [FURN_0006] Monitor Stand | 1        | 18.538484  |
| [FURN_0004] Letter Tray   | 1        | 18.538558  |
| [E-COM09] Large Desk      | 1        | 18.538498  |

Expected behavior:

 - TipoCambio (inside XML) should have the exchange value of the currency (invoiced). Example: June 17th should have 18.5385 (USD)

Inspired in: [l10n_mx_extended](https://github.com/odoo/enterprise/blame/f030d17e07ae7b10fe95e054eb27ba35101cfc96/l10n_mx_edi_extended/models/account_move.py#L178)

Forward-Port-Of: odoo/enterprise#64838

An error occurs when the system tries to access single values from multiple records at [1].

Traceback On Sentry:

```
ValueError: too many values to unpack (expected 1)
  File "odoo/models.py", line 5851, in ensure_one
    _id, = self._ids
ValueError: Expected singleton: iot.device(1, 2, 3, 4, 5, 6, 7, 8)
  File "odoo/http.py", line 2248, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1823, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1843, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1821, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1828, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2053, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 756, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 38, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 34, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/web/models/models.py", line 76, in web_save
    return self.with_context(bin_size=True).web_read(specification)
  File "addons/web/models/models.py", line 164, in web_read
    for vals in co_records.web_read(field_spec['fields'])
  File "addons/web/models/models.py", line 87, in web_read
    values_list: list[dict] = self.read(fields_to_read, load=None)
  File "odoo/models.py", line 3610, in read
    return self._read_format(fnames=fields, load=load)
  File "odoo/models.py", line 3821, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
  File "odoo/models.py", line 6608, in __getitem__
    return self._fields[key].__get__(self, self.env.registry[self._name])
  File "odoo/fields.py", line 1261, in __get__
    self.compute_value(recs)
  File "odoo/fields.py", line 1443, in compute_value
    records._compute_field_value(self)
  File "odoo/models.py", line 4934, in _compute_field_value
    fields.determine(field.compute, self)
  File "odoo/fields.py", line 100, in determine
    return needle(*args)
  File "home/odoo/src/enterprise/saas-17.2/quality_iot/models/iot.py", line 16, in _compute_qcp_test_type
    self.qcp_test_type = types.get(self.type, '')
  File "odoo/fields.py", line 1202, in __get__
    record.ensure_one()
  File "odoo/models.py", line 5854, in ensure_one
    raise ValueError("Expected singleton: %s" % self)

```

To handle this issue, Implement an iteration to iterate records.

sentry-5540606405

Forward-Port-Of: odoo/enterprise#65604

Issue -->

With a large number of `account.move.line` and `pos.order.line` records, methods `_get_tax_details`, `_get_gstr1_hsn_json` and `_set_details_pos_lines` do not perform well.

Solution -->

In `_get_tax_details` -->

Replace the journal items recordset with a set of ids to do deletions. Move the fetch to when it is actually needed.

In `_get_gstr_hsn_json` -->

Prefetch the l10n_in_code values on `uom.uom` records that are used in the for loop. This optimization prevents additional hits to the backend.

In `_set_details_pos_lines` -->

Fetch `product.product` records and all the `uom.uom` records before the for loop to prevent additional hits to the backend when trying to fetch `product_id.type`, `product_id.l10n_in_hsn_code` and `product_uom_id.l10n_in_code`

Benchmark -->

For about 110k journal items and 95k pos order lines, the current implementation takes about 2800 seconds to finish computation.

After the fix, the process takes about 300 seconds to finish.

opw-3895401

Forward-Port-Of: odoo/enterprise#65578
Forward-Port-Of: odoo/enterprise#62305

**Current behavior:**
A product that is tracked via serial will have all of its lots displayed in the Schedule gantt view instead of just the ones which are part of the order.

**Expected behavior:**
Only the lots corresponding to rented quants of a product will be displayed.

**Steps to reproduce:**
1. Enable `Rental Transfers` in settings

2. Create a rental order with 1 of the demo printer products (they are tracked via SN already) and confirm

3. Open the rental schedule view, see that for the new order, all of the printers in stock with a SN are displayed

**Cause of the issue:**
Previously, the commit 8c90c7493ec was merged to fix an issue where you could not group by serial numbers in the schedule view for orders that were created while the 'Rental Transfers' setting was enabled.

This introducted this bug by not actually specifying which `lot_id`s of a product were part of an order- so it selected ALL `lot_id`s of ANY product in a rental order.

**Fix:**
Add a join on `StockMove` so we can select `lot_id`s which are exclusively in `StockMoveLine`s that are linked to `StockMoves` which correspond to a rental order.

opw-3977685

Forward-Port-Of: odoo/enterprise#64662
Forward-Port-Of: odoo/enterprise#64118

**Steps to reproduce:**
- Install account_reports
- Go to "Accounting / Accounting / Journals / Journal Entries"
- Create a new entry:
  * Accounting Date: [a date from last month]
  * Journal Items: [2 lines using accounts that are not of type "asset_cash" or "liability_credit_card"]
- Post the entry
- Create a journal:
  * Type: Miscellaneous
  * Default Account: [one of the accounts used for the created entry]
- Go to "Accounting / Reporting / Statement Reports / Cash Flow Statement"

**Issue:**
The default account from the newly created misc journal appears in the report even if it is not a bank-type (or cash-type) account.

**Cause:**
Previously, only account moves from a bank or a cash journal were taken into account in the report.
The default account of these journals is forced to "asset_cash" type. However, a fix has been made to allow some account moves from miscellaneous journals, which can have any type of account as default account.

**Solution:**
Only allow default accounts having "asset_cash" or "liability_credit_card" as type.

opw-3867312

Forward-Port-Of: odoo/enterprise#63989

When renting with deliveries, if it's about a kit with subkit and
shared component, the return will not be correct

To reproduce the issue:
1. In Settings, enable "Rental Transfers"
2. Create a kit K as follow:
   - K
     - C1
       - C2
       - C3
     - C2
3. Confirm a rental with 1 x K

Error: in the return, there are two lines for each C2, which makes
sense since each line is linked to a different kit. However, the
quantity on each line is incorrect: 2 instead of 1

When generating the SM of the return, we first generate the values
https://github.com/odoo/odoo/blob/8db471e74238481a5429f0fcf8fbce1c0960ff27/addons/stock/models/stock_rule.py#L205-L206
In `_push_prepare_move_copy_values`, at some point, we adapt the
quantity of the returned SM based on the other SM of the SO. To do
so, we only consider the SM with the same product (among other
conditions). This criterion is not strict enough: for instance, when
looking at C2 of K, we take its quantity *and* we also take C2 of C1,
which is incorrect. Of course, we do the same when looking at C2 of
C1, hence the incorrect quantities.

OPW-3996074

…atch payment

Create a branch company and switch to it
Activate SEPA Direct Debit (SDD) and add Creditor Identifier
Activate Batch Payments
Add a SEPA bank account on the Bank journal
Add a SEPA bank account on a partner
Create SEPA mandate for the partner bank account on the Bank journal
Make an invoice to the partner
Register payment with payment method "SEPA Direct Debit"
Go to Accounting>Customer>Payments
Select the payment > Hit 'Create Batch'
Validate creted batch

Issue: A traceback will raise
```py
  File "[...]/enterprise/account_sepa_direct_debit/models/account_payment.py", line 117, in _sdd_xml_gen_header
    create_xml_node_chain(InitgPty, ['Id','OrgId','Othr','Id'], company_id.sdd_creditor_identifier)
  File "[...]/odoo/tools/xml_utils.py", line 109, in create_xml_node_chain
    current_node.text = last_node_value
  File "src/lxml/etree.pyx", line 1039, in lxml.etree._Element.text.__set__
  File "src/lxml/apihelpers.pxi", line 747, in lxml.etree._setNodeText
  File "src/lxml/apihelpers.pxi", line 735, in lxml.etree._createTextNode
  File "src/lxml/apihelpers.pxi", line 1538, in lxml.etree._utf8
TypeError: Argument must be bytes or unicode, got 'bool'
```

This occurs because we assign the credit identifier to the branch
company, but when validating the batch the system exports the
sdd xml using the company found on the journal
https://github.com/odoo/enterprise/blob/88d25bd184585143f39011947263e928b14551e5/account_batch_payment/models/account_batch_payment.py#L343
so the parent company that have no Creditor Identifier defined

After adding the Creditor Identifier on the parent company and trying
again the validation an error will block the action

"""Trying to generate a Direct Debit XML file containing payments from
another company than that file's creditor."""

opw-3943103

### Original issue:
When creating a debit note on a bill from a purchase order with the option 'copy_lines', the field 'Purchase Order' in the lines is not populated.

### Steps to reproduce:
- Install Purchase, Inventory apps and the l10n_co_edi module
- Switch to a Colombian company
- Go to Accounting > Configuration > Accounting > Journals
- In the Vendor Bill journal > Advanced Settings, uncheck the 'Electronic invoicing UBL 2.1 (Colombia)' option
- Go to Purchase > Orders > Purchase Orders, create a new one and confirm it
- 'Receive Products' and 'Validate'
- Go back to the Purchase order
- 'Create Bill' and 'Confirm'
- From actions, choose 'Debit Note'
- In the wizard, tick 'Copy Lines', select a 'Concepto Nota de Débito' and 'Create Debit Note'
- Display the Purchase Order field in the Invoice Line tab is visible, it should not be populated

### Cause:
This bug is due to another fix that have been badly made because no tests were there. Most of the content of enterprise/l10n_co_edi/wizards/account_debit_note.py:_prepare_default_values is not called when it is supposed to and called when it's not. 

In the 'Create Debit Note' wizard view there is an option to copy the lines and so, autopopulate them. This option is not displayed for Debit Notes generated from Credit Notes because the lines would be negative. 
(https://github.com/odoo/odoo/blob/47eff65afdba3a2a8283342d8b636657f1fac317/addons/account_debit_note/wizard/account_debit_note_view.xml#L16) 

The logic of this option is located in the module account_debit_note: https://github.com/odoo/odoo/blob/2a02ba4de1c823bcdef0e8b6b6373fa27b5587a1/addons/account_debit_note/wizard/account_debit_note.py#L64, the line_ids value is filled with a default value if copy_lines is False. If left empty, the lines are copied from the original account.move. 

In this commit, https://github.com/odoo/enterprise/commit/c738f14d4ac88d508b6b75747788f5867eb71a68 we are trying to manually populate the lines of a debit note when it is generated from a credit note. But the code is made so that the lines are always copied. 

So in this other commit https://github.com/odoo/enterprise/commit/fa65a1ff8cb7333a3339438513d1eeb5d5f9690e there is a correction to take the copy_lines into consideration. But it breaks the precedent fix as Debit Notes of Credit Notes always have copy_lines to False. So the code to copy the lines manually is actually never called for Debit Notes of Credit Notes (which is the only case we want it to be called in). But is called every time copy_lines is set to True therefore ignoring the actual code to copy the lines in the module account_debit_note. 

In the context of the bug of this PR, the problem comes from the manual copying of lines that is missing the value purchase_order_id.

### Solution:
Changing the logic of the _prepare_default_values function:
- if not a Colombian company or not a debit note of a credit note, stop here
       - we let the logic in account_debit_note copy the lines (or not) depending on copy_lines.
- if the debit note comes from a credit note, we copy the lines and return

With this flow, the lines will not be copied manually so the value purchase_order_id will be populated.

opw-3962301

Forward-Port-Of: odoo/enterprise#65215
Forward-Port-Of: odoo/enterprise#64689

An error occurs when the system tries to access single values from multiple records at [1].

Traceback On Sentry:

```
ValueError: too many values to unpack (expected 1)
  File "odoo/models.py", line 5851, in ensure_one
    _id, = self._ids
ValueError: Expected singleton: iot.device(1, 2, 3, 4, 5, 6, 7, 8)
  File "odoo/http.py", line 2248, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1823, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1843, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1821, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1828, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2053, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 756, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 38, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 34, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/web/models/models.py", line 76, in web_save
    return self.with_context(bin_size=True).web_read(specification)
  File "addons/web/models/models.py", line 164, in web_read
    for vals in co_records.web_read(field_spec['fields'])
  File "addons/web/models/models.py", line 87, in web_read
    values_list: list[dict] = self.read(fields_to_read, load=None)
  File "odoo/models.py", line 3610, in read
    return self._read_format(fnames=fields, load=load)
  File "odoo/models.py", line 3821, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
  File "odoo/models.py", line 6608, in __getitem__
    return self._fields[key].__get__(self, self.env.registry[self._name])
  File "odoo/fields.py", line 1261, in __get__
    self.compute_value(recs)
  File "odoo/fields.py", line 1443, in compute_value
    records._compute_field_value(self)
  File "odoo/models.py", line 4934, in _compute_field_value
    fields.determine(field.compute, self)
  File "odoo/fields.py", line 100, in determine
    return needle(*args)
  File "home/odoo/src/enterprise/saas-17.2/quality_iot/models/iot.py", line 16, in _compute_qcp_test_type
    self.qcp_test_type = types.get(self.type, '')
  File "odoo/fields.py", line 1202, in __get__
    record.ensure_one()
  File "odoo/models.py", line 5854, in ensure_one
    raise ValueError("Expected singleton: %s" % self)

```

To handle this issue, Implement an iteration to iterate records.

sentry-5540606405

Forward-Port-Of: odoo/enterprise#65604

Currently, an error occurs while editing the customer form view when the '281.50' contact tag is not available

Step to produce:

- Install the 'l10n_be_reports' module.
- Go to the list view of 'Contact Tags' and delete the '281.50' record.
- Open the customer form view and try to edit it.

Stack Trace :

```
KeyError: ('ir.model.data', <function IrModelData._xmlid_lookup at 0x7fb69b00be20>, 'l10n_be_reports.res_partner_tag_281_50')
  File "odoo/tools/cache.py", line 103, in lookup
    r = d[key]
  File "<decorator-gen-5>", line 2, in __getitem__
  File "odoo/tools/func.py", line 87, in locked
    return func(inst, *args, **kwargs)
  File "odoo/tools/lru.py", line 34, in __getitem__
    a = self.d[obj]
ValueError: External ID not found in the system: l10n_be_reports.res_partner_tag_281_50
  File "odoo/http.py", line 2250, in __call__
    response = request._serve_nodb()
  File "odoo/http.py", line 1759, in _serve_nodb
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2055, in dispatch
    result = endpoint(**self.request.params)
  File "odoo/http.py", line 756, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "home/odoo/src/custom/default/saas_worker/controllers/main.py", line 2305, in smtp
    proxy.message_process(None, message)
  File "addons/mail/models/mail_thread.py", line 1369, in message_process
    routes = self.message_route(message, msg_dict, model, thread_id, custom_values)
  File "home/odoo/src/custom/trial/saas_trial/models/mail.py", line 369, in message_route
    return super(MailThread, self).message_route(message, message_dict, model=model, thread_id=thread_id,
  File "addons/mail/models/mail_thread.py", line 1093, in message_route
    self._routing_handle_bounce(message, message_dict)
  File "addons/mail/models/mail_thread.py", line 754, in _routing_handle_bounce
    rec_bounce_w_email._message_receive_bounce(bounced_email, bounced_partner)
  File "addons/mail/models/mail_thread_blacklist.py", line 104, in _message_receive_bounce
    record.message_bounce = record.message_bounce + 1
  File "odoo/fields.py", line 1376, in __set__
    records.write({self.name: write_value})
  File "home/odoo/src/enterprise/saas-17.2/l10n_be_reports/models/res_partner.py", line 26, in write
    tag_281_50 = self.env.ref('l10n_be_reports.res_partner_tag_281_50')
  File "odoo/api.py", line 584, in ref
    res_model, res_id = self['ir.model.data']._xmlid_to_res_model_res_id(
  File "odoo/addons/base/models/ir_model.py", line 2185, in _xmlid_to_res_model_res_id
    return self._xmlid_lookup(xmlid)
  File "<decorator-gen-43>", line 2, in _xmlid_lookup
  File "odoo/tools/cache.py", line 110, in lookup
    value = d[key] = self.method(*args, **kwargs)
  File "odoo/addons/base/models/ir_model.py", line 2178, in _xmlid_lookup
    raise ValueError('External ID not found in the system: %s' % xmlid)
```

An error occurs when the system tries to retrieve an external ID of the contact
tag  '281.50'at [1],  but it is not available.

link [1]: https://github.com/odoo/enterprise/blob/77c76fecda9b63e2fc17431a4cd3623650f93724/l10n_be_reports/models/res_partner.py#L26

To handle this issue, add 'raise_if_not_found=False' if the contact tag  '281.50' is
 not available.

sentry-5499490971

Impacted versions:

 - 17.0

Steps to reproduce:
 1. Install l10n_mx_edi module.
 2. Go to Company ESCUELA KEMPER URGATE.
 3. Go to Settings / Automatic Currency Rates.
 4. Run manually the currency rates.
 5. Go to Accounting / Customers / Invoices.
 6. Create a new invoice with the next values:
    - Customer: "INMOBILIARIA CVA"
    - Currency: USD - Product: Any but set the UNSPSC Category (any)
 7. Confirm the invoice.
 8. Click send and print.
 9. Check CFDI and click on Click send and print.
 10. Open the generated xml

Current behavior:
 - TipoCambio have many variations depending of product and currency value:

Example: June 17th: have:
| Product                   | Quantity | TipoCambio |
|---------------------------|----------|------------|
| [FURN_0006] Monitor Stand | 1        | 18.538484  |
| [FURN_0004] Letter Tray   | 1        | 18.538558  |
| [E-COM09] Large Desk      | 1        | 18.538498  |

Expected behavior:

 - TipoCambio (inside XML) should have the exchange value of the currency (invoiced). Example: June 17th should have 18.5385 (USD)

Changes:
- Avoid create query to search mx currency

OPW-3985223

Related PR: #64838