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

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