### Issue:
When a kit BoM has `product_qty` > 1 (e.g. 12 Kit X = 12 Comp A + 12 Comp B), the SO line cost after confirmation is multiplied by the batch size. Selling 1 Kit X shows a cost of 360 instead of 30.

### Cause:
The method `_compute_average_price` uses `bom.explode(self, 1)`, which returns raw BoM line quantities for one full batch. It accumulates the total batch cost but returns it without dividing by `bom.product_qty`.

### Steps to Reproduce:
- Costing Method = AVCO, Inventory Valuation = Automated
- Comp A (cost 10), Comp B (cost 20), Kit X (cost 0)
- Kit BoM: 12 Kit X = 12 x Comp A + 12 x Comp B
- Create and confirm a SO for 1 x Kit X
- Expected SO line cost: 30
- Actual SO line cost: 360

Solution:
This fix mirrors the normalization already done in `_compute_bom_price`, which correctly divides by `bom.product_qty` and converts UoMs.

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

Forward-Port-Of: odoo/odoo#259005
Forward-Port-Of: odoo/odoo#253406

Issue:
---
In `tax included` companies, the down payment section is not correctly calculated.

Steps to reproduce:
- Configure selected company's field account_price_include to be "tax_included"
- Create a sales order
- Create 1 or more down payment invoices for the SO and confirm
- Create a final invoice that pays for the rest of it
- On this final invoice where the down payment(s) are also listed, click on the preview button

Current behavior:
- The down payment section's total is the sum of the subtotal

Expected behavior:
- The down payment section's total should be the sum of the totals

Justification:
---
The amounts included in the invoice report are dependent on the
`company_price_include` field in `res.partner`. If tax_excluded,
subtotals are listed. If `tax_included`, totals are listed.
There was a mismatch between the entries and the section total;
the section entries could have the total as the amount while
the section's sum would be in terms of subtotals.

Fix:
---
On stable we can still rely on `section_subtotal` but set its
amount to total instead of subtotal in case of `tax_included`.

However, this fix is not stable as there is a xpath on `t-set`
expression in `l10n_ar`.
To avoid breaking the views, we can re-set the `section_subtotal`
in the next lines.
This would still cause issues as it will replace the overridden
logic in the `l10n_ar` implementation.
To prevent that issue, we can re-set the `section_subtotal` only
if the value is the same as `get_section_subtotal`, which means
we are in the main implementation and it's safe to re-set the value.

opw-6127615

Forward-Port-Of: odoo/odoo#261372

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

**problem:**
On timesheets, the overtime indication next to an employee's name is incorrect when using flexible work schedules. for example: a "Flexible 20h" schedule (4h a day) shows 1h of negative overtime even when the employee has logged exactly 20h for the week.

**steps to reproduce:**
1. Create a new working schedule with flexible hours enabled for example (20h/week, 4h/day average)
2. Assign this schedule to an employee
3. Go to Timesheets, search for the employee
4. Navigate to a past week
5. Enter 4h on each working day
6. Observe the overtime indication shows incorrect value (-01:00)

**cause:**
In `resource/models/resource_calendar.py`, the flexible hours algorithm that determines the date range by converts UTC boundaries to the employee's timezone. When the employee's timezone has a positive UTC offset (UTC+1, like in brussels time zone), `Sun 23:59:59 UTC` becomes `Mon 00:59:59 CET`, pushing `end_date` to the next Monday. This creates an 8 day range instead of 7. The algorithm then starts a new weekly budget for the spillover day and allocates 1 extra hour, making `allocated_hours` 20.9999998 instead of 20.

**fix:**
- Use the UTC date before conversion to the employee's timezone when determining the flexible date range.
- prefer `self` when it is the flexible calendar being queried, so hr_contract's `_get_calendar_at()` override cannot substitute the contract's calendar parameters (full_time_required_hours, hours_per_day) for the flexible ones.

**note**
Updating the test (`test_no_carried_over_leaves_for_flexible_resource`) in `hr_holidays/tests/test_expiring_leaves.py` expected duration logic, is to match the corrected inclusive day range and prevent asserting the previous spillover behavior.
link to the enterprise PR: https://github.com/odoo/enterprise/pull/112879

link to the community PR: https://github.com/odoo/odoo/pull/257269

opw-5970511

---

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

Forward-Port-Of: odoo/enterprise#115693
Forward-Port-Of: odoo/enterprise#112879

**Steps-to-Reproduce**
- In v19, install subscriptions.
- create new subscription + service product with allow one time sale enabled.
- make a SO with that product,any reccuring plan and any end date. 
```
id |  name  | subscription_state | next_invoice_date |  end_date  
----+--------+--------------------+-------------------+------------
  1 | S00001 | 1_draft            |                   | 2026-05-02
```

- confirm the SO
```
 id |  name  | subscription_state | next_invoice_date |  end_date  
----+--------+--------------------+-------------------+------------
  1 | S00001 | 3_progress         | 2026-05-01        | 2026-05-02
```
- remove its recurring plan (some product sold for months for testing then converted to one time sale )
```
 id |  name  | subscription_state | next_invoice_date |  end_date  
----+--------+--------------------+-------------------+------------
  1 | S00001 | 3_progress         |                   | 2026-05-02
```

- upgrade to v19.1 will fail or opening sales > To Invoice > Orders To Invoice gives this error or add amount_to_invoice in list view using studio to produce in v19 :
```
File "/home/odoo/odoo18/enterprise/sale_subscription/models/sale_order_line.py",
 line 175, in _compute_amount_to_invoice
    and (not order.end_date or order.next_invoice_date < order.end_date)
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<' not supported between instances of 'bool' and 'datetime.date'
```

- upgrade failing for v19.1 because amount_to_invoice added to list view [here](https://github.com/odoo/odoo/commit/427232efd121410380b62acf4fd2e9ee369e6542#diff-48cb4309a6006f91b2b40e4c1049860218d419fce1782c7dcc278329803129caR193-R213).

upg - [4220658](https://upgrade.odoo.com/odoo/upgrade.request/4220658)
opw - [6128033](https://www.odoo.com/odoo/project/70/tasks/6128033)

Forward-Port-Of: odoo/enterprise#115976

**Steps to Reproduce:**
1. Install `hr_contract_salary_payroll` with demo data.
2. Open Employee (e.g; Abigail Peterson) > Payroll tab > Gear Icon > Edit Properties.
3. Add a new property for Payroll and fill in the value also.
4. Go to Payroll > Configuration > Benefits.
5. Create a new benefit with:
   Salary Structure Type: Worker
   Cost Field: Payroll Properties (Employee Contract)
6. Save the record.

Video: https://drive.google.com/file/d/1gHRkDW5G0bURlo9_IRgCnvqpE-8Fk1xa/view?usp=drive_link

**Error:**
`TypeError - unsupported operand type(s) for +: 'int' and 'Property'`

**Cause:**
The method `_get_benefits_costs()` directly sums values using: 
```
self[benefit.cost_field]
```
When the selected cost field is a property field, it returns a **fields_properties.Property** object instead of a numeric value, and this object is not directly compatible with the arithmetic sum operation.

Before 19.0, property fields were not allowed to be selected as a cost field - [1].

**Fix:**
This commit prevents selecting property fields as cost fields from the list of supported field types.

[1] : https://github.com/odoo/enterprise/blob/04224abcc7eec1c81df7ad57a9213fd091774888/hr_contract_salary/models/hr_version.py#L183

sentry-7388663038

Forward-Port-Of: odoo/enterprise#113238

### Issue:
When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction

Additionally, after selecting and unselecting a line with another currency, the balance can remain hidden even when no lines are selected

### Cause:
In `changeInSelectedMoveLine(selectedLines),` when the currency differs from the company currency, `selectedLineCurrencies` is built as a simple mapped array

This array may contain duplicate currencies, which should not prevent computing the balance but incorrectly impacts the logic that determines whether to display it
There is no reason to block the sum of lines with the same currency

When there is no selectedLines, the function returns early and doesn't unhide the balance

### Steps to reproduce:
- Install `account_accountant` with demo data
- Enable a foreign currency like EUR
- Create and confirm 2 invoices (Customer: Acme Corporation, Currency: EUR, Add a line for 100€)
- Go to the Dashboard, and select Bank
- Create a new transaction (Label: Multi-currencies, Partner: Acme Corporation, Price: 500$)
- Switch to the List View, and display the 2 columns `Foreign Currency` and `Amount in Currency`
- Modify the line Multi-currencies (Foreign Currency: EUR, Amount in Currency: 300$)
- Switch to the Kanban View and Reconcile the line Multi-currencies
- Select your 2 invoices one by one
Before the fix, after selecting the second invoice, the balance is displayed as `/`

For the additional case:
- Unselect all lines
- Select a line in another currency (e.g., USD), then unselect it
The balance remains hidden

opw-6063366

Forward-Port-Of: odoo/enterprise#115101

Step to reproduce:
- install "purchase_stock" and "point_of_sale"
- Create a product attribute -> Display Type: Radio Button
-> Variant Creation Mode: Never create variants
-> Add two attribute values, ensuring that one includes a 'is_custom' field.
- Create a product and assign this attribute to it.
- Enable the MTO (Make To Order) route.
- Add a vendor to the product.
- Create and confirm a POS order for this product. (add text for custom attr)
- Observe that a Purchase Order is generated automatically.

Observation:
- the PO does not have that text in description

Cause:
- After commit [1], `description_picking` became a computed field.
- Previously, its value (`product_description_variants`) was set in `_prepare_procurement_values`.
- That key is no longer used for this purpose, so the information is not propagated and the data is lost.

https://github.com/odoo/odoo/blob/71b1267e54fd53fb283c41b579756c72e393cbfa/addons/stock/models/stock_rule.py#L341-L343

above code is removed following that commit

Fix:
- The description is computed for pos orders

[1] https://github.com/odoo/odoo/commit/6b2d3af64a076654e04494972acc4c42d7c54bd8

opw-5969378


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

Forward-Port-Of: odoo/odoo#262503
Forward-Port-Of: odoo/odoo#253231

Steps to reproduce:
-------------------------------------
1. Install `hr_holidays_attendance` module
2. Time off > configurations > Time off types
3. Create new time off type as follows:
* Set Approval to Approved by time off officer
* Change Take time off In to Hours
4. Save the record and enable Deduct Extra Hours
5. Go to Management > Allocations
6. Create new allocation with created time off type and select 'Audrey Peterson' in Employee
7. Try to save record > Validation Error > Discard changes
8. Change time off type to Paid Time Off > add 'Audrey Peterson' > save record
9. Now change Time Off type to Created Time Off type > Save

Observation:
-------------------------------------
No Validation Error raised, as the employee and time off type are still the same as they were during creating allocation.

Issue:
-------------------------------------
In `write` method, there was no any check for the employee if it has enough overtime hours when we change Time off type (`holiday_status_id`) to overtime-deductible leave type.

Check was only present in the `create` method:
https://github.com/odoo/odoo/blob/a95c639db68f98351c7162de58a041a1c0ee13c5/addons/hr_holidays_attendance/models/hr_leave_allocation.py#L39-L49

Solution:
-------------------------------------
1. Create new function for validate overtime and to create adjustment
2. Added that function to `create` as well as in `write` method
3. Prevents creating a duplicate overtime adjustment for an allocation that already has one

opw-5937185

Forward-Port-Of: odoo/odoo#262716
Forward-Port-Of: odoo/odoo#249793

## Issue
When creating an invoice for a sale order with a recurring plan using a `billing_period_value` >= 1 and aligning, that value is not taken into account, and the invoice only covers one unit of time (week/month/year).

## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a Recurring Plan RP:
    - *Billing Period*: 6 Months
    - *Align to Period Start*: Checked
3. Create a Subscription Product P
4. Create a Subscription SO:
    - Any Customer
    - Recurring Plan RP
    - Product P (any quantity/price)
5. Confirm the SO and create the invoice
6. **In the line of the SO, only one month is covered by the invoice. If we generate the next invoice, only one month will be covered as well.**

## Cause
Since https://github.com/odoo/enterprise/commit/45f28f6c288f5213a4e29c816ec68d2c3966b55f, the `next_date_1st` is evaluated by taking the last day of the month/year and incrementing it by one day, to reach the first day of the next month/year.

https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/sale_subscription/models/sale_order_line.py#L377-L382

This is inaccurate when working with recurring plan which are not monthly/yearly, as it will always set the `next_date_1st` to the next month/year, without taking in account the `billing_period_value`.

## Fix
There are two ways to align dates to the period start. Given a subscription starting on January 15, with a billing period of 3 months, we could:
1. Invoice from January 15 to January 31, then from February 1 to April 30. This aligns the invoice to the closest month, then apply the 3 months period for the next invoices.
2. Invoice from January 15 to March 31, then from April 1 to June 30. This applies most of the billing period for the first invoice, while still aligning it to the start of the month, then apply the 3 months period normally for the next invoices.

**Here, we chose the second option** to avoid making the code more complex and keep the diff minimal.

opw-6151530

Forward-Port-Of: odoo/enterprise#115830

**Issue**
Lots manually indicated on stock move lines can be overridden when producing a Manufacturing Order.

**Steps to reproduce**
- Create a storable product P tracked by lot
- Create two lots for product P with 2 units each
- Create a MO for a product consuming two units P and confirm it
- On the raw move, manually set 1 unit for each lot
- Click on "Produce All"
- Check the move line associated to the product P -> 2 units associated to the first lot consumed instead of 1 unit each

**Cause**
While producing:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2109-L2110 It sets the quantities:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2246 This calls `_set_quantity_done_prepare_vals` with a qty of 2: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2264 which will, for each move line:
- Take the quantity indicated by move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2274 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2296-L2297
- Then take all the available quantity left for the lot associated to the move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2302-L2309 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2326-L2327 Instead of first taking all the quantity indicated by the move line, before checking available quantity

**Solution**
Assume that raw move lines being created in mrp without changing the producing quantity are manually created

opw-5946439

Forward-Port-Of: odoo/odoo#260518
Forward-Port-Of: odoo/odoo#257258

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

### Steps to reproduce:
	- Create a salary rule for expenses
	- Set a debit account for this rule with a type other than 'Payable'
	- Create an expense for an employee and report it for the next payslip
	- Create a payslip for this employee
	- Notice an error is shown that 'No debit account for Expenses rules'
	- Go to the expense rules and change the debit account type to 'Payable'
	- Go back to the payslip and notice the error didn't disappear and a new warning showed up

### Cause:
When changing the type of an account_debit that is linked to an expense
rule we will try to recompute the errors and issues but the env company
will be set to be equal to the default company of the env user. So if this
company is different than the payslips' company it won't be able to fetch
the correct account_debit in the rule

### Fix:
Access account_debit and journal_id using with_company() to make sure we get the correct company-related value.

opw-6013423

Forward-Port-Of: odoo/enterprise#114878

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#262136
Forward-Port-Of: odoo/odoo#245964

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

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