mark_urbanpiper_prep_order_as_printed() raised ValueError when the
'urbanpiper_printed' flag was already set, to stop the same order from
printing its preparation ticket twice (https://github.com/odoo/enterprise/pull/103894,
Task-5353283).

Accepting an UrbanPiper order fires this RPC from two places for the
same order: synchronously from TicketScreen, and again via the
DELIVERY_ORDER_COUNT bus notification the accept flow itself
broadcasts. Under load, both requests race for the row lock; Odoo's
retrying() replays the loser on lock contention, and by the time it
replays the winner has already committed, so the loser hits the
already-printed branch and raises. The raise is an unhandled
ValueError, so it surfaces as a 500 and fails any tour that accepts
an order (test_frontend.py, test_order_receipt.py),
intermittently and CI-timing-dependent only.

The only caller (pos_store.js: _sendDeliveryOrderForPreparation)
already wraps the RPC in try/catch and treats a caught exception
exactly like a falsy return value: either way it just skips sending
the ticket to preparation. No other code reads or writes
urbanpiper_printed, and no webhook path calls this method, so
returning False is behaviorally identical for every real caller and
safe to make the default.

This also removes the mark_urbanpiper_prep_order_as_printed_patch
monkeypatch added alongside the original raise in test_01_order_flow:
it existed solely to swallow this exact ValueError for that one tour,
which is no longer needed now that the method itself is idempotent.

runbot error: 941514

Forward-Port-Of: odoo/enterprise#125840

Since `company_id` on `worksheet.template` changed due to this a973d7d from a Many2many to a Many2one field.

For example, in v17, a single worksheet template linked to 3 companies via the m2m field was returned as 1 record when opening Design Template. After the upgrade in v18, company_id became m2o, and the same data is split into 3 separate records (one per company).

When trying to add a customization via Studio, the search [fetches](https://github.com/odoo/enterprise/blob/18.0/worksheet/controllers/main.py#L12) records based on the model set on the worksheet. In the new version, Studio
[creates](https://github.com/odoo/enterprise/blob/18.0/worksheet/models/worksheet_template.py#L112)
 a new model, but for existing records the
model is the same across the 3 worksheet records tied to the same template. This causes the search to match all 3 records and raise a SingletonError.

```py
Traceback (most recent call last):
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2856, in __call__
    response = request._serve_db()
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2331, in _serve_db
    raise self._update_served_exception(exc)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2329, in _serve_db
    return service_model.retrying(serve_func, env=self.env)
  File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 188, in retrying
    result = func()
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2384, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2599, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_http.py", line 353, in _dispatch
    result = endpoint(**request.params)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 838, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/src/enterprise/19.0/industry_fsm_report/controllers/main.py", line 9, in edit_view
    action = super().edit_view(view_id, studio_view_arch, operations, model, context)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 838, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/src/enterprise/19.0/worksheet/controllers/main.py", line 17, in edit_view
    worksheet_template_to_change._generate_qweb_report_template()
  File "/home/odoo/src/enterprise/19.0/worksheet/models/worksheet_template.py", line 490, in _generate_qweb_report_template
    new_arch = self._get_qweb_arch(worksheet_template.model_id, report_name, form_view_id)
  File "/home/odoo/src/enterprise/19.0/worksheet/models/worksheet_template.py", line 460, in _get_qweb_arch
    if 'name' in row_node.attrib and row_node.attrib['name'] not in self._get_qweb_arch_omitted_fields() and row_node.attrib['name'] in form_view_fields:
  File "/home/odoo/src/enterprise/19.0/worksheet/models/worksheet_template.py", line 378, in _get_qweb_arch_omitted_fields
    'x_%s_id' % self.res_model.replace('.', '_'), 'x_name',  # redundant
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1657, in __get__
    record.ensure_one()
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5942, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: worksheet.template(3, 14, 18)
```

OPW: 6389190

Forward-Port-Of: odoo/enterprise#126773

Steps to Reproduce:
1. Configure Payment Term (Accounting > Configuration > Payment Terms) containing multiple installments.
2. Create a Customer Invoice with this Payment Term.
3. Post the invoice.
4. Register a payment and fully reconcile one of the installments.
5. Navigate to the customer's Follow-Up Report (Accounting > Reporting > Partner Ledger > Report: Follow-Up Report).
6. Navigate to remaining open installment/account move line for that invoice.
7. Turn On or Off the No Follow-Up toggle for the invoice.

An error occurs when enabling or disabling the No Follow-Up toggle.

Issue:
Enabling or disabling the No Follow-Up toggle on a remaining open installment in the Follow-Up Report raises a server error when the invoice contains multiple installments and one or more installments are already fully reconciled.

Root Cause:
The Follow-Up Report only loads and sends non-fully reconciled account move lines from the JavaScript side through all_line_ids. In action_toggle_no_followup(), when the selected line belongs to an invoice, the code retrieves all receivable/payable lines of the invoice, including fully reconciled installments:

```
move.line_ids.filtered(
    lambda line: line.account_type in ('asset_receivable', 'liability_payable'),
)
```

The method then attempts to map every receivable/payable line to a report line ID using aml_id_to_line_id. Since fully reconciled installments are not present in all_line_ids, they are missing from the mapping dictionary, causing a KeyError when accessing:

`aml_id_to_line_id[line.id]
`

Fix:
Restricted the impacted lines to those present in the report by adding a check that the account move line exists in aml_id_to_line_id before performing the mapping:

```
lambda line: line.account_type in ('asset_receivable', 'liability_payable')
             and line.id in aml_id_to_line_id
```


opw-6245448

Forward-Port-Of: odoo/enterprise#126156

[FIX] l10n_ch: fix default contract type

This task is runbot error fix that occured from 19.0 to 19.2

Bug reproduction:

1 - Go to version 19.0, install l10n_ch_hr_payroll_account 2 - Execute test_version_timeline_auto_save_tour tour test 3 - It fails in .o_arrow_button_wrapper[data-tooltip^='Contract:'] step

Bug cause:

1 - When l10n_ch_hr_payroll_account is installed:

    1.1 - contract type becomes "Permanent contract with monthly salary"
    1.2 - the employee is not swiss but it has this CH contract type

2 - data-tooltip starts with Permanent contract instead of contract

    2.1 - Tour fails

3 - contract_type_id is overwritten in swiss modules

    3.1 - Default is assigned without looking to the country of self.env

Bug solution:

1 - If the country is not swiss, the default is assigned as False

    1.1 -> fixed in l10n_ch_hr_payroll/hr_version

    1.2 instead of assigning swiss contract type to the non-swiss emp.

Note: This is fix from saas-18.4 to master.

task-6392040

runbot error: https://runbot.odoo.com/odoo/runbot.build.error/941358