Before this change, the "Outlook: synchronization" cron would not create calendar events on Outlook's side in _sync_odoo2microsoft due to a filter for calendar.events written to within 5 minutes of microsoft_last_sync_date, when _sync_data is not called when a calendar.event is created, such as through website.appointment. microsoft_last_sync_date was set to datetime.now() at the beginning of _sync_microsoft_calendar, which would skip a large period of time between the last sync and now, if the only syncs were triggered through cron, and not _sync_data (by opening the calendar app).

To reproduce, 

Default "Outlook: synchronization" is ran every 12 hours. 

1) Calendar event is synced through "Outlook: synchronization" cron at 00:00, setting microsoft_last_sync_date to 00:00
2) A website.appointment is created for a resource with Outlook calendar sync enabled any time between 00:01 - 11:54. 
3) "Outlook: synchronization" runs again at 12:00, which sets microsoft_last_sync_date to 12:00, and filters out calendar.events based on their write_dates in _extend_microsoft_domain that need syncing outside of 11:55 to 12:00. 

This change removes setting of microsoft_last_sync_date at the beginning of _sync_microsoft_calendar, where we need to use the old value before setting it at the end of _sync_microsoft_calendar.

opw-5212908

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

Forward-Port-Of: odoo/odoo#262665
Forward-Port-Of: odoo/odoo#245964

### Issue:
Some DIAN XML files of type `AttachedDocument` are incorrectly imported, resulting in no extracted data

This issue only occurs for `AttachedDocument` files

According to the DIAN documentation, the `ProfileID` should contain the literal `Factura Electrónica de Venta` https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Factura-Electronica-de-Venta-vr-1-9.pdf

However, no strict validation is enforced, so variants should still be supported

### Cause:
When importing a DIAN document of type `AttachedDocument`, `_get_import_file_type()` searches for a node starting with `DIAN 2.1:`

This causes issues with documents structured like:
```xml
<AttachedDocument>
	<CustomizationID>Documentos adjuntos</CustomizationID>
	<ProfileID>DIAN 2.1: Factura Electrónica de Venta</ProfileID>
</AttachedDocument>
```

In this case, `DIAN 2.1:` is detected first, causing the file to be identified as `account.edi.xml.ubl_dian`

As a result, the `<AttachedDocument>` wrapper is ignored and the importer tries to parse the file using the wrong structure, preventing any data extraction

The import should first detect the `<AttachedDocument>` structure, then unwrap and process the embedded document

### Steps to reproduce:
- Install `l10n_co_dian`
- Go in Bills and import the test document: `import_attached_document_2`

Before the fix, nothing it extracted from the xml

opw-6083523

Forward-Port-Of: odoo/enterprise#115599

Before this commit, a Stripe terminal payment could still be marked as `done` even if the capture step failed.

This happens when the card authorization succeeds, `processPayment` returns a payment intent, but the subsequent `stripe_capture_payment` RPC fails and `capturePaymentStripe()` returns `false`. The capture flow did not guard that return value and still fell through to `line.set_payment_status("done")`.

In practice, this can happen for example if the Odoo server cannot resolve `api.stripe.com` while capturing the payment intent. Stripe then keeps the payment in `requires_capture`, while the POS line is still synced as paid.

Guard the failed capture path and stop the flow before marking the line as done. In that case, the payment line is put back to `retry` so the failure is visible in the POS instead of silently creating a paid, uncaptured payment.

opw-6075384

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

Forward-Port-Of: odoo/odoo#263200
Forward-Port-Of: odoo/odoo#261521

### Issue before this commit:
Sales taxes at 7% and 5% were incorrectly mapped to the same tax report  tags as the 18% sales taxes, causing them to be reported under the  'Taxable Goods/Services at 18%' line. In addition, the 7% and 5% report  lines displayed negative amounts instead of positive ones.

### Steps to reproduce the issue:
1. Install l10n_mt
2. Create invoices using 18%, 7%, 5% taxes
3. Go to Accounting > Reporting > Tax Report
4. See the amounts for Taxable Goods/Services at 18% is negative and  all the invoices are reported into the Taxable Goods/Services at 18%  even if the tax applied to the invoice is 5% or 7%

### Cause of the issue:
An automatic script (https://github.com/odoo/odoo/pull/225252)  missed to invert sign of formulas for the 7% and 5% lines, so their  values were displayed with the wrong sign. Moreover it is assigned to  the 7% and 5% Malta sales taxes the III.1_base  and III.1_tax tags, which belong to the 18% tax report line.

### Reason to introduce the fix:
The tag mapping must match the tax report structure so that 18%, 7%, and 5% sales taxes are reported in their respective lines. The report formulas for the 7% and 5% lines must also use the proper sign convention to display positive amounts consistently.

opw-6015509

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

Forward-Port-Of: odoo/odoo#263073
Forward-Port-Of: odoo/odoo#254894

# Setup
For easiness of testing : have no purchase order in your dashboard

# How to reproduce
- Create a Purchase Order for Vendor X and with Product Y
- Click on Confirm Order -> Receive -> Validate
- Go back to the dashboard

# The problem
The displayed OTD is 0%, but when you go to the Vendor X form view and check his On-time Rate, it is 100%

# Cause
The computation for the On-time rate in the dashboard uses the whole datetime value, so if there is even a second of difference between `effective_date` and `date_planned`, the PO is not counted as on-time :
https://github.com/odoo/odoo/blob/942cbbbf243ff28f84fdaa40ed73b6572e0032a6/addons/purchase_stock/models/purchase_order.py#L253

That is not the case for the partner On-time rate computation, where we round the datetime value to the date value : https://github.com/odoo/odoo/blob/942cbbbf243ff28f84fdaa40ed73b6572e0032a6/addons/purchase_stock/models/res_partner.py#L57

opw-6128510

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

Forward-Port-Of: odoo/odoo#263015
Forward-Port-Of: odoo/odoo#260384

### Steps to reproduce:
- Download 'Sign' and 'Contacts' apps
- Create a contact with a really long name
- Create a sign document template with a multiline text field (Read-only) that has contact name value
- Click 'Sign Now' and put the new contact as the signer
- Sign and download
> The text appears as a single extended line exceeding field/page boundaries

### Cause of Issue:
The textarea and stamp field rendering only handled explicit newline characters (`\n`) and did not account for text that exceeded the field width. https://github.com/odoo/enterprise/blob/017743cbe97b629e9d9f1895b655014d4c3abbcb/sign/models/sign_document.py#L330-L345 When the HTML preview showed wrapped text, the PDF output rendered it as a single line. For continuous text without spaces, the text would overflow the field boundaries entirely.

### Fix:
Accounted for long texts that have spaces and long words to show all the information in the PDF

opw-6045062

Forward-Port-Of: odoo/enterprise#114813

Problem: When entering the barcode interface from a picking and scanning a different serial number than one already reserved, a new line gets created in certain situations. When exiting the barcode interface without validating the picking, both serial numbers show up on the picking view. However, the first serial number’s `stock.move.line` was deleted, so only one serial number should be there. 

When exiting the barcode interface a call to `post_barcode_process` is made, where the extra `stock.move.line` is deleted, but it doesn’t wait for the call to finish. 
https://github.com/odoo/enterprise/blob/d5a52cb79c9c41d792685d2858cfeb6aee147642/stock_barcode/static/src/models/barcode_picking_model.js#L1896

Purpose: By overriding `beforeQuit` to add the `_onExit` call, the component now waits for the `post_barcode_process` call to finish before navigating back to the picking view. This helps ensure the UI displays the updated data. 

Steps to reproduce on Runbot:
Create a product tracked by serial numbers.
Have 2 units on hand: serial 001 with a package, and serial 002 without a package. (This is needed so the barcode app will create a new line).
Create a delivery for 1 unit of our test product and mark it as todo.
Ensure that serial 001 is reserved.
Click the Barcode smart button and scan the barcode for serial 002.
Click the back button.
Observe that both serial numbers are shown on the picking. 
Refresh the page and observe only serial 002 is now shown. 

opw-6105740

Forward-Port-Of: odoo/enterprise#115491

Commit 072a8e4fd061ff23902e6e448a577624cb27e188 fixes edition of buttons by wrapping the editable button in an editable span. But it allows user to write outside the savable node, and allows user to copy website builder's branding attributes (which causes issues when pasted).

This commit adds a span inside the button instead of outside, and removes it before saving the content.

Steps to reproduce:
- Open website buider on `/product/item-1`
- Place the cursor in the "Add to cart" button
- Press left arrow, repeat until out of the button
- Bug: You can write text there, but it won't be saved

#####
- Open website buider on `/product/item-1`
- Select some text in the "Add to cart" button
- Copy (`ctrl+c`)
- Paste (`ctrl+v`)
- Bug: Some content seems duplicated: the branding of the savable button has been duplicated inside it and the automatic replication between identical fields is based on this branding, thus replicates the button's content inside it

Similar issue about copy+pasted branding: ec93d48ab17b4a72f61fa358e5a81d2abcb18897

Forward-Port-Of: odoo/odoo#257849

Currently, an error occurs when a user attempts to mark a payslip as paid.

**Steps to Reproduce:**

 - Install the `hr_payroll` module without demo data.
 - Go to `Payslips` and click on `New Off-cycle`.
 - Create a record > `Compute` > `Validate`, and Pay.
 - In the wizard, enable `Include Unpaid` and select `CSV` mode.
 - Click `Mark as Paid`.

**Error:**
`UnboundLocalError: cannot access local variable 'rows' where it is not associated with a value`

The error occurs when a user tries to mark a payslip as paid with Include Unpaid enabled. 
When the wizard is created from here [1], the default unpaid payslips are empty. In this case, 
the system assigns an empty set of payslips to process [2].and the rows variable is not 
defined because there are no payslips to work on, which raises the error [3].

This commit ensures that when the wizard is created, the matched unpaid payslips are passed to 
the wizard. If the Include Unpaid option is enabled, the unpaid payslips are assigned for processing, 
similar to [4]. The unpaid payslips cannot be empty, as they always include the currently 
processed payslip.
Also, the rows are redefined for each payslip case and updated accordingly. Therefore, this commit 
ensures that the rows are created at the end from grouped payments.

[1] https://github.com/odoo/enterprise/blob/a784d118e076724b02e5c59d9ce5d1815c42b0bf/hr_payroll/models/hr_payslip.py#L792-L809

[2] https://github.com/odoo/enterprise/blob/e971fca0d09e564ae9029f3d7e166e078c44dcbb/hr_payroll/wizard/hr_payroll_payment_report_wizard.py#L56

[3] https://github.com/odoo/enterprise/blob/e971fca0d09e564ae9029f3d7e166e078c44dcbb/hr_payroll/wizard/hr_payroll_payment_report_wizard.py#L97

[4]: https://github.com/odoo/enterprise/blob/a784d118e076724b02e5c59d9ce5d1815c42b0bf/hr_payroll/models/hr_payslip_run.py#L274-L288

sentry-7436885639

### Steps to reproduce:

- In the settings Enable: "Automatic accounting"
- Create a storable kit product with a storable component both invoiced on delivered qty and in an "automated" ('real_time') inventory valuation.
- Create a kit product with a component invoiced on delivered qty
- Create and confirm a sale order for 1 units of your kit
- On the delivery add a new move for 1 unit of your kit and save
#### > The new line should be exploded into the component
- Set the quantity on both moves and validate
- On the sale order > Create draft invoice > confirm
#### > User Error: The unit of measure Units defined on the order line doesn't belong to the same category as the unit of measure False defined on the product. Please correct the unit of measure defined on the order line or on the product. They should belong to the same category.

### Cause of the issue:

The issue occurs when the `_stock_account_get_anglo_saxon_price_unit` is launched on the account move line created for the extra component because the moves where generated from a kit and hence are associated with a `bom_line_id` but the the product it self is not a kit so that no bom will be found here:
https://github.com/odoo/odoo/blob/521111d50e9119a6286e4b0e236161b1b898f072/addons/sale_mrp/models/account_move.py#L12-L23 In particular, the rest of the call that tries to treat it as a kit will fail because no bom is and should be provided to this line: https://github.com/odoo/odoo/blob/521111d50e9119a6286e4b0e236161b1b898f072/addons/sale_mrp/models/account_move.py#L34

opw-6041375

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

Forward-Port-Of: odoo/odoo#261878
Forward-Port-Of: odoo/odoo#258141

With Employee Login enabled in POS, leaving the “Basic rights” field empty is meant to allow all employees to log in as basic cashiers.

In v19, configuring at least one Advanced/Minimal employee while keeping “Basic rights” empty incorrectly restricted the login list to only the explicitly configured employees (and the linked backend user), so other employees could no longer sign in.

Steps to reproduce:
-------------------
* Go to POS settings and enable Employee Login.
* Add at least one employee in Advanced rights.
* Leave Basic rights empty.
* Open POS login.

> Observation:
Only Advanced can sign in.
Other employees are missing.

Why the fix:
------------
The employee loading domain must only become restrictive when Basic rights is explicitly set. If Basic rights is empty, all company employees should remain selectable, and Advanced/Minimal should only affect roles, not visibility. Align with 19.1 behavior/state of code.

opw-6170066

Forward-Port-Of: odoo/odoo#263100
Forward-Port-Of: odoo/odoo#261939

### Issue:
Some DIAN XML files of type `AttachedDocument` are incorrectly imported, resulting in no extracted data

This issue only occurs for `AttachedDocument` files

According to the DIAN documentation, the `ProfileID` should contain the literal `Factura Electrónica de Venta` https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Factura-Electronica-de-Venta-vr-1-9.pdf

However, no strict validation is enforced, so variants should still be supported

### Cause:
When importing a DIAN document of type `AttachedDocument`, `_get_import_file_type()` searches for a node starting with `DIAN 2.1:`

This causes issues with documents structured like:
```xml
<AttachedDocument>
	<CustomizationID>Documentos adjuntos</CustomizationID>
	<ProfileID>DIAN 2.1: Factura Electrónica de Venta</ProfileID>
</AttachedDocument>
```

In this case, `DIAN 2.1:` is detected first, causing the file to be identified as `account.edi.xml.ubl_dian`

As a result, the `<AttachedDocument>` wrapper is ignored and the importer tries to parse the file using the wrong structure, preventing any data extraction

The import should first detect the `<AttachedDocument>` structure, then unwrap and process the embedded document

### Steps to reproduce:
- Install `l10n_co_dian`
- Go in Bills and import the test document: `import_attached_document_2`

Before the fix, nothing it extracted from the xml

opw-6083523

Forward-Port-Of: odoo/enterprise#115599

### Steps to reproduce:

- In the settings Enable: "Automatic accounting"
- Create a storable kit product with a storable component both invoiced on delivered qty and in an "automated" ('real_time') inventory valuation.
- Create a kit product with a component invoiced on delivered qty
- Create and confirm a sale order for 1 units of your kit
- On the delivery add a new move for 1 unit of your kit and save
#### > The new line should be exploded into the component
- Set the quantity on both moves and validate
- On the sale order > Create draft invoice > confirm
#### > User Error: The unit of measure Units defined on the order line doesn't belong to the same category as the unit of measure False defined on the product. Please correct the unit of measure defined on the order line or on the product. They should belong to the same category.

### Cause of the issue:

The issue occurs when the `_stock_account_get_anglo_saxon_price_unit` is launched on the account move line created for the extra component because the moves where generated from a kit and hence are associated with a `bom_line_id` but the the product it self is not a kit so that no bom will be found here:
https://github.com/odoo/odoo/blob/521111d50e9119a6286e4b0e236161b1b898f072/addons/sale_mrp/models/account_move.py#L12-L23 In particular, the rest of the call that tries to treat it as a kit will fail because no bom is and should be provided to this line: https://github.com/odoo/odoo/blob/521111d50e9119a6286e4b0e236161b1b898f072/addons/sale_mrp/models/account_move.py#L34

opw-6041375

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

Forward-Port-Of: odoo/odoo#261878
Forward-Port-Of: odoo/odoo#258141

Commit 072a8e4fd061ff23902e6e448a577624cb27e188 fixes edition of buttons by wrapping the editable button in an editable span. But it allows user to write outside the savable node, and allows user to copy website builder's branding attributes (which causes issues when pasted).

This commit adds a span inside the button instead of outside, and removes it before saving the content.

Steps to reproduce:
- Open website buider on `/product/item-1`
- Place the cursor in the "Add to cart" button
- Press left arrow, repeat until out of the button
- Bug: You can write text there, but it won't be saved

#####
- Open website buider on `/product/item-1`
- Select some text in the "Add to cart" button
- Copy (`ctrl+c`)
- Paste (`ctrl+v`)
- Bug: Some content seems duplicated: the branding of the savable button has been duplicated inside it and the automatic replication between identical fields is based on this branding, thus replicates the button's content inside it

Similar issue about copy+pasted branding: ec93d48ab17b4a72f61fa358e5a81d2abcb18897

The session id rotates softly every 3 hours

For some features, the mobile app sometimes does requests "outside" of the mobile app, through a webview for instance, and if the session rotation interval is reached at that moment, it rotates the session and the `set-cookie`
instruction setting the new session cookie is received by the webview only, it's not propagated back to the mobile app.

Then, this could lead for the user to be logged out of the mobile app if the soft automatic session rotation happens at the very unfortunate moment the request through that webview happens.

For instance, the mobile app uses a webview to download attachments. If the session rotation happened during that request, the mobile app doesn't receive the `set-cookie` header and doesn't receive the new session id, leading for the user to be logged out of the mobile app.

This revision aims to provide an option for the mobile app to temporary skip the session rotation for a specific request, such as the requests done through the webview during downloads.

This option to be able to disable the rotation is not a security threat: If an attacker passes that header to disable the interval session rotation, he would avoid the session to be changed every 3 hours, but if he wouldn't he would still receive the new session id every 3 hours.
The session rotation is for legitimate user / computer to rotate their session every 3 hours so that in case of data leak of their browser cookies, there is a chance the session cookie is already no longer valid when published on the public web. Legitimate users have no benefit using this option header to disable the rotation.

Forward-Port-Of: odoo/odoo#263325

### Steps to reproduce:
- Download 'Sign' and 'Contacts' apps
- Create a contact with a really long name
- Create a sign document template with a multiline text field (Read-only) that has contact name value
- Click 'Sign Now' and put the new contact as the signer
- Sign and download
> The text appears as a single extended line exceeding field/page boundaries

### Cause of Issue:
The textarea and stamp field rendering only handled explicit newline characters (`\n`) and did not account for text that exceeded the field width. https://github.com/odoo/enterprise/blob/017743cbe97b629e9d9f1895b655014d4c3abbcb/sign/models/sign_document.py#L330-L345 When the HTML preview showed wrapped text, the PDF output rendered it as a single line. For continuous text without spaces, the text would overflow the field boundaries entirely.

### Fix:
Accounted for long texts that have spaces and long words to show all the information in the PDF

opw-6045062

Forward-Port-Of: odoo/enterprise#114813

Problem: When entering the barcode interface from a picking and scanning a different serial number than one already reserved, a new line gets created in certain situations. When exiting the barcode interface without validating the picking, both serial numbers show up on the picking view. However, the first serial number’s `stock.move.line` was deleted, so only one serial number should be there. 

When exiting the barcode interface a call to `post_barcode_process` is made, where the extra `stock.move.line` is deleted, but it doesn’t wait for the call to finish. 
https://github.com/odoo/enterprise/blob/d5a52cb79c9c41d792685d2858cfeb6aee147642/stock_barcode/static/src/models/barcode_picking_model.js#L1896

Purpose: By overriding `beforeQuit` to add the `_onExit` call, the component now waits for the `post_barcode_process` call to finish before navigating back to the picking view. This helps ensure the UI displays the updated data. 

Steps to reproduce on Runbot:
Create a product tracked by serial numbers.
Have 2 units on hand: serial 001 with a package, and serial 002 without a package. (This is needed so the barcode app will create a new line).
Create a delivery for 1 unit of our test product and mark it as todo.
Ensure that serial 001 is reserved.
Click the Barcode smart button and scan the barcode for serial 002.
Click the back button.
Observe that both serial numbers are shown on the picking. 
Refresh the page and observe only serial 002 is now shown. 

opw-6105740

Forward-Port-Of: odoo/enterprise#115491

The employment subsidy calculation was incorrect in two main scenarios:

### 1. Incorrect threshold prorating:

The system was comparing the salary against the full monthly limit even for partial periods (weekly or bi-weekly). This resulted in employees wrongly receiving the subsidy when their proportional salary actually exceeded the limit.

Example: In 2026, the 14-day threshold should be 5,292.67 (11,492.66 / 30.4 * 14). Currently, an employee earning 10,000.00 in those 14 days still gets the subsidy because it's being compared against the full 11,492.66.

### 2. Cumulative monthly cap:

When multiple payslips occur in the same month, the total subsidy sometimes exceeds the statutory monthly maximum (536.22 for 2026) because the cap wasn't enforced across all slips.

Example: The 2026 maximum monthly subsidy is 536.22. In a month with three partial payslips:
- Mar 1st - Mar 14th: The system grants 246.68.
- Mar 15th - Mar 28th: The system grants 246.68.
- Mar 29th - Apr 11th: For the 3 days belonging to March, the system grants an additional 52.86.
Total subsidy for March reaches 546.22, exceeding the legal cap.

### Changes included in this PR:
- Updated `l10n_mx_rule_parameter_uma` to include monthly and annual values. This prevents rounding discrepancies.
  Example: the 2026 annual UMA published is 42,794.64. In a rule the calculation is: l10n_mx_uma * 30.4 * 12 = 117.31 * 30.4 * 12 = 42,794.68 resulting in a ~0.04 difference.

- Create a new rule parameter `l10n_mx_rule_parameter_subsidy_salary_limit` to have the subsidy eligible threshold. Starting in 2026, the government's rounding changed from zero decimals(e.g., 9,081.00 in 2024, 10,171.00 in 2025) to two decimals (11,492.66). Storing these as explicit parameters avoids the precision errors.

- Added comprehensive unit tests covering:
  - Complete periods: validates standard payslips aligned with the month calendar (bi-monthly, monthly, bi-weekly).
  - Overlapping periods: validates split-month scenarios (14-day, 10-day, weekly) where periods cross month boundaries:
    Example of self._overlapping_period("weekly", 7, 2646.33, (35.24, 88.10), (3, 123.34), (77.53, 35.24))
    This test covers 5 weekly payslips with the following subsidy
    distribution:
    - Tuple `first_payslip` => (35.24, 88.10) means that:
      First payslip (Apr 29 - May 5), the subsidy is 35.24 for April and 88.10 for May.
    - Tuple `mid_payslips` => (3, 123.34) means that:
      For the next 3 payslips fully in May, the subsidy is 123.34 each.
      Payslip 2 (May 6 - May 12): Subsidy for May = 123.34
      Payslip 3 (May 13 - May 19): Subsidy for May = 123.34
      Payslip 4 (May 20 - May 26): Subsidy for May = 123.34
    - Tuple `last_payslip` => (77.53, 35.24) means that:
      Last payslip (May 27 - June 2), the subsidy is 77.53 for May and 35.24 for June.
  - Across years: subsidy amounts and limits are updated annually.
    Therefore, if a period overlaps two years, a salary amount might be eligible for a subsidy in January but not in the previous December, and the paid subsidy is increased in January due to the new limits.

- Cleaned up redundant tests (test_regular_payslip_subsidy) and adjusted decimal precision.

- For split-month `schedule_pay` periods, the first payslip might generate a subsidy. However, in subsequent payslips, due to commissions or a wage increase, the employee may exceed the monthly subsidy salary limit.
  In those payslips, a warning is shown to notify the user that a manual adjustment is required.
  Created tests to validate these cases.

target: 19.0
task-5419659

Forward-Port-Of: odoo/enterprise#107601

Steps to reproduce
1. Set the company's partner timezone to a negative UTC offset (e.g. America/Argentina/Buenos_Aires, UTC-3).
2. Create a sale order for a storable subscription product and confirm it.
3. Open the generated delivery order and check its Scheduled Date.

Issue
The scheduled date on the first delivery renders as the previous day. `_prepare_procurement_values` writes `date_planned` as `current_period_start`, which is a plain `fields.Date` value
(https://github.com/odoo/enterprise/blob/ba41d7de3c0474286e3e9319710fdacfb95d3e2c/sale_subscription_stock/models/sale_order_line.py#L156). When a `date` is stored in the `Datetime` column `stock.move.date`, Odoo anchors it at midnight UTC; in any negative-offset timezone this renders as the previous day (e.g. `2022-03-02 00:00 UTC` shows as `2022-03-01 21:00` in UTC-3). The non-subscription path does not hit this because it resolves `date_planned` through `_expected_date()`, which returns `order_id.date_order` — a full `Datetime` set to `fields.Datetime.now()` at confirmation (https://github.com/odoo/odoo/blob/996702b0d5c518db2ac6f0b144e7835b27c29736/addons/sale/models/sale_order_line.py#L1398).

The same midnight-UTC drift also affects later recurrences, where `current_period_start` falls back to `last_invoice_date` — another `Date`.

Solution
Split the two cases explicitly:
- First delivery (`last_invoice_date` unset): set `date_planned` to `order_id.date_order`, matching the non-subscription flow.
- Subsequent deliveries: localize `last_invoice_date` at `00:00` in the company timezone before converting back to UTC, reusing the pattern already applied to reordering rules (https://github.com/odoo/odoo/blob/20a0eee2d03293564320c268252a0353781d99ea/addons/stock/models/stock_orderpoint.py#L722).

opw-6133831

Forward-Port-Of: odoo/enterprise#116362
Forward-Port-Of: odoo/enterprise#115100

### Issue before this commit:
The XML export for branch companies incorrectly identified the branch as the sender, even when a Peppol parent company was configured.

### Steps to reproduce the issue:
1. Download Accounting, Contacts and l10n_be
2. Create a branch for a Belgium company
3. Enable Peppol sending on the parent company
4. Enable Peppol sending on the branch company using the parent company endpoint
5. Switch to branch company
6. Create a customer invoice in the branch company using a customer who is on the Peppol network (meaning insert a valid VAT number and then verify button in the Accounting tab)
7. Confirm and send the invoice via Peppol
8. Download the resulting xml file and check the "AccountingSupplierParty" nodes. It contains the data of the branch and not the ones of the parent company

### Cause of the issue:
The EDI export logic was fetching the supplier data directly from the invoice's company record without checking for a delegated Peppol parent company, ignoring the hierarchical relationship defined in the settings.

### Reason to introduce the fix:
This fix ensures that the AccountingSupplierParty in the UBL/CII file correctly reflects the parent company's data when applicable.

opw-6030526

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

Forward-Port-Of: odoo/odoo#260389

**Problem:**
After importing records through the Import action, the list view that opens with the imported records does not inherit the context of the originating action. Column visibility and default values that depend on that context (e.g. `default_move_type` on the shared invoice list) end up wrong.

**Steps to reproduce:**
1. Go to Accounting → Customers → Invoices
2. Click "Favorites → Import records"
3. Upload a CSV containing at least one valid customer invoice row
4. Run the import and look at the "Imported records" list that opens

**Current behavior:**
The imported records list opens with an empty context. Columns rendered conditionally on `default_move_type` (invoice-type-specific columns on `account.view_invoice_tree`) are not shown as they are when opening the list from the menu, and records created from that list have no default move type.

**Expected behavior:**
The imported records list should open with the same context as the action the user started the import from (e.g.
`{ default_move_type: 'out_invoice' }` for customer invoices), so columns and defaults match the previous view.

**Cause of the issue:**
`openRecords()` in `import_action.js` builds the follow-up `ir.actions.act_window` but never forwards `this.model.context`. The model already holds the context passed through the import action's `params.context`, but it is dropped when the redirect action is dispatched, so the window action opens with an empty context.

**Fix:**
Forwarding the context the import was launched with keeps the user inside the same functional scope (invoice type, default partner, company, etc.) when they land on the imported records list. Column visibility logic and default values that rely on that context behave identically to opening the list through the normal menu flow.

opw-6120758

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#261309

## Issue
When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive.

## Steps to reproduce
1. Install *United States - Payroll* (`l10n_us_hr_payroll`)
2. Set the current company's State to Colorado
3. Create an employee and a contract
    - Wage: $0
    - (Set the contract's status to *Running*)
    - (In the payroll tab) State Withholding Allowance: $1000
4. Create a Payslip for the employee
    - Structure: *"United States: Regular Pay"*
5. Compute Sheet
6. **In the _Salary Computation_ tab, the _CO State Income Tax_ line has a positive value**

## Justification
This fix is similar to the one applied for the AL(abama) state income tax by https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6. That modification was justified by CAS (PO of US localizations for Payroll) in opw-5137280:

> *"Payroll taxes are always funds withheld from employee's paychecks, if there is a positive value it means the tax is a refund, not a withholding. Refunds happen when individuals file their income."*

## Note to reviewer
The test [`test_069_al_state_tax_0_income`](https://github.com/odoo/enterprise/blob/219d2a797ee2099c9d77c2defc9c9c5e1d504ffe/test_l10n_us_hr_payroll_account/tests/test_salary_rules.py#L957-L989) (added by the aforementioned commit https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6) is wrongly indented and thus never executed. The test passes with the dedicated fix, and fails without it, as expected. Let me know if you want me to indent it correctly (in this commit or in an additional one).



opw-5999856

Forward-Port-Of: odoo/enterprise#116305
Forward-Port-Of: odoo/enterprise#112724

## Issue
When generating a DMFA report with a working schedule with more or less than 5 days a week, the *Days Per Week* value in the report is still appearing as 5.

## Steps to reproduce
1. Install *Belgium - Payroll* (`l10n_be_hr_payroll`)
2. In Payroll's Settings:
    - set *ONSS Registration Number* to `0830123456`
    - set *DMFA Employer Class* to `083`
    - create a *Work Address DMFA code* (any name, any numeral code, but set the *Working Address* to the Belgian company used for the rest of the steps)
3. In Employees' Settings, set the *Company Working Hours* to a new Working Schedule, with 9 hours/day, 4 days/week. E.g from Monday to Thursday included:
    - Work from 8:00 to 12:00
    - Lunch from 12:00 to 13:00
    - Work from 13:00 to 18:00
4. Create an Employee E for the Belgian company:
    - In the *Payroll* tab, set the start date of the contract to 01/01/2026.
    - In the *Personal* tab, set the *NISS Number* to `85073003328`
5. Create the payslip for January 2026 for the Employee E.
6. In Payroll > Reporting > Belgium > DMFA, create a new DMFA for the first quarter of 2026 and generate the PDF report
7. **In the generated PDF report, the _Days per Week_ line is set to 5.**

## Cause
The number of days was calculated by multiplying `5` with the `work_time_rate` of the related calendar. This is inaccurate in the case of a company where employees are only expected to work 4 days a week.

opw-6103934

Forward-Port-Of: odoo/enterprise#116465
Forward-Port-Of: odoo/enterprise#113804

## Issue
When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive.

## Steps to reproduce
1. Install *United States - Payroll* (`l10n_us_hr_payroll`)
2. Set the current company's State to Colorado
3. Create an employee and a contract
    - Wage: $0
    - (Set the contract's status to *Running*)
    - (In the payroll tab) State Withholding Allowance: $1000
4. Create a Payslip for the employee
    - Structure: *"United States: Regular Pay"*
5. Compute Sheet
6. **In the _Salary Computation_ tab, the _CO State Income Tax_ line has a positive value**

## Justification
This fix is similar to the one applied for the AL(abama) state income tax by https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6. That modification was justified by CAS (PO of US localizations for Payroll) in opw-5137280:

> *"Payroll taxes are always funds withheld from employee's paychecks, if there is a positive value it means the tax is a refund, not a withholding. Refunds happen when individuals file their income."*

## Note to reviewer
The test [`test_069_al_state_tax_0_income`](https://github.com/odoo/enterprise/blob/219d2a797ee2099c9d77c2defc9c9c5e1d504ffe/test_l10n_us_hr_payroll_account/tests/test_salary_rules.py#L957-L989) (added by the aforementioned commit https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6) is wrongly indented and thus never executed. The test passes with the dedicated fix, and fails without it, as expected. Let me know if you want me to indent it correctly (in this commit or in an additional one).



opw-5999856

Forward-Port-Of: odoo/enterprise#116305
Forward-Port-Of: odoo/enterprise#112724

## Issue
When generating a DMFA report with a working schedule with more or less than 5 days a week, the *Days Per Week* value in the report is still appearing as 5.

## Steps to reproduce
1. Install *Belgium - Payroll* (`l10n_be_hr_payroll`)
2. In Payroll's Settings:
    - set *ONSS Registration Number* to `0830123456`
    - set *DMFA Employer Class* to `083`
    - create a *Work Address DMFA code* (any name, any numeral code, but set the *Working Address* to the Belgian company used for the rest of the steps)
3. In Employees' Settings, set the *Company Working Hours* to a new Working Schedule, with 9 hours/day, 4 days/week. E.g from Monday to Thursday included:
    - Work from 8:00 to 12:00
    - Lunch from 12:00 to 13:00
    - Work from 13:00 to 18:00
4. Create an Employee E for the Belgian company:
    - In the *Payroll* tab, set the start date of the contract to 01/01/2026.
    - In the *Personal* tab, set the *NISS Number* to `85073003328`
5. Create the payslip for January 2026 for the Employee E.
6. In Payroll > Reporting > Belgium > DMFA, create a new DMFA for the first quarter of 2026 and generate the PDF report
7. **In the generated PDF report, the _Days per Week_ line is set to 5.**

## Cause
The number of days was calculated by multiplying `5` with the `work_time_rate` of the related calendar. This is inaccurate in the case of a company where employees are only expected to work 4 days a week.

opw-6103934

Forward-Port-Of: odoo/enterprise#116465
Forward-Port-Of: odoo/enterprise#113804

### Issue:
When changing the delivery date (used as the Hungarian exchange rate date), some journal lines could be recomputed incorrectly, leading to unbalanced entries

### Cause:
`expected_currency_rate` was recomputed when `delivery_date` changed, but the new value was never automatically applied

In addition, after https://github.com/odoo/odoo/pull/225407, `_sync_tax_lines` partially updated the lines:
https://github.com/odoo/odoo/blob/f5501e5c8dcf60444077912db4c87e7a3f2654a6/addons/account/models/account_move.py#L3029-L3031
https://github.com/odoo/odoo/blob/f5501e5c8dcf60444077912db4c87e7a3f2654a6/addons/account/models/account_move.py#L1633-L1637
These methods reapply the previous tax rate, causing base and tax lines to be updated inconsistently
As a result, when the base amount increases, the tax amount decreases, and vice versa

### Steps to reproduce:
- Install `l10n_hu_edi` and `accountant` with demo data, then switch to the `HU company`
- Go to Currencies → USD and add two rates:
April 5: HUF per Unit = 100
April 6: HUF per Unit = 150
- Create an Invoice: (Any customer, Currency: USD, Line: Price = 1000, Tax = 27%)
- Open the Journal Items and duplicate the browser tab for comparison
- In the duplicated tab, change the Delivery Date to April 5 and save
- Change the Delivery Date back to today and compare both tabs

### Before the fix:
The values differ between both tabs because the tax lines keeps the old exchange rate

opw-5801126

Forward-Port-Of: odoo/odoo#258310

**Issue:**
In the navbar view, when a user starts in mobile view (narrow width) and then increases the screen width (e.g., by zooming out or resizing), the menu items and app icon do not reappear. The navbar remains stuck in mobile mode even when there is enough space to display the full layout.

**Fix:**
The navbar was relying on `env.isSmall`, which is only set during initialization and does not react to window resizing. This has been updated to use `this.ui.isSmall`, which is reactive and updates dynamically when the viewport size changes.

**Before:**
After resizing from mobile to a larger width, the navbar continued to behave as if it were still in mobile view, keeping menu items and the app icon hidden.

**After:**
When the screen width increases, the navbar correctly detects the change and re-renders, restoring the menu items and app icon as expected.

opw-6107660

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

Forward-Port-Of: odoo/odoo#263296
Forward-Port-Of: odoo/odoo#263039

**Description of the issue/feature this PR addresses:**
The `WebsiteEvent._getEventObjectId` method lacks a specific match case for the root directory, causing event ID retrieval to fail on the homepage.

In order to resolve this, I've implemented a default return of 0 when the URL pattern matching fails [following the pattern established by later revisions of this code](https://github.com/odoo/odoo/blob/2199f71070ce3e9a4717eb6b750c14485406f7aa/addons/website_event/static/src/website_builder/event_page_option_plugin.js#L67).

**Steps to reproduce bug:**
1. Create an event website
2. Create an event and visit it
3. On the page click Site > Properties
4. Enable `Is Homepage`
5. Return to the homepage of the application and open the editor

https://drive.google.com/file/d/1OpCUAp4LJKqkoStciWeJEGVVlR3qpw1R/view?usp=drive_link

**Current behavior before PR:**

https://drive.google.com/file/d/1c7ACqaQx03mePzJSV_RoPn8mlLWSMa1I/view?usp=drive_link

**Desired behavior after PR is merged:**

https://drive.google.com/file/d/1L3Ne9h6-yB3v7VbXipjly9OrDSkZvDOu/view?usp=drive_link

opw-6101680

Forward-Port-Of: odoo/odoo#258502

## Issue
When generating a DMFA report with a working schedule with more or less than 5 days a week, the *Days Per Week* value in the report is still appearing as 5.

## Steps to reproduce
1. Install *Belgium - Payroll* (`l10n_be_hr_payroll`)
2. In Payroll's Settings:
    - set *ONSS Registration Number* to `0830123456`
    - set *DMFA Employer Class* to `083`
    - create a *Work Address DMFA code* (any name, any numeral code, but set the *Working Address* to the Belgian company used for the rest of the steps)
3. In Employees' Settings, set the *Company Working Hours* to a new Working Schedule, with 9 hours/day, 4 days/week. E.g from Monday to Thursday included:
    - Work from 8:00 to 12:00
    - Lunch from 12:00 to 13:00
    - Work from 13:00 to 18:00
4. Create an Employee E for the Belgian company:
    - In the *Payroll* tab, set the start date of the contract to 01/01/2026.
    - In the *Personal* tab, set the *NISS Number* to `85073003328`
5. Create the payslip for January 2026 for the Employee E.
6. In Payroll > Reporting > Belgium > DMFA, create a new DMFA for the first quarter of 2026 and generate the PDF report
7. **In the generated PDF report, the _Days per Week_ line is set to 5.**

## Cause
The number of days was calculated by multiplying `5` with the `work_time_rate` of the related calendar. This is inaccurate in the case of a company where employees are only expected to work 4 days a week.

opw-6103934

Forward-Port-Of: odoo/enterprise#116465
Forward-Port-Of: odoo/enterprise#113804

### Issue:
Some DIAN XML files of type `AttachedDocument` are incorrectly imported, resulting in no extracted data

This issue only occurs for `AttachedDocument` files

According to the DIAN documentation, the `ProfileID` should contain the literal `Factura Electrónica de Venta` https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Factura-Electronica-de-Venta-vr-1-9.pdf

However, no strict validation is enforced, so variants should still be supported

### Cause:
When importing a DIAN document of type `AttachedDocument`, `_get_import_file_type()` searches for a node starting with `DIAN 2.1:`

This causes issues with documents structured like:
```xml
<AttachedDocument>
	<CustomizationID>Documentos adjuntos</CustomizationID>
	<ProfileID>DIAN 2.1: Factura Electrónica de Venta</ProfileID>
</AttachedDocument>
```

In this case, `DIAN 2.1:` is detected first, causing the file to be identified as `account.edi.xml.ubl_dian`

As a result, the `<AttachedDocument>` wrapper is ignored and the importer tries to parse the file using the wrong structure, preventing any data extraction

The import should first detect the `<AttachedDocument>` structure, then unwrap and process the embedded document

### Steps to reproduce:
- Install `l10n_co_dian`
- Go in Bills and import the test document: `import_attached_document_2`

Before the fix, nothing it extracted from the xml

opw-6083523

Forward-Port-Of: odoo/enterprise#115599

Currently, generating the Swiss Master Data report raises an error

### **Steps to reproduce:**
1) Install `l10n_ch_hr_payroll` with demo data.
2) Switch to a Swiss company.
3) Navigate to `Payroll > Reporting > Master Data`. 
4) Create a new report and click Generate Data.

### **Error:**
IndentationError: expected an indented block after 'else' statement on line 116

### **Root Cause:**
The QWeb template had a conditional block using `t-elif` followed by an empty `t-else` at [1]. During template compilation, this generated a Python `else` statement without a body, leading to an IndentationError.

[1]- https://github.com/odoo/enterprise/blob/b77984b3a9fb1b35c07e152a0f86aaf4d430e2c0/l10n_ch_hr_payroll/report/l10n_ch_wage_type_report.xml#L44

### **Fix:**
This commit prevents the error by removing the empty `t-else` block and ensuring `category_ids` are properly evaluated by computing their codes and checking if they include `BASIC`, `ALW`, or `DED`.

**opw-6107565**

Forward-Port-Of: odoo/enterprise#113808

On a multi-website / single-company setup, helpdesk notification emails posted after the initial confirmation contained a "View Ticket" button pointing to the wrong website, always the company's default website instead of the website the ticket was created from.

Steps to reproduce:
===================
1. Create two websites W1 (seq 1) and W2 (seq 2) under the same company, with distinct domains.
2. Create two helpdesk teams with "Submit a Ticket" enabled, each bound to one website (Helpdesk1 -> W1, Helpdesk2 -> W2).
3. From W2, submit a ticket on /helpdesk/helpdesk2.
4. In the ticket, send email from the chatter.
5. Inspect the outgoing notification email.

=> "View Ticket" button points to W1's domain.

Root cause:
============
`helpdesk.ticket` has no `website_id`, so `Base.get_base_url`
 falls through to `company_id.website_id.domain`, i.e. the first
website of the company by sequence. The first confirmation message looked right only because it was posted inside a website request, where `website.get_current_website()` provided the correct context; subsequent agent replies are posted from the ticket with no such context, so the fallback kicked in.

Override `get_base_url` on `helpdesk.ticket` to prefer `team_id.website_id.domain` when set, so every notification on the ticket links back to the website the customer submitted it from.

=> "View Ticket" button points to W2's domain (the site the
   customer is browsing).

opw-6071999

Forward-Port-Of: odoo/enterprise#116034
Forward-Port-Of: odoo/enterprise#114693

### Issue:
Some DIAN XML files of type `AttachedDocument` are incorrectly imported, resulting in no extracted data

This issue only occurs for `AttachedDocument` files

According to the DIAN documentation, the `ProfileID` should contain the literal `Factura Electrónica de Venta` https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Factura-Electronica-de-Venta-vr-1-9.pdf

However, no strict validation is enforced, so variants should still be supported

### Cause:
When importing a DIAN document of type `AttachedDocument`, `_get_import_file_type()` searches for a node starting with `DIAN 2.1:`

This causes issues with documents structured like:
```xml
<AttachedDocument>
	<CustomizationID>Documentos adjuntos</CustomizationID>
	<ProfileID>DIAN 2.1: Factura Electrónica de Venta</ProfileID>
</AttachedDocument>
```

In this case, `DIAN 2.1:` is detected first, causing the file to be identified as `account.edi.xml.ubl_dian`

As a result, the `<AttachedDocument>` wrapper is ignored and the importer tries to parse the file using the wrong structure, preventing any data extraction

The import should first detect the `<AttachedDocument>` structure, then unwrap and process the embedded document

### Steps to reproduce:
- Install `l10n_co_dian`
- Go in Bills and import the test document: `import_attached_document_2`

Before the fix, nothing it extracted from the xml

opw-6083523

Forward-Port-Of: odoo/enterprise#115599

Before this commit, finding a bom for a recordset of `products` involved looping over all the boms and it will loop over all the `product_variant_ids` of `bom.product_tmpl_id` if the bom's `product_id` is NULL. This approach might loop over variants which we are not trying to find a bom for. In additon to that, due to the fact that multiple boms might have the same `product_tmpl_id`, this approach might consider the same variants in the inner loop redundantly even though we matched the variant with a bom in a previous itration.

Worst case, this might result in a time complexity of $O(N * M)$ where N is the number of boms and M is the number of variants.

To improve the performance, I only considered the variants given in the paramater `products` and in addition to that, I created a new dictionary mapping a `product_tmpl_id` to its bom if the bom doesn't have a variant set. By doing this, I can loop over the `products` given and if it doesn't have a bom set then it will be set to the one its template had taken from the previos loop.

In a method call with the following constraints
    - **2** products the method was finding a bom for
    - The 2 products had the same template and the template contained **550** active variants
    - The boms were only related to the template rather than the variants themselves.

| Input Size | Before | After |
| :--- | :--- | :--- |
| 100 | 0.78s | 0.03s |
| 1000 | 8.53s | 0.11s |
| 10000 | 80.99s | 0.73s |

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