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#127849
Forward-Port-Of: odoo/enterprise#127513

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
---

Forward-Port-Of: odoo/enterprise#127532

**Steps to reproduce**
* Install the `pos_order_tracking_display` module with demo data.
* Open the restaurant POS, preparation display, and status screen in separate tabs.
* From the POS, send an order to the kitchen.
* In the preparation display, mark the order as **Ready**.
* Verify that the order moves to the **Ready** stage on the status screen.
* In the preparation display, mark the order as **Completed**.

**Observation**
* The completed order moves back to the **Almost There** stage on the status 
screen.
* Completed orders should no longer be displayed.

**Cause**
The order stage shown in the preparation display is determined by `_get_pos_orders`. Previously, order lines were retrieved through `_get_open_orderlines_in_display`, which excluded completed orders. 
After the refactor, order lines are fetched using  `get_preparation_display_orders_domain`, which returns completed order lines as well.

Orders are then split into two groups:

* Orders in the **Ready** stage are displayed as **Ready**.
* All other orders are displayed as **Almost There**.

As a result, completed orders incorrectly appear under **Almost There**.

Additionally, `get_preparation_display_orders_domain` contains an incorrect domain introduced by commit https://github.com/odoo/enterprise/commit/8491f7a74363f7de4fd542e0de0b2f06f00f01ae:

* `last_stage_id` is treated as a string literal:
  `('stage_id', '=', 'last_stage_id')`
  which always evaluates to `False`.
* The `todo` condition is also inverted.



**Fix**
This commit fixes two issues:
* Exclude completed order lines from the preparation display.
* Restore the correct domain logic by replacing the faulty condition with the 
simpler equivalent:
```
'|', ('todo', '=', True), ('stage_id', '!=', last_stage_id)
```

This restores the original behavior while keeping the domain easier.

opw-6423519

Currently, an error occurs when a user adds a rental product to the cart, opens the corresponding sales order, removes the rental period, and then opens the cart again.

Steps to replicate:
- Install `website_sale_renting` with demo.
- Open website > shop > add the product named `Projector`.
- Click Ecommerce in the menu bar > Orders .
- Remove the `Confirmed` filter > Click on the top order (should be containing the projector product.)
- Remove the `Rental Period` and go to the cart.

Error:
```
QWebError: Error while rendering the template:
AttributeError: 'bool' object has no attribute 'time'
Template: website_sale.shorter_cart_summary
```

Cause:
- When the user removes the rental period (`rental_start_date` and `rental_end_date`), both fields are set to `False`. When the cart is opened again, these values trigger the error in [line].

- Since the rental period has been removed from the order, the order is converted to a regular Sales Order (see [PR] and its [task]). Therefore, the Rental Period should no longer be displayed.

Solution:
- Use `is_rental_order` to determine whether to render the rental period instead of `has_rentable_lines`, since `has_rentable_lines `only checks whether the product is rentable [1], which is determined by the product's `rental_periodicity` [2].

- `is_rental_order` is a better check here because it indicates whether the rental period is actually defined on the order [3].

[line]: https://github.com/odoo/enterprise/blob/7c80c9ffa9e7812267f2ac285e3a3fc5ca501814/website_sale_renting/views/templates.xml#L207

[task]: https://www.odoo.com/odoo/all-tasks/6003684

[PR]: https://github.com/odoo/enterprise/pull/106381/commits/56ec41d81f7536f047a1586a12ea6f6e8414b844

[1]: https://github.com/odoo/enterprise/blob/f23ef9c604d8ce6be152d5e5bf6f72bd68b31451/sale_renting/models/sale_order.py#L140-L143

[2]: https://github.com/odoo/enterprise/blob/f23ef9c604d8ce6be152d5e5bf6f72bd68b31451/sale_renting/models/sale_order_line.py#L61-L64

[3]: https://github.com/odoo/enterprise/blob/f23ef9c604d8ce6be152d5e5bf6f72bd68b31451/sale_renting/models/sale_order.py#L135-L138

sentry-7663524549

Forward-Port-Of: odoo/enterprise#128084

Some generic validation errors raised by core account models lack enough context to identify which record caused the issue, making FEC imports harder to troubleshoot.

This commit improves the two error cases identified for this use case:
- `account.account._check_account_code` now includes the invalid account code in the error message.
- `account.move.write` now includes the move name/reference and displays human-readable field labels instead of technical field names when attempting to modify read-only fields on posted entries.

Although motivated by FEC import, these are generic core validations, so the improvements are implemented at the source to benefit all callers rather than only the FEC import flow.

Enrichment is scoped to the two cases above, other constraints/errors across these models are intentionally left unchanged for now, since editing core error messages more broadly should be done deliberately and on a case-by-case basis, not as a blanket rewrite

task-5346068

Forward-Port-Of: odoo/odoo#282840
Forward-Port-Of: odoo/odoo#281746

> Replaces https://github.com/odoo/odoo/pull/282286, which GitHub closed automatically after a bad force-push on my side: the branch was pushed from a shallow clone and its head lost its parent commit, leaving no common ancestor with 18.0. A PR in that state cannot be reopened, so this one continues from a clean branch with the exact same change. The review discussion is in that PR, and the rename asked for there is included here.

### Steps to reproduce

1. Go to `Accounting > Customers > Invoices` and create an invoice on a given journal, leaving it in draft. For the clearest case, leave it with no invoice line.
2. Go to `Accounting > Configuration > Journals`, open that journal and archive it.
3. `_check_auto_post_draft_entries` raises: *"You can not archive a journal containing draft journal entries. To proceed: 1/ click on the top-right button 'Journal Entries' from this journal form 2/ then filter on 'Draft' entries 3/ select them all and post or delete them through the action menu"*.
4. Follow those steps: click the `Journal Entries` smart button on the journal form.

### Current behaviour

The list comes up empty, so the user concludes the error message is wrong, while the draft entries do exist.

The instructions cannot be followed:

- The smart button opens `action_account_moves_all_a`, which is named **"Journal Items"** and targets **`account.move.line`**, not `account.move`. The label of the button and the name of the action it opens do not match.
- That action defaults to `search_default_posted: 1`, so no draft record is listed.
- Draft entries with **no line at all** — commonly created through the incoming mail alias of a journal — have no `account.move.line`, so they stay invisible in that view even after switching the filter.
- The action menu of a move line list offers no way to post or delete the entries, and the action sets `create: 0`.
- The filter is labelled **"Unposted"**, not "Draft".

The offending entries are only reachable through `Accounting > Accounting > Journal Entries`, filtering by journal and by "Unposted".

### Expected behaviour

The error should point to a view where the records blocking the archiving are actually listed and actionable.

### This PR

Two changes, the validation itself is unchanged:

- The error message now points to `Accounting > Accounting > Journal Entries` and uses the real filter name, "Unposted".
- The smart button of the journal form is renamed to **"Journal Items"**, so its label matches the action it opens and no longer suggests it lists journal entries. This was asked for in the review of the previous PR.

Targeted at 18.0 because that is where the misleading message is being hit in practice; it is identical on 19.0 and master. If a translatable string change does not qualify for the stable series, tell me and I will retarget to master.

Forward-Port-Of: odoo/odoo#282956

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#127849
Forward-Port-Of: odoo/enterprise#127513

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
---

Forward-Port-Of: odoo/enterprise#127532

* = 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#128209
Forward-Port-Of: odoo/enterprise#126006

Steps to reproduce:
- Post a Peruvian invoice so it is sent to SUNAT (directly or through Estela/Digiflow).
- SUNAT's sendBill call hangs and Odoo's request times out (ReadTimeout / ConnectionError), even though SUNAT actually finishes registering the document on its side a moment later.
- Odoo retries sending the same invoice (either automatically through the EDI cron, or manually). SUNAT now replies with a "document already exists" SOAP fault (code 1033/4000), since it processed the previous attempt.
- Odoo tries to recover from this by fetching the CDR through getStatusCdr, but SUNAT has not finished generating it yet, so the lookup also fails.

Cause of the issue:
_l10n_pe_edi_post_invoice_web_service() already has recovery logic for error codes 1033/4000: it calls _l10n_pe_edi_retrieve_cdr() to fetch the CDR and treat the invoice as sent. But when that lookup itself fails (CDR not generated yet), the resulting error keeps the 'blocking_level' set to 'error' from the original SOAP fault. Documents with blocking_level 'error' are excluded from the automatic EDI cron retries (see account.edi.document._cron_process_documents_web_services), so the invoice gets stuck needing a manual retry, which can lose the same race against SUNAT again and again.

Solution:
When the CDR can't be retrieved yet after a 1033/4000 duplicate error, mark the result as 'blocking_level': 'warning' instead of leaving it at 'error'. This keeps the invoice eligible for the automatic EDI cron retries, so Odoo keeps polling SUNAT until the CDR becomes available, instead of requiring manual intervention every time this race is lost.

opw-6393231

Forward-Port-Of: odoo/enterprise#125053

The PstlAdr block written into pain.001 files never contains the
partner's state/province nor the second street line, even when they
are set on the record: _get_all_addr() now returns them, but
_get_PstlAdr() also needs to write them out. Some North American banks
reject wire transfers whose beneficiary address lacks the
state/province, so those payments fail regardless of how complete the
vendor record is.

Emit CtrySubDvsn when the address has a state, before Ctry as required
by the element order of the PostalAddress schema, and append street2
to the street address line.

Steps to reproduce:
- Install Accounting and enable a generic ISO 20022 payment method on
  a bank journal
- Create a vendor located in the US or Canada with a complete address,
  including the state and a second street line
- Register a vendor payment, add it to a batch and generate the
  pain.001 file
- The creditor PstlAdr has no state/province, and its street line only
  carries the first street field: the street2 part is dropped


Requires odoo/odoo#282518, which makes _get_all_addr() return the state and street2.

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

Forward-Port-Of: odoo/enterprise#128021
Forward-Port-Of: odoo/enterprise#127958

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
---

Forward-Port-Of: odoo/enterprise#127532

> Replaces https://github.com/odoo/odoo/pull/282286, which GitHub closed automatically after a bad force-push on my side: the branch was pushed from a shallow clone and its head lost its parent commit, leaving no common ancestor with 18.0. A PR in that state cannot be reopened, so this one continues from a clean branch with the exact same change. The review discussion is in that PR, and the rename asked for there is included here.

### Steps to reproduce

1. Go to `Accounting > Customers > Invoices` and create an invoice on a given journal, leaving it in draft. For the clearest case, leave it with no invoice line.
2. Go to `Accounting > Configuration > Journals`, open that journal and archive it.
3. `_check_auto_post_draft_entries` raises: *"You can not archive a journal containing draft journal entries. To proceed: 1/ click on the top-right button 'Journal Entries' from this journal form 2/ then filter on 'Draft' entries 3/ select them all and post or delete them through the action menu"*.
4. Follow those steps: click the `Journal Entries` smart button on the journal form.

### Current behaviour

The list comes up empty, so the user concludes the error message is wrong, while the draft entries do exist.

The instructions cannot be followed:

- The smart button opens `action_account_moves_all_a`, which is named **"Journal Items"** and targets **`account.move.line`**, not `account.move`. The label of the button and the name of the action it opens do not match.
- That action defaults to `search_default_posted: 1`, so no draft record is listed.
- Draft entries with **no line at all** — commonly created through the incoming mail alias of a journal — have no `account.move.line`, so they stay invisible in that view even after switching the filter.
- The action menu of a move line list offers no way to post or delete the entries, and the action sets `create: 0`.
- The filter is labelled **"Unposted"**, not "Draft".

The offending entries are only reachable through `Accounting > Accounting > Journal Entries`, filtering by journal and by "Unposted".

### Expected behaviour

The error should point to a view where the records blocking the archiving are actually listed and actionable.

### This PR

Two changes, the validation itself is unchanged:

- The error message now points to `Accounting > Accounting > Journal Entries` and uses the real filter name, "Unposted".
- The smart button of the journal form is renamed to **"Journal Items"**, so its label matches the action it opens and no longer suggests it lists journal entries. This was asked for in the review of the previous PR.

Targeted at 18.0 because that is where the misleading message is being hit in practice; it is identical on 19.0 and master. If a translatable string change does not qualify for the stable series, tell me and I will retarget to master.

Forward-Port-Of: odoo/odoo#282956

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
---

Forward-Port-Of: odoo/enterprise#127532

> Replaces https://github.com/odoo/odoo/pull/282286, which GitHub closed automatically after a bad force-push on my side: the branch was pushed from a shallow clone and its head lost its parent commit, leaving no common ancestor with 18.0. A PR in that state cannot be reopened, so this one continues from a clean branch with the exact same change. The review discussion is in that PR, and the rename asked for there is included here.

### Steps to reproduce

1. Go to `Accounting > Customers > Invoices` and create an invoice on a given journal, leaving it in draft. For the clearest case, leave it with no invoice line.
2. Go to `Accounting > Configuration > Journals`, open that journal and archive it.
3. `_check_auto_post_draft_entries` raises: *"You can not archive a journal containing draft journal entries. To proceed: 1/ click on the top-right button 'Journal Entries' from this journal form 2/ then filter on 'Draft' entries 3/ select them all and post or delete them through the action menu"*.
4. Follow those steps: click the `Journal Entries` smart button on the journal form.

### Current behaviour

The list comes up empty, so the user concludes the error message is wrong, while the draft entries do exist.

The instructions cannot be followed:

- The smart button opens `action_account_moves_all_a`, which is named **"Journal Items"** and targets **`account.move.line`**, not `account.move`. The label of the button and the name of the action it opens do not match.
- That action defaults to `search_default_posted: 1`, so no draft record is listed.
- Draft entries with **no line at all** — commonly created through the incoming mail alias of a journal — have no `account.move.line`, so they stay invisible in that view even after switching the filter.
- The action menu of a move line list offers no way to post or delete the entries, and the action sets `create: 0`.
- The filter is labelled **"Unposted"**, not "Draft".

The offending entries are only reachable through `Accounting > Accounting > Journal Entries`, filtering by journal and by "Unposted".

### Expected behaviour

The error should point to a view where the records blocking the archiving are actually listed and actionable.

### This PR

Two changes, the validation itself is unchanged:

- The error message now points to `Accounting > Accounting > Journal Entries` and uses the real filter name, "Unposted".
- The smart button of the journal form is renamed to **"Journal Items"**, so its label matches the action it opens and no longer suggests it lists journal entries. This was asked for in the review of the previous PR.

Targeted at 18.0 because that is where the misleading message is being hit in practice; it is identical on 19.0 and master. If a translatable string change does not qualify for the stable series, tell me and I will retarget to master.

Forward-Port-Of: odoo/odoo#282956

**Description:**
While loading the budget report, the bad queries are created by 
```def _get_aal_query()``` and ```def _get_pol_query()``` function, makes 
the budget report unusable.

**Root cause:**
Instead of doing a hash join while searching the record,
 the OR statement in the Left Join in the condition 
```(%(bl)s IS NULL OR %(a)s = %(bl)s)``` 
creates a nested for loop that compares everything single aal to bl, 
this causes a significant performance issue as the number of the 
number of check will be the the number aal * bl,
if a database has a 70k aal and 20k bl, both numbers are not large
but it will cause a 70k * 20k search which is more than a billion.

**Fix**:
There are some refactors made in this PR.

_First_, separate out the Q1.
In order to find the aal that has no bl connects to it. 
Doing a search to find the aals that have bl and then subtract them from all aals.

_Second_, Instead of doing a nested loop for by using
 ```(%(bl)s IS NULL OR %(a)s = %(bl)s)```, 
originally we will have do something like
```
JOIN budget_line bl
  ON (bl.x_plan2_id IS NULL OR aal.x_plan2_id = bl.x_plan2_id)
 AND (bl.x_plan3_id IS NULL OR aal.x_plan3_id = bl.x_plan3_id)
 AND (bl.x_plan4_id IS NULL OR aal.x_plan4_id = bl.x_plan4_id)
```
Assuming each bl has three plans ```x_plan2_id```, ```x_plan3_id```, ```x_plan4_id```

Grouping the bl base on whether a specific plan is set, (i.e. shapes)
we can skip the ```IS NULL OR``` because we already know which plan
 is null and do the hash join directly.

For example, the shapes will be a dictionary with a key of a tuple of booleans
based on whether a plan is set or not and the value is a list of bl_id.

```
{
    (True, False, False): [1, 2],
    (False, True, True):  [3, 4],
    (False, False, False): [5],
}
```

we can end up doing something like

```
JOIN budget_line bl
 ON bl.id = ANY(ARRAY[3,4])
 AND aal.x_plan3_id = bl.x_plan3_id AND aal.x_plan4_id = bl.x_plan4_id
```
which is way more faster.

---
The benchmark is made locally from this client's database which contains
 69k aal, 23k bl, 6829 pol and 3 plans for aal and bl.

|Record count                                      |Time before|Time after|
|--------------------------------------------------|-----------------|---------------|
|69k aal, 23k bl, 6829 pol, 3 plans    |70.04s         |4.6s            |

Dalibo:

Before: 
Month-over-month grand total by company:
https://explain.dalibo.com/plan/8h3d4e89aaf9f3d4
Overall grand total by company:
https://explain.dalibo.com/plan/445g1f9caf4923e2
Month-over-month grand total by plan: 
https://explain.dalibo.com/plan/53a138ca50b2a7c4
Overall grand total by plan: 
https://explain.dalibo.com/plan/hdbe169ddc7g5785

After: 
Month-over-month grand total by company:
https://explain.dalibo.com/plan/hcc86c801e6872bf
Overall grand total by company:
https://explain.dalibo.com/plan/69b2421a3581f98h
Month-over-month grand total by plan:
https://explain.dalibo.com/plan/a88f398bbbch3148
Overall grand total by plan: 
https://explain.dalibo.com/plan/1gg749ae7ab1553c

opw-6345552

Forward-Port-Of: odoo/enterprise#127732
Forward-Port-Of: odoo/enterprise#124161

### 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

## [FIX] planning_field_service: display complete button in popover footer

Before this commit, the complete button is displayed in the card even in
the gantt popover instead of displaying it in the footer of the gantt
popover.

This commit makes sure the complete button in the card is only displayed
in the kanban view and that button is displayed in the footer of the
gantt view.

## [FIX] planning_field_service: adapt onboarding tour based on recent changes

Before this commit, the quick create on resource_ids field in
planning.slot has been replaced by a form view inside a modal.
The Sign in button in gantt/calendar popover no longer automatically
redirects the user to the form view of the intervention and so the user
cannot directly complete the shift.

This commit adapts the onboarding tour based on the recent changes. It
also forces a reload in the gantt view when the user signs in a
intervention via the Sign in button in the gantt popover.

runbot-error-941063
task-[6353582](https://www.odoo.com/odoo/project/4105/tasks/6353582)

Forward-Port-Of: odoo/enterprise#122495

**Steps to reproduce:**
- Go to Documents app in mobile
- Go to the kanban view
- Add some files and select one
- Click on `Info & Tags` button in the control panel
- Reload the page
- Chatter is not displayed but the button is still enabled
- Switching to the list view properly shows it

**Issue:**
Original fix (see [1]) was not enough for every case. Additional issues:
- Chatter hidden on init even when its panel has `visible = true`
- State desynchronized with the view when switching menu type (kanban/list) or by previewing a document and coming back
- When using the button with an open preview, chatter shows up in the background but is not accessible (and going back discards it)
- Removing selection with an open chatter disable the related action

**Fix:**
- Disable the chatter on mobile init by default to avoid having to manually move it back
- Reset chatter on selection removal to avoid getting stuck in the menu
- Reset chatter on view switch to avoid being in the wrong state afterwards
(and revert the previous css changes)

Not a great fix (quite mobile-specific) and there might still be some edge cases.

[1] original fix: https://github.com/odoo/enterprise/commit/cf3c2fce8a6b7b2d7547d44a0e4423f887986d52

opw-6061993

Forward-Port-Of: odoo/enterprise#127874
Forward-Port-Of: odoo/enterprise#121521

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#128151
Forward-Port-Of: odoo/enterprise#126242

Creating a batch of payslips mixing employees with and without leave allocations raises a KeyError:
```
  File "l10n_au_hr_payroll/models/hr_payslip.py", line 869, in _add_unused_leaves_to_payslip
    annual_gross = leaves_totals[payslip.id]['annual'] * daily_wage
                   ~~~~~~~~~~~~~^^^^^^^^^^^^
  KeyError: 22
```

Current Issue:
`_l10n_au_get_unused_leave_by_type` only materialises leaves_by_date[payslip.id] inside the allocation loop, so a payslip whose employee has no matching allocation never gets a key. `_l10n_au_get_unused_leave_totals` then rebuilt a plain dict out of those entries and only fell back to a defaultdict when leaves_by_date was completely empty. A mixed batch is not empty, so the plain dict was returned and `_add_unused_leaves_to_payslip` raised on the payslips that were missing from it.

This never showed up in the UI, **where payslips are created one at a time**: a single slip either has an allocation, or produces an empty mapping that hits the fallback.

Approach:
Build the totals on a defaultdict and update it instead of returning a plain dict, so any payslip without allocation resolves to 0 rather than being absent. This also drops the need for the empty special case, and keeps the mapping consistent with the defaultdict returned by `_l10n_au_get_unused_leave_by_type`, which `_l10n_au_get_leaves_for_withhold` indexes the same way.

task-6465229

Steps to reproduce:
- Have an external VoIP software configured (e.g. Linphone)
- Have your Odoo configured and opened too
- Call your VoIP number, using your smartphone => Both the softphone and Linphone ring
- Answer or reject using Linphone => The VoIP call record in Odoo immediately switches from "Trying to call" to "Missed".

While there was no guarantee for our VoIP integration to work alongside Linphone in 19.0, we decided this should be an easy safe enough fix. Starting 19.2 (with [1]), the fix will be simplified and hopefully prettier thanks to the ameliorations that were made.

After this fix, provided Odoo is open while Linphone is used, the call records will now switch to the right terminated / rejected status, still immediately once Linphone answers / rejects.

In future versions and especially 20.0+, the system will be different and will allow way more features like this one to work better (e.g. here the call record only even exists if Odoo is opened while using Linphone and we won't have any information about the call duration).

[1]: https://github.com/odoo/enterprise/commit/942f32316ab02d8c739fe7fdd5ec2bdde472a68e

task-6449259

Steps to reproduce:
---------------------------
1. Install `sale_planning` with demo data.
2. Create a SO with a planning product, set the quantity to 100 hours, and confirm the SO.
3. Click the "To Plan" button, then click "Auto Plan".
4. Make sure the "Month" filter is selected in the scale options and observe the planned slots.

Issue:
--------
When auto planning slots for a month, the last day of the month is excluded. For example, slots are scheduled only until July 30th, even though July 31st is a working day.

Cause:
--------
While preparing the context, `stopDate` is set to July 31st at 00:00. It is then passed to [serializeDateTime()](https://github.com/odoo/odoo/blob/dacaad91bba8f959daf5d89a046c5a1c11e48eec/addons/web/static/src/core/l10n/dates.js#L553-L560), which converts the datetime to UTC. Depending on the user's timezone, this can shift the date to the previous day, causing the last day of the month to be excluded.

Solution:
------------
Use `localEndOf()` to set `stopDate` to the local end of the selected range before passing it to `serializeDateTime()`. This ensures the last day of the month is preserved during UTC conversion.

**NOTE:**
Forward-port the solution from the 18.0 version, which was adapted to the publish shift use case in 18.3 and introduced this issue. Add a HOOT test case to prevent this regression in future versions.

References: [18](https://github.com/odoo/enterprise/commit/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e) and [saas-18.3](https://github.com/odoo/enterprise/commit/c81fba31780869940f726b695ad46a87f69798fb)

opw-6391495

When reconciling an internal transfer between a branch and its parent
company, an User Error is raised if the branch transaction has been
processed via reconciliation model.

Steps to reproduce:
- Have a company with branch both selected
- On the branch, create a reconciliation model "Internal transfer" that
  assigns the whole balance to the liquidity transfer account
- Have a Bank journal on the company and a Bank journal on the branch
- On the branch bank journal, create a -100 transaction 'testb' and
  reconcile it using the branch internal transfer model
- On the company bank journal, creata a 100 transaction, open the
  reconciliation widget and select the branch transaction to match it

Issue:
The reconciliation is refused with a company inconsistency error
``` Uh-oh! You’ve got some company inconsistencies here:
- “BNK1/2026/00011 test” belongs to company “YourCompany” while
  “Reconciliation Model” (reconcile_model_id: 'Internal Transfer
  branch') belongs to another company.  To avoid a mess, no company
  crossover is allowed!
```
However, if user manually assign the transfer account to the branch transaction,
the reconciliation proceed as expected

Analysis:

When reconciling, we build the counterpart journal item by cloning the
values of the matched move line, copying also the reconcile model.
That field is company dependent and flagged copy=False, so it should not
be propagated.

opw-6365856

Currently, an error occurs when resetting a **bank** statement line to draft.

**Steps to Reproduce:**
 - Install the `Accounting` module.
 - Go to `Accounting Dashboard` and click the `three-dot` on bank journal.
 - Open `Transactions`.
 - Create a new `statement line`.
 - Select the `statement line`, click the `gear action`, and click `Reset to Draft`.

`AttributeError: 'bool' object has no attribute 'setdefault'`

After the [recent commit], when resetting the statement line to draft, the server action run [1] and 
the linked move is going reset to draft, and the method returns the result [2]. After the mentioned 
commit, the method returns True [3]. When the result from [4] is passed to clean_action, it raises an error [5].

This commit ensures that it returns None after resetting the statement line linked to the 
invoice to draft, as it previously returned None and same as like [6].

[recent commit]: https://github.com/odoo/odoo/commit/712718d9df0fd5044ac57fdd9ec58e64bece36c0

[1]- https://github.com/odoo/enterprise/blob/7ca28a1c079d22b60e3756ca9b4f404771f214e8/account_accountant/views/bank_rec_widget_views.xml#L541-L551

[2]- https://github.com/odoo/enterprise/blob/eae51e3ca155ca29e1de54f4bd223e7540b2aa7f/account_accountant/models/account_bank_statement.py#L112-L114

[3]: https://github.com/odoo/odoo/blob/b3444e4bd421a30229b0dc7c8d5eb6c78b8b51ed/addons/account/models/account_move.py#L6236-L6251

[4]: https://github.com/odoo/odoo/blob/a6f99706c6a62fc65666a0ff5e58fa465b41a6fb/addons/web/controllers/action.py#L53-L59

[5]: https://github.com/odoo/odoo/blob/b3444e4bd421a30229b0dc7c8d5eb6c78b8b51ed/addons/web/controllers/utils.py#L24

[6]: https://github.com/odoo/odoo/blob/d7df2e8acff9eb7066993fa6a0b0c6d7c85baabc/addons/account/models/account_payment.py#L1206-L1208

sentry-7354160052

Currently, an error occurs when orders are being fetched from shops with pending authorization.

Steps to replicate:
- Install `sale_tiktok`.
- Open Sales > Configuration > Shops (Under the title tiktok shops).
- Click `Connect New Shop` > Give values for `App key, App secret, Service ID`.
- Click `Connect Shop & Authorize` and then Return back to Odoo.
- Run the Scheduled Action `TikTok Shop: sync orders`.

Error:
```
File '/home/odoo/src/enterprise/saas-19.4/sale_tiktok/utils.py', line 171, in make_tiktok_api_request
    if now > shop.access_token_expire_datetime - timedelta(minutes=5):
TypeError: unsupported operand type(s) for -: 'bool' and 'datetime.timedelta'

ValueError: TypeError('unsupported operand type(s) for -: 'bool' and 'datetime.timedelta'') while evaluating
'model._sync_orders()'
```

Cause:
- Since the shop has not yet been authorized with TikTok, the `access_token_expire_datetime` field is not set. This field is only populated after the shop is successfully authorized (see [this]).

- Later, when the `TikTok Shop: sync orders` cron runs, the flow reaches [here], where we checks whether the access token is expired and needs to be refreshed. At this point, `access_token_expire_datetime` is still False because the shop has not been authorized yet.

Solution:
- The orders should only be fetched from those shops that are authorized with TikTok.
- Used the `access_token` field to determine whether a shop is authorized, as it is only populated after the authorization flow is successfully completed.

[this]: https://github.com/odoo/enterprise/blob/593409ca160863d3e985f3cf5e2aadda1d450b41/sale_tiktok/controllers/onboarding.py#L52-L54

[here]: https://github.com/odoo/enterprise/blob/593409ca160863d3e985f3cf5e2aadda1d450b41/sale_tiktok/utils.py#L171

sentry-7631179329

### Current behavior:
With first day of week set to Monday, a Monday attendance that starts and ends at local midnight does not appear in Attendances weekly Gantt. The same record is visible in List and Monthly Gantt. Switching the first day of week to Sunday also shows it in weekly Gantt view.

### Expected behavior:
Monday attendances should appear in weekly Gantt view when the week starts on Monday, including 0-duration records at Monday 00:00.

### Steps to reproduce:
1. Set first day of the week to Monday
2. Create an attendance on Monday with check-in and check-out at 00:00
3. Open Attendances > Gantt > Weekly
4. The Monday column is empty while List still shows the record

### Cause of the issue:
`AttendanceGanttModel._getDomain` filters with check_out > range start. When the week starts Monday, range start is Monday 00:00, so a record whose check_out equals that bound is excluded.

### Fix:
Fix the comparison to be `check_out >= range start` so records ending at week start are still fetched and rendered.

opw-6414884

Steps to reproduce
---
1. Enable Storage Locations and Lots/Serial Numbers.
2. Set the delivery operation type's "Source Location" to "Do not scan".
3. Create a serial-tracked product with a serial stored in a sublocation (e.g. WH/Stock/Section 2).
4. Confirm a sale order for it, open the delivery in Barcode, and scan an unreserved serial.

Issue
---
Scanning the unreserved serial creates a new move line that falls back to _defaultLocation() because the decoded scan carries no source location (the operation type does not require scanning one) and never carries the serial's quant location.

https://github.com/odoo/enterprise/blob/f42cfa7265ce32bd95f7f805cf4fb54d8b79cce1/stock_barcode/static/src/models/barcode_model.js#L937-L944

For a delivery, that default resolves to the picking's own source location (the parent WH/Stock), so the line is sourced from the parent instead of the sublocation where the serial physically sits.

https://github.com/odoo/enterprise/blob/f42cfa7265ce32bd95f7f805cf4fb54d8b79cce1/stock_barcode/static/src/models/barcode_picking_model.js#L1542-L1544

On validation the unit is deducted from the parent location instead of the sublocation, leaving a stale quant of the serial in the sublocation and a negative quant at the parent.

opw-5864414

**Steps to reproduce:**
* Install the **Accounting** module.
* Create two companies with different currencies (e.g. **USD** and **CAD**) sharing the same **Chart of Accounts**.
* Open a shared account and:
  * Add both companies in the **Company** field.
  * Under the **Mappings** tab, configure a mapping for each company.
* In each company, create and post a journal entry on the same shared account (for example, a receivable account) using the company's own currency.
* Set the journal entry dates to the **current month**.
* Open **Accounting → Reporting → General Ledger**.
* Change the reporting period to the **following month** so the posted entries are shown as the **Initial Balance**.
* Open the report separately for each company.

**Observed behavior:**
* From the **CAD company**, the Initial Balance displays **USD 2,000** instead of the expected **USD 1,000**.
* From the **USD company**, the **Currency** column on the Initial Balance is **blank**.

**Cause:**
* The SQL query for the `id_with_accumulated_balance` groupby used `SUM(amount_currency)` and `MIN(currency_id)` to aggregate all pre-period lines into a single Initial Balance row.
* In a multi-company shared Chart of Accounts, lines from different companies (each with their own currency) were collapsed into the same group, causing `SUM(amount_currency)` to add amounts across currencies and `MIN(currency_id)` to return an arbitrary currency ID.
* Additionally, the Python accumulation loop incorrectly performed **integer addition** on `currency_id` (a foreign key), further corrupting the displayed currency.

**Fix:**
* Replace `SUM(amount_currency)` and `MIN(currency_id)` with `CASE` expressions `MIN = MAX` is a uniformity check that works for **any number of currencies**: if every row in the group shares the same currency the condition is true and the correct sum is returned; if even one row differs the condition is false and both fields return `NULL`. The original three-column `GROUP BY (id, date, account_id)` is preserved.
* The Initial Balance row now correctly shows a **blank** currency column, consistent with the Odoo 18 behavior, instead of an incorrect aggregated foreign currency amount.

opw-6375310