> 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 the `Sales` module.
- In Settings, enable `Automatic Invoice`.
- Also enable the Demo payment provider.
- Create a sale order with a total of `800` and confirm it.
- Generate a payment link for `200` from the gear icon and pay it.
- Generate a second payment link for `300` and pay it.
- Generate a final payment link for the remaining `300` and pay it.

Issue:
---
- After the first payment (200), an `invoice of 200` is created. Correct.
- After the second payment (300), an` invoice of 500` is created instead of 300.
- After the third payment (300), an `invoice of 100` is created instead of 300.

Root cause:
---
- The down payment invoice uses `order.amount_paid`, the cumulative sum of all transactions on the order, instead of the amount of the latest payment. This causes invoices to be sized off the running total instead of the individual payment delta.

Fix:
---
- Compute the invoice amount as `order.amount_paid - order.amount_invoiced` (the unpaid) instead of passing the cumulative `amount_paid` directly.

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

Forward-Port-Of: odoo/odoo#283111
Forward-Port-Of: odoo/odoo#273099

## Current behavior:
On a Monday–Friday working schedule, a Daily accrual plan that is based on worked time grants accrued time on Saturday as well, even though Saturday is not a working day. The employee accrues on 6 days per week instead of 5 (Sunday is correctly skipped. Only Saturday is wrong).

## Expected behavior:
The employee accrues only on the 5 working days (Mon–Fri) → 5 grants per week. Saturday and Sunday should add nothing.

## Setup:
- Working schedule: Standard 40h/week, Monday–Friday, 08:00–17:00.
- All timezones set to Australia/Brisbane (UTC+10) and matching: employee, working schedule, and user are all the same timezone.
- Accrual plan milestone: accrue 5 Hours, Daily, "At the end of the accrual period", "Based on worked time = Yes".

## Steps to reproduce:
- Create the working schedule and accrual plan above, with the calendar timezone set to Australia/Brisbane.
- Assign the accrual allocation to an employee, Starting on a Monday.
- On the Time Off dashboard, use "Balance at the (date)" to project the balance day by day across a weekend (Friday → Saturday → Sunday → Monday).

## Cause of the issue:
Accrual period boundaries were built as naive UTC midnights instead of local calendar midnights.

## Fix:
Localize accrual period boundaries in the employee/resource timezone before calling resource calendar APIs.

This bug is reproducible in multiple versions. PRs for:
- v19.0: https://github.com/odoo/odoo/pull/279029
- v18.0: https://github.com/odoo/odoo/pull/279036

opw-6316062

Forward-Port-Of: odoo/odoo#282026
Forward-Port-Of: odoo/odoo#279029

Steps to reproduce
----------------------------------------
1. Install the SMS Marketing module (mass_mailing_sms).
2. Open any SMS Marketing record in the "Sent" or "Sending" stage.
3. Click on the "Insert Field" button.

Observation
----------------------------------------
Traceback Occurs:
```
TypeError: Cannot read properties of null (reading 'getRootNode')
```

Issue
----------------------------------------
The SMS widget displays the "Insert Field" button even when the SMS message
field is readonly. The button relies on the textarea reference to open the
dynamic fields popover, but the textarea is only rendered in editable mode.

The readonly behavior of the text field can be seen here:
https://github.com/odoo/odoo/blob/ccce9fcc79edcfb1f310b49a16de8235d987b74b/addons/web/static/src/views/fields/text/text_field.xml#L5-L7

However, the SMS widget still renders the "Insert Field" button without
checking whether the message field is readonly:
https://github.com/odoo/odoo/blob/ccce9fcc79edcfb1f310b49a16de8235d987b/addons/sms/static/src/components/sms_widget/fields_sms_widget.xml#L6

As a result, clicking the button in readonly mode tries to access an
unavailable textarea reference to open the dynamic fields popover, causing
a traceback.

Solution
----------------------------------------
Hide the "Insert Field" button when the SMS message field is readonly,
preventing the dynamic fields popover from being opened when the textarea
reference is unavailable.

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

Forward-Port-Of: odoo/odoo#282845

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

* = de, din5008, din5008_purchase, din5008_repair, din5008_sale

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

**Observed behavior (commercial register):**

* The footer always shows `HRB-Nr.:` regardless of whether the company has a commercial register entry.
* The abbreviation `HRB-Nr.:` appears even for Austrian and Swiss companies, where the commercial register number is a German-specific concept.
* In the company form view, the field is labeled generically as "Company ID" instead of "Commercial Register Number" for German companies.

**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`).

**Cause (commercial register):**

* The footer renders `company.company_registry` unconditionally with no country guard and no label.

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

**Fix (commercial register):**

* Remove the hardcoded `HRB-Nr.:` label from the footer and instead render `company.partner_id.company_registry_label` (which is country-aware).
* Update the duplicate contact warning message to use the country-aware label via `company.partner_id.company_registry_label`, backed by a new `_get_company_registry_labels` override in l10n_de that registers `Commercial Register Number` for `DE`.
* In the company form view (`l10n_de`), hide the generic "Company ID" field for German companies and show a relabeled instance with `string="Commercial Register Number"` instead.

opw-6392649

Forward-Port-Of: odoo/odoo#282964
Forward-Port-Of: odoo/odoo#279085

Problem: 
When a `table` with a `color`/`backgroundColor` contains a nested `table`, `distributeTableColorsToAllCells` propagates the outer table's color to every `td` in the subtree, including cells belonging to the inner table. The inner table's own color is then discarded since its `td`s already have a value.

Cause: 
`table.querySelectorAll("td")` returns every `td` in the entire subtree, not just the table's own direct cells.

Solution:
Scope the selected `td`s to `td.closest("table") === table`, so a table's color is only distributed to its own cells.

Steps to reproduce:
1. Add a `background-color` to an outer `table`.
2. Nest a `table` with a different `background-color` inside one of its cells.
3. Load/normalize the content in the editor.
4. Observe both tables' cells carry the outer table's color.

opw-6438972

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

Forward-Port-Of: odoo/odoo#281850
Forward-Port-Of: odoo/odoo#281413

_get_all_addr() feeds the postal address block of generated pain.001
payment files, but does not return the partner's state nor the second
street line. The beneficiary state/province and street complement
(suite, unit, ...) therefore never appear in the generated file, even
when they are set on the partner, and there is no way to fix it from
the record. 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.

Return the state code and street2 alongside the other address
components, from the partner for the base implementation and from the
employee private address for the hr one, so the payment engine can
write them in the PstlAdr block.

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


Companion enterprise PR emitting the state in the generated file: odoo/enterprise#127958

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

Forward-Port-Of: odoo/odoo#282620
Forward-Port-Of: odoo/odoo#282518