**Problem:**
Starting the timer on a task that is linked to a sale order item produces a timesheet that is not linked to it, and the Billable toggle is missing from the timer.

**Steps to reproduce:**
1. Install Timesheets and Sales
2. Open a task whose Sales Order Item is set
3. Start the timer from the Timesheets systray
4. Save it and open the resulting timesheet

**Current behavior:**
The Sales Order Item is empty. The Billable toggle only appears after removing and re-adding the task in the timer.

**Expected behavior:**
The timer is billable on the task's sale order item as soon as it is opened.

**Cause of the issue:**
`_get_timesheet_pre_filled_form_data` returns only `project_id` and `task_id`. The timer form merges that pre-fill over `timesheet_default_values`, which `lazy_session_info` computes once per session from `account.analytic.line.new()`
- a record with no project and no task, so `so_line`, `allow_billable` and `has_available_so` are all `False` in it. Because the pre-fill carries none of those keys, they keep the task-independent session values: the timesheet stays unlinked from the sale order item, and the Billable toggle stays hidden since it is displayed from `has_available_so`.

**Fix:**
The pre-fill endpoint is the only place that knows which task the timer is being opened on, so it is where the task-dependent values have to be resolved. Reading them off a new timesheet built with that project and task keeps the endpoint generic - it returns whatever `_get_aw_timesheet_fields_specification` declares, so the sale fields stay owned by sale_timesheet_enterprise rather than being named in timesheet_grid.

Dropping the session defaults instead was rejected: they are also the only source of `date`, `user_id` and `company_id` for the timer record, and removing them makes saving fail on the required Date field.

opw-6423577

Forward-Port-Of: odoo/enterprise#127800

### This is a revision of #119399 which had to be reverted.

Original issue
-----
Deliveries cannot be validated using DPD with Sendcloud, users get an error.

Steps to reproduce
-----
- Set up Sendcloud DPD
- Create a SO
	- Interntional customer
		- Some VAT number
	- Some product
	- Add sendcloud delivery
- Confirm SO
- Validate the linked picking

> Error: “The receiver VAT number is missing; please provide it to continue”

Issue's cause
-----
Tax numbers should be included in the `customs_information` field of the request as per the API

https://sendcloud.dev/api/v2/parcels/create-a-parcel-or-parcels#body-one-of-0-parcel-customs-information-tax-numbers

For the `vat_label` field, we have to force the language to English in the context because the field is translated by default, but sendcloud only accepts the english names (eg French "TVA" is not accepted, expected value is "VAT").

https://github.com/odoo/odoo/blob/d1d1610332a1596d026fb0a42ec236d1a79c71cc/odoo/addons/base/models/res_country.py#L75

Revert cause
-----
The vat_label field is marked for translation (translate=True)

https://github.com/odoo/odoo/blob/d1d1610332a1596d026fb0a42ec236d1a79c71cc/odoo/addons/base/models/res_country.py#L75

So if the user has the DB in french for example, we are sending "TVA" instead of "VAT" in the name field.

Other issues
-----
- We need to provide an actual fallback for `customs_invoice_nr`. As it stands, if we create a new delivery it cannot be validated because Sendcloud doesn't accept for the field to be empty.
- Same for `name`, we need to provide an actual fallback.

-----
Ticket:
opw-6250860

Forward-Port-Of: odoo/enterprise#127425
Forward-Port-Of: odoo/enterprise#124245

A running task/ticket timer can sometimes stutter, show negative values, and track the wrong elapsed time.

### Steps to reproduce

On a record with a timesheet timer (for example, a Field Service task):

1. Start the timer and let it run for about 15-20 seconds.
2. Stop it and confirm the dialog.
3. Start it again. This creates a new `timer_start`.
4. Reload the page.

The timer starts jumping every second between two different values. As it keeps running, it can even show negative values such as `00:00:-57`.

If the problem does not appear right away, repeat steps 2-4 a few times. It usually shows up after a few stop/start/reload cycles.

### Cause

The timer shown in the button bar is the `timer_start_field` widget. It starts a `setInterval` that updates a shared `TimerReactive` object once per second.

While a form is loading, Odoo renders it several times in a row (for example: a first render, another when the chatter is loaded, and another when the record data comes back from the server). Rendering a form builds all of its fields to produce the display, so each of these renders creates its own `timer_start_field`. Odoo keeps and mounts only the render that ends up on screen; the earlier ones are thrown away before being mounted.

The interval is started while the field renders, from the record observer set up in `setup`, before the field is mounted. So the fields that are later thrown away also start an interval. Those intervals keep running for the rest of the session. Each one updates the same shared `TimerReactive` object using the `timer_start` it was created with.

As long as every instance has the same `timer_start`, they all write the same value and the problem stays hidden. After the timer is stopped and started again, the old instances keep the old `timer_start` while the mounted one uses the new one. Every second they overwrite each other's value, so the timer jumps between two different elapsed times. When the instance with the newer `timer_start` writes right after one with an older start, it tries to show a smaller elapsed time than what is already there, and the subtraction in `TimerReactive` produces a negative number of seconds.

### Fix

Move the per-second timer update into a `useEffect`. The effect only runs after the field is mounted, and Owl automatically cleans it up when the field is unmounted or when `timer_start` or `timer_pause` change.

This means fields that are destroyed before they are mounted never start an interval, so only the mounted field updates the shared timer.

`onRecordChange` no longer starts or stops the interval. It only updates the displayed timer value to match the current record.

opw-6209405

Forward-Port-Of: odoo/enterprise#128071
Forward-Port-Of: odoo/enterprise#126242

The embedding model deprecation cron starts by searching for chunks that are embedded using a model that hasn't been deprecated. However, due to an optimization in the ORM (optimize_type_selection), the search doesn't return any result.

A domain that uses the 'not in' operator is converted by the optimization to use the 'in' operator and the values are replaced by the difference between the available selection values (self._selection) and the values in the domain. So, given that the selection values of the embedding_model field are the non deprecated embedding models and the search domain of the cron is ['embedding_model', 'not in', non deprecated embedding models] , the final domain will be
['embedding_model', 'in', non deprecated models list - non deprecated models list] = ['embedding_model', 'in', []] which will retrieve nothing from the DB because all records have an embedding_model.

The main issue is that the optimization assumes that the available selection values are static. However, an old embedding model can be deprecated and a new one added which makes the optimization fail. So, the selection values are changed to be computed dynamically which will be skipped by the optimization.

On a database that was not created with demo data, registering for Peppol using the "Odoo Demo ID" identification fails instead of activating the local demo/training registration. The registration wizard correctly shows "Demo" as the EDI mode once that identifier is selected, but submitting the registration still reaches out to the real Peppol Access Point, which the wizard cannot connect to, so the registration is blocked.

Steps to reproduce:
-------------------
* Create a new database without demo data (e.g. a regular Odoo Online database, not a /trial one)
* Install Accounting, open the Peppol registration wizard
* Select "Odoo Demo ID" as the Electronic Address Scheme and fill in the other required fields
* Click on Register

> Observation:
The wizard displays "Demo" as the EDI mode, yet registering raises "Failed to connect to Odoo Peppol Proxy." Manually creating the system parameter `account_peppol.edi.mode` with the value "demo" makes the registration succeed, but that parameter is only ever set automatically when the module's demo data is loaded.

Why the fix:
------------
The wizard's displayed `edi_mode` correctly resolves to "demo" for the Odoo Demo ID EAS, but `handle_demo` - which decides whether `_can_connect`/`_create_connection` run against the local mock or the real Peppol proxy - recomputed the mode itself without passing that EAS along, so it could only detect demo mode via the system parameter or an already existing proxy user. Made `handle_demo` pass the record's own `peppol_eas` as `temporary_eas`, aligning its detection with what the wizard already displays.

opw-6448276

Steps to reproduce:
- Make sure you have 2 or more languages installed
- Install events and website app
- For the website, apply the languages you have in settings
- Make sure website default language is different from backend language
- Create an event
- Go to the event's website page through the smart button
- Switch the language of the frontend to one that is different from backend
- Translate (alter) the description for this language
- Click on the outlook icon to download the ics

Current Behavior:
The ics will contain a description based on the backend's chosen language

Expected Behavior:
The ics will contain a description based on the website's chosen language.
If there's no website, it will use the browser's language

Clarification:
The current behavior is confusing for users as they will expect the ics to match
the description of the current webpage which is dependent on the frontend's
selected language. This current behavior also contradicts the google calendar
behavior which grabs the description based on the frontend's selected language.

The endpoints for retrieving the ics file now utilize the website=True flag to
take advantage of IrHttp._match which will automatically set the context
language to be the frontend's rather than the backend language. We want
the ics file to be in the frontend language for visual consistency. Also,
send_email_reminder function does not require with context for this reason

opw-6235320

Forward-Port-Of: odoo/odoo#280520
Forward-Port-Of: odoo/odoo#271968

A running task/ticket timer can sometimes stutter, show negative values, and track the wrong elapsed time.

### Steps to reproduce

On a record with a timesheet timer (for example, a Field Service task):

1. Start the timer and let it run for about 15-20 seconds.
2. Stop it and confirm the dialog.
3. Start it again. This creates a new `timer_start`.
4. Reload the page.

The timer starts jumping every second between two different values. As it keeps running, it can even show negative values such as `00:00:-57`.

If the problem does not appear right away, repeat steps 2-4 a few times. It usually shows up after a few stop/start/reload cycles.

### Cause

The timer shown in the button bar is the `timer_start_field` widget. It starts a `setInterval` that updates a shared `TimerReactive` object once per second.

While a form is loading, Odoo renders it several times in a row (for example: a first render, another when the chatter is loaded, and another when the record data comes back from the server). Rendering a form builds all of its fields to produce the display, so each of these renders creates its own `timer_start_field`. Odoo keeps and mounts only the render that ends up on screen; the earlier ones are thrown away before being mounted.

The interval is started while the field renders, from the record observer set up in `setup`, before the field is mounted. So the fields that are later thrown away also start an interval. Those intervals keep running for the rest of the session. Each one updates the same shared `TimerReactive` object using the `timer_start` it was created with.

As long as every instance has the same `timer_start`, they all write the same value and the problem stays hidden. After the timer is stopped and started again, the old instances keep the old `timer_start` while the mounted one uses the new one. Every second they overwrite each other's value, so the timer jumps between two different elapsed times. When the instance with the newer `timer_start` writes right after one with an older start, it tries to show a smaller elapsed time than what is already there, and the subtraction in `TimerReactive` produces a negative number of seconds.

### Fix

Move the per-second timer update into a `useEffect`. The effect only runs after the field is mounted, and Owl automatically cleans it up when the field is unmounted or when `timer_start` or `timer_pause` change.

This means fields that are destroyed before they are mounted never start an interval, so only the mounted field updates the shared timer.

`onRecordChange` no longer starts or stops the interval. It only updates the displayed timer value to match the current record.

opw-6209405

Forward-Port-Of: odoo/enterprise#126242

Problem:
On a flexible working schedule, a time off of a few hours (neither a full nor a half day) was treated as a full day off. The Attendance list then reported the whole day's attendance as overtime, and the Time Off gantt grayed out the entire day instead of only the leave's hours.

Steps to reproduce:
1. Give an employee a flexible working schedule (e.g. 8h/day) with an overtime ruleset based on the contract's expected hours.
2. Record a 2-hour time off, then an 8-hour attendance on the same day.
3. Observe the attendance reports 8 hours of overtime instead of 2.

Current behavior:
A partial time off makes the whole day count as extra hours.

Expected behavior:
Only the hours actually taken off reduce the day's expected hours.

Cause:
For a flexible schedule, _handle_flexible_leave_interval expands a leave to the whole day. The override already narrows full-day and half-day leaves, but any other number of hours fell through to that full-day expansion. The expanded interval is subtracted from the day's expected hours in _work_intervals_batch, so they drop to zero and every worked hour becomes overtime.

Fix:
A leave of an arbitrary number of hours should only remove the hours it actually covers, so it keeps its requested interval instead of being stretched to the whole day.

opw-6291536

Forward-Port-Of: odoo/enterprise#127449
Forward-Port-Of: odoo/enterprise#123778

### Steps to reproduce:
- Install 'whatsapp', and 'crm_livechat'
- Configure a WhatsApp channel and receive a message to create a conversation in Discuss
- Open the WhatsApp conversation in Discuss
- Click on the 'Create Lead' smart button
- Check the created lead
> The Customer/Contact field is empty

### Cause of Issue:
When a lead is created from a Discuss conversation, `_convert_visitor_to_lead` in `crm_livechat` attempts to set the lead's customer. It does this by checking if the channel has `livechat_customer_partner_ids`. However, in whatsapp discuss conversations, the client is saved in `whatsapp_partner_id` and `livechat_customer_partner_ids` is empty. https://github.com/odoo/odoo/blob/29556fda44b9f1e6cf08129443ca47fa6cda34f9/addons/crm_livechat/models/discuss_channel.py#L54-L64

### Fix:
Overrode `_convert_visitor_to_lead` in the `whatsapp` module to properly populate the `partner_id` of the created lead if it wasn't already set and the channel has a `whatsapp_partner_id` instead of checking for the client in `crm_livechat`, which will raise an "Attribute Error", since `crm_livechat` isn't dependent on `whatsapp`.

**Note**: No automated test could be added for this fix. Testing the `_convert_visitor_to_lead` method from the `whatsapp` module requires the `crm_livechat` module to be installed to access the base method implementation

opw-6371274

Steps to reproduce:

- Create a product with a bom and 2 operations
- Create an MO for 1 unit of that product
- Confirm the MO
- On the bom, delete the second operation and modify the first operation on anything else than the company, name or workcenter
- Go back to the MO, click the "Update Bom" button
> The second operation is not unlinked and the first operation is not
  updated

Cause of the issue:

The `action_update_bom` updates the move raws and operations of the MO via the `_link_bom`:
https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L1214-L1218 For draft MO's all the work of these updates is done via the compute methods and by deleting all the records unrelevant to the new bom: https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L2603-L2626 And, in that case all the workorders that are not linked to an operation of the bom are expected to be deleted. However, when the MO is not in draft, the update of operations is expected to be performed here: https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L2647-L2664 However, since the operation of the bom has been deleted, the workorder that is expected to be deleted is not linked to any operation and hence does not satisfy the condition to be deleted:
https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L2663-L2664 Concerning the non update of operations, it happens because the MO's operation are only updated on the three fields: `company_id`, `workcenter_id`, `name`:
https://github.com/odoo/odoo/blob/31df5033e31c193b4576ef37dfbc5fc683817bc5/addons/mrp/models/mrp_production.py#L2647-L2664 https://github.com/odoo/odoo/blob/31df5033e31c193b4576ef37dfbc5fc683817bc5/addons/mrp/models/mrp_production.py#L2628-L2629 However, many other cahnges can and are actually relevant.

Note:

Prior to commit 80e6ed658fb43584bc2fad673ca40d9af6cf0ab6 operations were archived on boms rather than deleted:
https://github.com/odoo/odoo/blob/4a5270218fe6fd7d30edb6d684b3340dc7423bab/addons/mrp/views/mrp_routing_views.xml#L53-L55 As such they would still be linked to an operation (but unrelated to the present values of the bom) and hence would fall into the condition of being unlinked from the MO.

Since the bom operations are no longer archived there is no way to determine if an operation used to be linked to a bom and we therefore need to chose between deleting all operations unrelated to the present bom or to keep them all (when the MO has been confirmed).

Community: https://github.com/odoo/odoo/pull/269747

opw-6285878
opw-6261738

Forward-Port-Of: odoo/enterprise#126938
Forward-Port-Of: odoo/enterprise#120709

Steps to Reproduce:
1. Install l10n_do_edi on a company configured with Dominican Republic localization.
2. Leave the company's address / Document Layout details unconfigured (Settings > Companies > Configure Document Layout).
3. Enable 'Use Documents' on the sales journal and create a Customer Invoice with Document Type = Electronic Consumer Invoice (e-CF).
4. Confirm/post the invoice and print/preview the PDF.
5. Observe the company name is printed twice in the header.

Root Cause:
l10n_do_edi.custom_header explicitly renders the company name via:
    [`<span t-field='o.company_id.partner_id.name'/>`](https://github.com/odoo-dev/enterprise/blob/c23d526f53402471dccbbf9460cfd04ce377b5d0/l10n_do_edi/views/report_invoice.xml#L10)

immediately followed by a call to the core template web.company_address_list:
   [` <t t-call='web.company_address_list'/>`](https://github.com/odoo-dev/enterprise/blob/c23d526f53402471dccbbf9460cfd04ce377b5d0/l10n_do_edi/views/report_invoice.xml#L11)

When the company's address/Document Layout is empty, `company.is_company_details_empty` evaluates True, causing `web.company_address_list` to fall back to a contact widget with `fields=['address', 'name']` — which renders the company name a second time. custom_header assumed `company_address_list` would never render the name itself, which does not hold in this empty-address state, resulting in the duplicate. This only surfaces on e-CF document types, since custom_header is only set via l10n_do_edi.report_invoice_document's routing (_get_name_invoice_report()), which standard invoices never hit.

Solution:
Made the explicit name span in `l10n_do_edi.custom_header` conditional on whether the company's details are configured. `web.company_address_list` (core, shared across other reports, left untouched) already renders the company name via its contact widget fallback when the address is empty — so the explicit span now only prints the name when `company_details` is populated, avoiding both sources printing it at once.

Result:
Company name now renders exactly once on e-CF invoices, regardless of whether the company's address/Document Layout is configured.

opw-6430918

Currently, when the user scraps a component during a manufacturing order, the system can still consume the same lot/serial number during production, leading to double consumption even when the product is no longer available in inventory.

## Steps to produce:
- Install the Manufacturing app.
- Enable 'Work Orders' and 'Lots & Serial Numbers' from the settings.
- Create two products: 'Car' and 'Engine'.
- Configure 'Engine' to be tracked by 'Serial Number' and update its on-hand quantity to 2 using two different serial numbers.
- Create a Bill of Materials (BoM) for 'Car' with 'Engine' as a component.
- Create a work center named 'Car Assembly'.
- Go to Manufacturing > Configuration > Operations.
- Create a new manufacturing operation named 'Engine Insertion' with:
  - Bill of Materials: 'Car'
  - Work Center: 'Car Assembly'
- Create and confirm a new Manufacturing Order (MO) for 'Car'.
- Open the related work order and start the operation.
- From Actions > Scrap, scrap the 'Engine' serial number currently reserved for the MO.
- Click Produce All.
- Open the product view for 'Engine' and check the on-hand quantity.

## Observed behavior:
Even after the user scraps the product during the work order, the system still allows the same serial-numbered component to be consumed during production. This results in negative on-hand quantities and creates inconsistencies in inventory and manufacturing data.

## Root cause:
When the user starts the work order, the `button_start` function [1] is called. This sets the `qty_producing` field, which triggers its inverse method `_set_qty_producing`. As part of this flow, the component move is marked as picked at [2]. This, in turn, triggers the inverse method of the `picked` field, which marks all move lines in the move as picked, as shown at [3].

Later, when the user scraps the same serial-numbered product, the `do_scrap` function is called. This invokes `_action_done` at [4], which further calls `_action_done` on the move lines at [5]. During this process, `_free_reservation` is executed at [6].

However, because the move lines were previously marked as picked, they no longer satisfy the domain condition at [7]. As a result, they are not unlinked at [8]. This leaves the reservation intact and eventually causes the scrapped component to still be consumed when the user produces the quantity on the manufacturing order.

**Why does this issue not occur in saas-19.3?**
This issue no longer occurs in saas-19.3 after this [commit](https://github.com/odoo/odoo/commit/bb56600bfc81b9a6573a867df93a706de8154d0a), which removed the manual consumption field. As a consequence, move lines are no longer marked as picked when starting work orders, preventing the inconsistent state that leads to this issue.
[1]:
https://github.com/odoo/odoo/blob/8f5d7b5cd0c3e1808375baef8f0834d3f2e27a75/addons/mrp/models/mrp_workorder.py#L659-L660 [2]:
https://github.com/odoo/odoo/blob/8f5d7b5cd0c3e1808375baef8f0834d3f2e27a75/addons/mrp/models/mrp_production.py#L1417-L1421 [3]:
https://github.com/odoo/odoo/blob/8f5d7b5cd0c3e1808375baef8f0834d3f2e27a75/addons/stock/models/stock_move.py#L287-L290 [4]:
https://github.com/odoo/odoo/blob/8f5d7b5cd0c3e1808375baef8f0834d3f2e27a75/addons/stock/models/stock_scrap.py#L152-L158 [5]:
https://github.com/odoo/odoo/blob/8f5d7b5cd0c3e1808375baef8f0834d3f2e27a75/addons/stock/models/stock_move.py#L2125 [6]:
https://github.com/odoo/odoo/blob/8f5d7b5cd0c3e1808375baef8f0834d3f2e27a75/addons/stock/models/stock_move_line.py#L696-L700 [7]:
https://github.com/odoo/odoo/blob/8f5d7b5cd0c3e1808375baef8f0834d3f2e27a75/addons/stock/models/stock_move_line.py#L807-L817 [8]:
https://github.com/odoo/odoo/blob/8f5d7b5cd0c3e1808375baef8f0834d3f2e27a75/addons/stock/models/stock_move_line.py#L851
## Solution:
When a component move line is scrapped, it should be unpicked so that the system can reserve the next available lot/serial number automatically.

Once a component has been physically scrapped, it no longer makes sense to keep it marked as picked and reserved. Doing so leaves the MO in an inconsistent state, where the system still considers the scrapped component usable. By unpicking the move line after scrapping, both the system and the user clearly see that there is no longer any reserved quantity associated with that component.

This also allows system to automatically pick from next available lot or serial number, ensuring the manufacturing process can continue smoothly.

Such behavior is especially important in shop floor scenarios, where mistakes or damages may occur after components have already been registered, and the manufacturing process should continue without interruption.


opw-6157406

Forward-Port-Of: odoo/odoo#264589

Issue:
Swiss payslips count one extra absence day for employees without a working schedule. A one day accident leave can therefore be prorated as two days, reducing the regular wage and overstating the accident salary.

Steps to reproduce:
* Install Swiss Payroll.
* Configure a monthly employee without a working schedule.
* Assign one day of accident time off.
* Generate the payslip for that month.

Cause:
The Swiss wage computation derives absence boundaries from the date portion of the leave's UTC datetimes: https://github.com/odoo/enterprise/blob/16c29e1bab34b5bcb2b001477d928ec5eb294a97/l10n_ch_hr_payroll/models/hr_payslip.py#L313-L330

A fully flexible employee's full day leave starts at local midnight. In timezones ahead of UTC, that start is stored on the previous UTC date, so the inclusive calendar day computation adds an extra day.

Solution:
We need to use the requested time off dates for both payslip range filtering and absence proration. These fields preserve the calendar days selected by the user independently of timezone conversion, while leaving the UTC datetimes and half-day handling unchanged.

opw-6435086

Forward-Port-Of: odoo/enterprise#127513

1- The benefit fields related to the hr.version have a domain that limits them to the whitelisted fields used to copy values from a template, which does not always include benefit fields. The advantage of the whitelist is that it factored in for the allowed countries, so instead of duplicating this logic to benefit fields and implementing it in every l10n, we can check which module the field comes from.

example:
The field [`company_car_total_depreciated_cost`](https://github.com/odoo/enterprise/blob/ce691cd6aaacfb86cd866698d2fcc3fe930912cb/l10n_be_hr_payroll_fleet/models/hr_version.py#L62) cannot be selected as `res_field_id` when it should be possible as we see in the [data](https://github.com/odoo/enterprise/blob/ce691cd6aaacfb86cd866698d2fcc3fe930912cb/l10n_be_hr_contract_salary/data/hr_contract_salary_benefit_data.xml#L6), it is not whitelisted because we dont want to copy its value from a template.

2- Another fix is the inverse of the public field, there's a traceback because the selection field is always converted to a string and cannot be used to browse as is.
```py
  File "/data/build/enterprise/hr_contract_salary/models/hr_contract_salary_benefit.py", line 238, in _inverse_res_field_public
    record.res_field_id = self.sudo().env['ir.model.fields'].browse(record.res_field_public)
    ^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/orm/fields.py", line 1890, in __set__
    write_value = self.convert_to_write(value, records)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/orm/fields_relational.py", line 387, in convert_to_write
    return value.id
           ^^^^^^^^
  File "/data/build/odoo/odoo/orm/fields_misc.py", line 115, in __get__
    raise ValueError("Expected singleton: %s" % record) from None
ValueError: Expected singleton: ir.model.fields('1', '7', '3', '8', '4')
```

#### Description of the issue/feature this PR addresses:
The "Request Appraisals" server action on hr.employee calls model._create_multi_appraisals(), a method that no longer exists. Running it raises AttributeError: 'hr.employee' object has no attribute '_create_multi_appraisals'.

#### Current behavior before PR:
Commit 8845eb2ac29 replaced the multi-appraisal flow with hr.appraisal.campaign.wizard: it deleted _create_multi_appraisals and repointed the employee list header button to action_open_appraisal_campaign_wizard, but left the action_create_multi_appraisals record in hr_appraisal/views/hr_employee_views.xml. Its code is now the only reference to the deleted method, so the action crashes whenever it is run.

#### Desired behavior after PR is merged:
The dangling action is gone. Requesting appraisals for several employees at once is done with the "Launch Campaign" button already present in the Employees list view; action_open_appraisal_campaign_wizard reads active_ids when active_model is hr.employee and pre-fills the selected employees.

Nothing references the removed xml id, and the record is not noupdate, so _process_end removes it from existing databases on update; no migration script is required. Verified on a 19.0 database: with the orphan record loaded, updating hr_appraisal with this change deletes it.

opw-6408609

Forward-Port-Of: odoo/enterprise#125630

* = din5008_account_followup, din5008_industry_fsm

**Steps to reproduce:**

* Install the **Germany - Accounting** (`l10n_de`) module (which pulls in `l10n_din5008`)
* Set the document layout to **DIN 5008** and generate any PDF report (invoice, quotation, purchase order, etc.).

**Observed behavior (date format):**

* All dates in the information block (Invoice Date, Due Date, Delivery Date, Order Date, etc.) are rendered in `yyyy-mm-dd` format instead of the expected `dd.MM.yyyy` format used in DE, AT, and CH.

**Cause (date format):**

* All `t-options="{'widget': 'date'}"` directives across the DIN 5008 template family rely on the active user's language locale for date formatting. If the user language is not `de_DE`, dates render in the locale's default format (e.g. `yyyy-mm-dd` for `en_US`).

**Fix (date format):**

* Add `'format': 'dd.MM.yyyy'` explicitly to all `t-options` date widgets across all DIN 5008 report templates (`l10n_din5008`, `l10n_din5008_sale`, `l10n_din5008_purchase`, `l10n_din5008_sale_subscription`, `l10n_din5008_repair`, `l10n_din5008_account_followup`, `l10n_din5008_industry_fsm`).
* This is correct for all three countries using DIN 5008 (DE, AT, CH), which all follow the `dd.MM.yyyy` convention.

opw-6392649

Forward-Port-Of: odoo/enterprise#126006

Peppol documents can be received in a journal or in the Documents app (peppol_reception_mode). Some companies cannot use Documents: _peppol_allows_document_reception() returns False and the journal stays required. This is the case of French companies (via l10n_fr_pdp).

The onchange of the settings and the import did not check this method. So on a French company with the mode set to 'documents':
  - the Settings cleared the journal on each opening, while it was still required
  - the incoming documents were saved in Documents instead of vendor bills

Steps to reproduce:
- Create a Belgian company, with a purchase journal, and register it on Peppol as receiver
- Set the reception mode to "Receive in Documents"
- Change the fiscal position to France, and install l10n_fr_pdp, the Peppol part is replaced by "French Electronic Invoicing", so the radio button is not visible anymore, but the company still has peppol_reception_mode == 'documents'.
- Open the Settings again: the field "Incoming Invoices Journal" is empty.

opw-6429691

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes and rental transfers
- Unarchive the MTO route
- Create a rental product P with a buy route and a set vendor
- Create a rental order for 1 x P and set the the MTO route on the sol
- Confirm the order
#### > The delivery as well as the purchase for 1 unit of P was generated but the return was not.

### Cause of the issue:

The procurement generated to handle both the delivery and the return rental picking are handled by the `_create_procurements`: https://github.com/odoo/enterprise/blob/b0e48baaf99bdc4faefd2ffdd3bd5637fb548593/sale_stock_renting/models/sale_order_line.py#L353-L374 The `route_ids` set and used is the `mto_route` set on the sol: https://github.com/odoo/odoo/blob/0f061503e26ac8c441d62d91947419119e48c47a/addons/sale_stock/models/sale_order_line.py#L415-L422 https://github.com/odoo/odoo/blob/0f061503e26ac8c441d62d91947419119e48c47a/addons/sale_stock/models/sale_order_line.py#L282-L297
However, in the present case, the mto  route does not contain any rule with a relevant `location_src_id` in the rental location so that the return will not be generated.

opw-6361322

Forward-Port-Of: odoo/enterprise#126410
Forward-Port-Of: odoo/enterprise#124097

Steps to reproduce
---
1. Enable Storage Locations and Lots & Serial Numbers.
2. Add a putaway rule sending a lot-tracked product from WH/Stock to WH/Stock/Shelf 1.
3. Confirm a receipt reserving 2 units of that product; putaway sets the reserved move line destination to WH/Stock/Shelf 1.
4. In the Barcode app, scan a first lot, then a second lot.

The second lot lands on a separate line at WH/Stock instead of WH/Stock/Shelf 1.

Issue
---
The first lot reuses the reserved line and keeps its Shelf 1 destination. The second lot cannot reuse it because its tracking number differs, so `_findLine` returns nothing and `_getNewLineDefaultValues` builds a new line with `location_dest_id` set to `_defaultDestLocation()`, the picking's default destination (WH/Stock).

https://github.com/odoo/enterprise/blob/314a79b774f30dc9377b2971492576c4b84483e1/stock_barcode/static/src/models/barcode_picking_model.js#L1591-L1601

Putaway relocates the destination on the move line at reservation, never on the picking, so only the reserved line carries Shelf 1. Since `groupKey` includes `location_dest_id`, the new line does not group with the first lot and shows separately at WH/Stock. This is not a regression: new lines have always defaulted to the operation destination.

https://github.com/odoo/enterprise/blob/314a79b774f30dc9377b2971492576c4b84483e1/stock_barcode/static/src/models/barcode_picking_model.js#L239-L241

The new line now inherits the selected line's `location_dest_id`, already relocated by putaway, instead of the default.

opw-6317077

Forward-Port-Of: odoo/enterprise#127906
Forward-Port-Of: odoo/enterprise#125309

## [FIX] timesheet_grid: remove duplicate rpc call

Before this commit, the `loadTimesheets` method is called 2 times in a
row, that method does a rpc call to load the existing timesheets and so,
it is not needed to call it 2 times since the rpc will return the exact
same result.

This commit removes the rpc call when we compute the suggestions to only
load the timesheets when we load all the data.

## [FIX] timesheet_grid: show chronological view instead of project view

Before this commit, the `by project` view were loaded first in the
timesheet assistant action, to group the suggestion by project, the
problem is at the beginning the view will not really show a perfect
matching and so the user could think the feature does not work and he
will not understand how to correctly match the suggestions shown in the
view.

This commit changes the view loaded by default in Timesheets Assistant
to first show the chronological view, that view is more logical for the
current user to rethink what he did in the past to correctly map the
events to a project and a task when he generates his timesheets thanks
to those events. The by project view is still useful afterwards when the
system has learned the choices made by the current user.

## [FIX] timesheet_grid: ensure events are consumed forever

Before this commit, the suggestions removed by the current user comes
back when he changes the date and come back to the day he removes the
suggestions. The reason is because a shallow copy of events consumed is
made and that copy alters the duration of the initial object.

This commit avoids copying the consumed events object to make sure the
initial object is not altered when processing the events to remove them
if they are removed before by the user.

### Steps to reproduce the issue:

1. install timesheet_grid and Activity watch, makes sure Activity watch
collects some activities on your computer.
2. Go to Assistant menu in timesheets app.
3. Remove some suggestions displayed in the right panel.
4. Go to next date.
5. Come back to previous date.

### Expected Behavior:


The suggestions removed should not appear again.

### Actual Behavior:

The suggestions removed come back in the view.

## [FIX] timesheet_grid: fix flicker when suggestion selected

Before this commit, when the user selects a suggestion in timesheet
assistant, there is a small flicker appears because the height of the
row grows because of the border added to highlight the suggestion
selected.

This commit reviews a bit the style to make sure the border bottom in
the previous element is removed if the element is not selected or if the
2 consecutives suggestions are selected.

## [FIX] timesheet_grid: fix discord rules to handle discord in web

Before this commit, when the user uses discord in its browser instead of
the app on his computer, the discord rules don't catch the activity
watch events because the tab title is different than the windows name in
the app.

This commit adapts the regex of Discord rules to handle the both use
cases.

task-[6385639](https://www.odoo.com/odoo/project.task/6385639)

Forward-Port-Of: odoo/enterprise#126435
Forward-Port-Of: odoo/enterprise#124855

When the AI agent switched from another view to a pivot view, the pivot view
could crash or open without any active measures.

The AI controller patch applies the agent's adjustments upon receiving the
`APPLY_AI_ADJUST_MODEL` bus event. However, the event could be processed while
the pivot model was still executing `_loadData()`.

In that case, the following sequence occurred:

* `_loadData()` started and awaited.
* The controller patch was executed.
* The patch called `toggleMeasures()`.
* `toggleMeasures()` waited for `_loadData()` to complete.
* `_loadData()` finished and updated the metadata with the available measures.
* `toggleMeasures()` resumed and wrote back the metadata snapshot it had taken
before waiting.

Since `toggleMeasures()` operates on a snapshot of the metadata, the measures
populated by `_loadData()` were lost when the snapshot replaced the current
metadata, leaving the pivot model without its `measures` metadata and causing
the view to crash.

Prevent this race condition by waiting for the pivot model initialization to
complete before applying the AI adjustments.

Also preserve the default active measures when the AI agent does not explicitly
request any measures instead of clearing them and opening an empty pivot view.

task-6384368

Steps to produce:
---
- Install sale_tiktok module.
- Create two active tiktok.shop records.
- Run the database neutralization command.

Issue:
---
- Neutralization fails with a PostgreSQL error:
 ```py
 duplicate key value violates unique constraint tiktok_shop_unique_active_shop`
 DETAIL: Key (tiktok_shop_ref)=(1) already exists.
```

Root cause:
---
- At [1], we are setting `tiktok_shop_ref = 1` for all `tiktok_shop` records. Because `tiktok_shop` enforces a partial unique constraint on `tiktok_shop_ref` for active shops [2], setting the same reference value `1` on multiple active shops violates this constraint.

Solution:
---
- Update sql to assign a row-unique string to each shop. This strips the real shop reference while maintaining uniqueness across active shop records so neutralization completes cleanly.

[1]https://github.com/odoo/enterprise/blob/85754b0354b76da8b4d87a3a81dd19679ed35d15/sale_tiktok/data/neutralize.sql#L1-L8

[2]https://github.com/odoo/enterprise/blob/85754b0354b76da8b4d87a3a81dd19679ed35d15/sale_tiktok/models/tiktok_shop.py#L136-L139

opw-6451715
---

* = din5008_account_followup, din5008_industry_fsm

**Steps to reproduce:**

* Install the **Germany - Accounting** (`l10n_de`) module (which pulls in `l10n_din5008`)
* Set the document layout to **DIN 5008** and generate any PDF report (invoice, quotation, purchase order, etc.).

**Observed behavior (date format):**

* All dates in the information block (Invoice Date, Due Date, Delivery Date, Order Date, etc.) are rendered in `yyyy-mm-dd` format instead of the expected `dd.MM.yyyy` format used in DE, AT, and CH.

**Cause (date format):**

* All `t-options="{'widget': 'date'}"` directives across the DIN 5008 template family rely on the active user's language locale for date formatting. If the user language is not `de_DE`, dates render in the locale's default format (e.g. `yyyy-mm-dd` for `en_US`).

**Fix (date format):**

* Add `'format': 'dd.MM.yyyy'` explicitly to all `t-options` date widgets across all DIN 5008 report templates (`l10n_din5008`, `l10n_din5008_sale`, `l10n_din5008_purchase`, `l10n_din5008_sale_subscription`, `l10n_din5008_repair`, `l10n_din5008_account_followup`, `l10n_din5008_industry_fsm`).
* This is correct for all three countries using DIN 5008 (DE, AT, CH), which all follow the `dd.MM.yyyy` convention.

opw-6392649

### Issue before this commit:
When generating a SEPA Credit Transfer batch using the German XML format (pain.001.001.03), the <LEI> tag is erroneously included in the exported file if an LEI is configured on the company. This invalidates the XML, causing banks to reject the file.

### Steps to reproduce the issue:
1. Download Accounting and l10n_de
2. Go to Settins > Vendor Payments > SEPA Credit Transfer / ISO20022 and set Name Identification as 529900T8BM49AURSDO55 and Issuer as LEIMAN
3. Go to companies and set 529900T8BM49AURSDO55 as LEI in the DE company
4. Go to Accounting dashboard and click the 3 dots of the bank group, go to Configuration and set the Account Number and be sure in the Outgoing Payments tab XML Format is German
5. Create a new German company from Contacts with:
	1. Country as Germany
	2. VAT
	3. Account Number in the Bank Accounts by adding one line:
		1. example Account Number: DE65100500007201811026
		2. example Bank: BNP Paribas
		3. activate the Send Money button
7. Then go to Vendor > Payments and create a new one with Payment Method as SEPA Credit Transfer for the German company created
8. Go back and select the new payment from the list and click create batch and print it
9. In the XML of pain.001.001.03.(DE) file, the LEI tag should not be included.

### Cause of the issue:
The XML generation logic does not filter out the <LEI> element for older schema versions like pain.001.001.03, which do not support this tag.

### Reason to introduce the fix:
To ensure strict schema compliance and prevent bank rejections. The <LEI> element is now properly omitted from pain.001.001.03 files and restricted only to newer formats (e.g., pain.001.001.09) where it is valid.

opw-6428150

Issue:

- DATEV does not support multiple foreign currencies on a single journal line.
- This can occur when reconciling a bank transaction where:
  - the payer uses one currency (C1),
  - the bank journal is held in another currency (C2),
  - the company uses a third currency (C3).
- The existing export logic could not represent the bank liquidity and
  foreign AR/AP currencies separately in such cases.

Fix:

- Detect 3-currency cases from bank statement transactions and their
  liquidity line.
- Use the DATEV clearing account (1360 SKR03 / 1460 SKR04) to split the
  transaction into two logical legs:
  - Bank → Clearing (bank journal currency)
  - AR/AP → Clearing (payer currency)
- Emit the liquidity leg only once when multiple foreign AR/AP lines are
  reconciled against the same bank transaction.
- Keep regular 1- and 2-currency transactions on the existing export path.

Impact:

- Correctly represents 3-currency bank settlements in DATEV.
- Keeps each exported line in a single foreign currency.
- Leaves manual entries and payment transactions outside this specific
  handling, as the scenario is specific to the bank liquidity line.

taskID-5457547

### Steps to reproduce issue:

1. Activate the Mexican localization and configure a company able to sign
2. Create an invoice with one line: a product with a valid UNSPSC code,
   Price 250.00, VAT 16%, Discount 99.99%
3. Confirm, then Send & Print with the CFDI checked
4. In the generated XML, the following values are off:
    - In node "Comprobante": SubTotal="200.00" Descuento="199.98"
    - In node "Concepto": ValorUnitario="200.00" Importe="200.00"
      Descuento="199.98"
    - Expected are 250.00 and 249.98

### Explanation:

`discount` is a Float(digits=(16, 2)) and both conversions of the field don't give the same float: `convert_to_column` writes it as '99.99' while `convert_to_cache` rounds it to 99.99000000000001. Hence, 250 * (1 - 99.99000000000001 / 100) = 0.0249999999999695, rounded to 0.02, but 250 * (1 - 99.99 / 100) = 0.0250000000000250, rounded to 0.03. `price_subtotal` is therefore stored as 0.02 when the invoice is posted, while any later request, such as the one generating the CFDI, recomputes 0.03.

`gross_price_subtotal` is computed by dividing the rounded `price_subtotal` by `discount_factor`, which amplifies the rounding error of `price_subtotal` by 1 / discount_factor, so 10 000 times with a 99.99% discount: 0.02 / 0.0001 = 200.00 instead of 250.00. That difference is exactly half a cent, which is also the tolerance of the condition added by 771d3e3cf, so the condition fails and the amount computed from `price_subtotal` wins over `price_unit`. Every price whose net lands on a half cent is affected, i.e. the odd multiples of 50 with a 99.99% discount.

### Fix reasoning:

`price_unit` is the source of truth for `ValorUnitario`. Tolerating one rounding unit instead of half of one is enough to cover the rounding of `price_subtotal`, so `price_unit` keeps the priority. The fallback still applies to the cases it was added for, where something other than the discount affects `price_subtotal` (e.g. price-included taxes), since those differ by much more than one rounding unit. The discount amount is derived from the gross, so it absorbs the difference: `Importe` - `Descuento` still gives `price_subtotal` and the total of the document is unchanged.

ticket-id: [6386895](https://www.odoo.com/odoo/project/49/tasks/6386895)