Problem:
The bookings calendar of an appointment type opens on the week of the most
distant booking instead of the next one, even when a booking exists later the
same day.

Cause:
`action_calendar_meetings` sets the landing date from `appointments[0].start`,
where `appointments` is `self.meeting_ids.filtered_domain(domain)`.
`calendar.event` is ordered on `start desc` and a one2many is read in the order
of its comodel, so the first record is the furthest booking rather than the
next one. The original `search([...], order='start')` was replaced by the
one2many in 14b5caccc325 (odoo/enterprise#23191).

Solution:
Sort the filtered bookings on `start` in `action_calendar_meetings`. That
method is the only place the initial date is built, and
`action_calendar_event_view_request` reuses it for the gantt start date, so
both entry points are covered. `calendar.event` keeps its `start desc` order,
which the booking list views rely on.

Steps to reproduce:
- Go to Appointments.
- Open the appointment type "Schedule a Demo" and click Appointments.
- Click New, set the date to later today, save and go back.
- Click New, set the date to one year from now, save and go back.
- Go back to Appointments, reopen "Schedule a Demo" and click Appointments.
- Switch to the calendar view.
- Observe that the calendar opens on the week of the booking one year from now.

Ticket [link](https://www.odoo.com/odoo/project.task/6480029)

opw-6480029

**Steps to reproduce:**
1. Create a product.
2. Add two attributes: multi-checkbox and any single-select type (e.g. Radio).
3. Publish the product and open its page on eCommerce.
4. Verify that no multi-checkbox option is selected by default.
5. Refresh the page twice.

**Issue:**
On the second page refresh, the first option of the multi-checkbox attribute is automatically selected, and the URL is updated with its parameter.

**Cause:**
- `_prepare_product_values` construct attribute combinations by mapping requested `attribute_values` query parameters line by line.
- When URL query parameters were present (e.g., set after the first refresh), the fallback logic `or ptal.product_template_value_ids.filtered('ptav_active')[:1]` treated unselected `multi_checkbox` attribute lines as missing required selections rather than empty selections, forcing them to default to their first active option.

**Fix:**
If no selection is provided for `multi_checkbox` line, return an empty recordset instead of falling back to the first active option.

opw-6494697

According to LSS Art. 36, minimum wage workers are exempt from IMSS deductions. Previously, the system evaluated the period's total gross wage instead of the daily wage, which caused incorrect withholdings when a minimum wage employee received extra pay (like commissions). We now evaluate the `l10n_mx_daily_salary` directly to protect minimum wage workers while ensuring correct deductions for higher earners with unpaid leaves.

Since calculations rely on `schedule_days` retrieved from the schedule table, users commonly adjust these values (e.g., from 15 to 15.2, or 30 to 30.4). To prevent discrepancies caused by this practice, we now round the `schedule_days`.

Finally, this commit fixes the employment subsidy eligibility threshold. Previously, the limit was incorrectly reduced by unpaid absences. This caused a double-counting effect (since absences already lower the actual gross wage) and wrongly disqualified employees. The subsidy limit is now based strictly on the full payroll schedule length, while the ISR minimum wage exemption correctly continues to consider actual worked days.

target: 19.0
task-6370959

### Steps to reproduce:
event = env['event.event'].create({
'name': 'Repro Event',
'date_begin': '2026-09-01 08:00:00',
'date_end': '2026-09-01 18:00:00',
})
ticket = env['event.event.ticket'].create({
'event_id': event.id,
'name': 'VIP',
'seats_limited': True,
'seats_max': 1,
})
env['event.registration'].create({
'event_id': event.id,
'event_ticket_id': ticket.id,
'name': 'Attendee 1',
'state': 'open',
})

ticket.seats_available -> 0
ticket.is_sold_out -> True

result = ticket._get_current_limit_per_order(event=event) print(result) # {ticket.id: 30} -- expected {ticket.id: 0}

### Issue and Expected
`_get_current_limit_per_order()` used `if not seats_available:` to detect the "no limit" case returned by `_get_seats_availability()`. That check is truthy for both `None` (genuinely no limit) and the integer `0` (fully booked), so a sold-out ticket/slot combination was incorrectly treated as unlimited and returned `limit_max_per_order or EVENT_MAX_TICKETS` (e.g. 30) instead of `0`.

### Fix
`_get_seats_availability()` explicitly documents `None` as the "no limit" sentinel, with `0` meaning "constrained, zero seats left". Use `seats_available is None` to preserve that distinction instead of a falsy check.

No functional regression was found in the current website_event flow: sold-out slots/tickets are filtered or re-derived independently before reaching this value in every existing UI path. This fixes the underlying contract of the method itself, so future or additional callers don't inherit the wrong value.

https://github.com/odoo/odoo/issues/284098




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

Steps to reproduce:
===================
1. Add several images to a product, one of them much wider than tall.
2. On the product page, set the image ratio to "Disabled".
3. Move the thumbnails below the image.

=> The wide thumbnail sits at the top of its slot, with blank space
   under it.

Root cause:
===========
Thumbnails are given a fixed width of 64px and take their height from `aspect-ratio: var(--o-wsale-product-image-ratio)` [1]. With cropping disabled that variable is `auto`, so each thumbnail keeps the shape of its own image and they no longer share a height.

They sit in a flex row, which stretches every slot to the height of the tallest one. The image inside keeps its own height and stays at the top of the slot, so a wide image leaves the rest of its slot empty.

The slots are only stretched when the images differ in height, which is why the problem needs cropping to be disabled, and why it does not appear when every image is a landscape one.

- [1] sized the thumbnails from the image ratio.

Fix:
====
Center the thumbnails in the row so each one keeps the height of its own image instead of being stretched to the tallest.

Their width stays at 64px, so a row of wide images still takes the same space as before and none of them is pushed out of the container.

[1]: 670b1daa2254
opw-6472484

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

## HOW TO REPRODUCE:
- Create a product AVCO Perpetual
- Receive 10 units with a unit price of $10 => Product average price is now $10
- Create a Sale Order for 10 units, confirm, deliver and invoice => COGS are at $100
- Receive 1 unit with a price of $5 => Product average price is now $5
- Update SO and add 1 unit, deliver and invoice this new unit => New invoice COGS is $-45

This is because Odoo computes the COGS for the whole SO, and decided that the value of the deliveries is the `quantity * standard_price`, which would means `11 units * $5 = $55`. Because the 1st invoice has a COGS balance of $ 100, the 2nd invoice is set to $ -45.

This behavior is inconsistent with how it was done in previous versions. Furthermore, if we added the +1 unit in a new invoice, the COGS would have been $ 5, for a total products COGS of $ 105.

- - -

With this fix, the COGS are computed using the average of the move value. So if the first move value is $100, and the second is $5, then the global COGS for the sale order should be $105. Because the first invoice COGS are already at $100, the second invoice COGS must be $5.

OPW-6442049

---

## TEST RESULT WITHOUT FIX:
```
2026-08-21 08:00:11,722 28203 INFO oes_test_19.0 odoo.addons.sale_stock.tests.test_anglo_saxon_valuation: Starting TestAngloSaxonValuation.test_cogs_average_multiple_invoices_and_deliveries ... 
2026-08-21 08:00:13,055 28203 INFO oes_test_19.0 odoo.addons.sale_stock.tests.test_anglo_saxon_valuation: ====================================================================== 
2026-08-21 08:00:13,055 28203 ERROR oes_test_19.0 odoo.addons.sale_stock.tests.test_anglo_saxon_valuation: FAIL: TestAngloSaxonValuation.test_cogs_average_multiple_invoices_and_deliveries
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/19.0/odoo/addons/sale_stock/tests/test_anglo_saxon_valuation.py", line 1935, in test_cogs_average_multiple_invoices_and_deliveries
    self.assertRecordValues((cogs_line_1 | cogs_line_2), [
  File "/home/odoo/Odoo/src/19.0/odoo/odoo/tests/common.py", line 727, in assertRecordValues
    self.assertSequenceEqual(expected_reformatted, record_reformatted, seq_type=list)
AssertionError: Lists differ: [{'ac[142 chars]it': 5.0}, {'account_id': 3566, 'debit': 5.0, 'credit': 0.0}] != [{'ac[142 chars]it': 45.0}, {'account_id': 3566, 'debit': 45.0, 'credit': 0.0}]

First differing element 2:
{'account_id': 3536, 'debit': 0.0, 'credit': 5.0}
{'account_id': 3536, 'debit': 0.0, 'credit': 45.0}

  [{'account_id': 3536, 'credit': 100.0, 'debit': 0.0},
   {'account_id': 3566, 'credit': 0.0, 'debit': 100.0},
-  {'account_id': 3536, 'credit': 5.0, 'debit': 0.0},
+  {'account_id': 3536, 'credit': 45.0, 'debit': 0.0},
?                                 +

-  {'account_id': 3566, 'credit': 0.0, 'debit': 5.0}]
+  {'account_id': 3566, 'credit': 0.0, 'debit': 45.0}]
?                                               +

 
```

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

## Issue
When a use rmanually increases the invoiced quantity on a timesheet invoice, subsequent timesheets logged in future periods can no longer be invoiced. The system assumes that the most recent logged hours are already covered by the previously over-invoiced amount, blocking the billing of the most recent timesheet entries.

## Steps to reproduce
1. Install *Sales Timesheet* (`sale_timesheet`)
2. Create a Product P
    - Product Type: Service
    - Invoicing Policy: Based on Timesheets
    - Create on Order: (Project &) Task
3. Create an SO:
    - Customer: Any
    - Product: P (any quantity)
    - Confirm
4. Record hours on the task created:
    - 06/01/2026 (June 1st): 1 hour
    - 07/01/2026 (July 1st): 1 hour
5. Create the invoice for the June timesheet entry (by setting a timesheets period when creating the invoice), then **change the quantity to any value strictly greater than 2** and confirm.
6. Create the invoice for July
7. **An "Invalid Operation" error appears, stating that there's nothing to invoice, even though the timesheet entry from July was never invoiced.**

## Cause
Since https://github.com/odoo/odoo/commit/3b86ac3d180993239b63fd305ee0ba1f17f7eb20, the computation of the quantity to invoice changed to include the difference between the quantity delivered and the quantity already invoiced. In the flow described by the steps to reproduce above, the quantity to invoice is larger than the quantity delivered, making the `qty_to_invoice` equal to `0.0`.

https://github.com/odoo/odoo/blob/626d31fa0191bfe7ca8e1fcf177357eeeb60f2c7/addons/sale_timesheet/models/sale_order.py#L331-L334

The reason for the fix above being the partial refunding of timesheet-related invoices, we can keep that solution when working with refunded invoices, and keep the previous behavior for other cases.

This solution solves the issue in the steps to reproduce above, but was also manually tested on the issues from https://github.com/odoo/odoo/commit/3b86ac3d180993239b63fd305ee0ba1f17f7eb20 and https://github.com/odoo/odoo/commit/64cf4afabd0c5ef040cf87fc6f3125fe0bb81bbb.

opw-6485674

Forward-Port-Of: odoo/odoo#286043
Forward-Port-Of: odoo/odoo#284470

Steps to reproduce:
- Install `l10n_fr_pdp` and `l10n_be` module
- Activate `French e-invoicing` (you need to put your DB in test mode)
  (i.e: `account_peppol.edi.mode = 'test'` in system parameter) Refer this Documentation https://www.odoo.com/documentation/19.0/applications/finance/fiscal_localizations/france.html?highlight=e%20invoicing#localizations-france-e-invoicing-fac-elec-config
- Create a Invoice and Sent with `E-invoicing`
- Run `PEPPOL: retrieve new documents` Cron
- In Invoice Other Info >  `E-Invoicing Status` should be in `Done` state
- Now Vendor Bill is created for that invoice > Cancel that bill with reason >  Check `E-Invoicing Status` response for bill(one response will be without UUID)
- Go to schedule actions > `PEPPOL: update message status`
- Run it and get the traceback: `KeyError: 'false'`

Issue:
When sending a lifecycle response to the French PDP, `_pdp_send_response` calls the `/api/pdp/1/send_response` endpoint and expects IAP to return a `message_uuid` for each response.

However, IAP return a response without a message UUID, for example: ` {'messages': [{'message_uuid': False}]}` `_pdp_send_response` currently assumes that every returned message has a valid UUID and creates an `account.peppol.response` with:
```
    'peppol_message_uuid': False
    'peppol_state': 'processing'
```
This leaves an `account.peppol.response` in `processing` state without a UUID that can be used to track it.

During the next execution of `_cron_peppol_get_message_status`, `_peppol_get_message_status` retrieves this response through `_peppol_get_documents_for_status` and builds `uuid_to_record` using `peppol_message_uuid` as the key. The resulting mapping contains the Python value `False` as a key.

The cron then calls the PDP `1/get_document` endpoint with this invalid UUID. IAP returns it as the string `'false'`, which is passed to `_peppol_process_messages_status`. The French PDP implementation tries to retrieve the corresponding record with: `uuid_to_record[uid]`

Since the mapping contains `False` while `uid` is `'false'`, this raises: `KeyError: 'false'`

This failure prevents the status cron from completing the processing of the messages.

Solution:
Avoid creating the `account.peppol.response` when IAP does not return a `message_uuid`. A response without a UUID cannot be tracked through the PDP status flow, so creating it in `processing` state only leaves an
invalid record that will later cause the status processing to fail.

opw-6453133

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

Forward-Port-Of: odoo/odoo#281691

Steps to reproduce
---
1. Set the warehouse Manufacture route to 2 steps (Pick Components).
2. Create a product to manufacture whose bill of materials has a lot-tracked component, and keep that component in stock.
3. Create and confirm a manufacturing order for it; a Pick Components transfer is generated.
4. Set the produced quantity (`qty_producing`) on the order before validating the Pick Components transfer.
5. Validate the Pick Components transfer, then Produce All.

A consumption warning shows the components as Consumed 0 instead of producing the order.

Issue
---
Entering `qty_producing` before the Pick Components transfer is validated runs `_set_qty_producing` while the components are not reserved yet (they have not reached pre-production), so the
tracked component stock moves stay at a zero quantity and unpicked; validating the transfer afterwards reserves them to the full quantity but never sets `picked`. At `button_mark_done`,
`_set_quantities` only recomputes and picks the component stock moves when `qty_producing` is zero, so with the quantity already set `_set_qty_producing` is skipped and the mark-done
fallback picks only `manual_consumption` stock moves, leaving the auto-consumption component stock moves unpicked.

https://github.com/odoo/odoo/blob/0d44f26d9b0fb1c1a5db463cf1f8dd0d3c72ba26/addons/mrp/models/mrp_production.py#L2933-L2943

Since `_get_consumption_issues` counts consumption from picked stock moves only, it reads 0 consumed and raises the warning even though the components are fully reserved.

https://github.com/odoo/odoo/blob/0d44f26d9b0fb1c1a5db463cf1f8dd0d3c72ba26/addons/mrp/models/mrp_production.py#L1784-L1791

The zero-quantity gate comes from https://github.com/odoo-dev/odoo/commit/ab432cf77311ba852c59ae8675ad4c2dab3bfdf4, which wrapped `_set_qty_producing` in `_set_quantities` to preserve a hand-entered quantity and, as a side effect, stopped picking the
component stock moves in that path. When the quantity is already set, the auto-consumption component stock moves are now marked `picked`: a move reserved above what the run consumes
(`should_consume_qty`) is trimmed down to it so producing part of the order consumes only its share and backorders the rest, while a move reserved at or below it is picked as reserved so
an under-supplied component is consumed at what is available.

opw-6415931

In Italy the periodic VAT return (LIPE) is filed quarterly, so `is_quarter_month` gates the XML export wizard on March, June, September and December. That field only looks at the date, never at the kind of return, so every Italian return locked on a quarter month was treated as a LIPE.

Submitting the withholding tax return therefore opened the LIPE export wizard. Depending on the record the wizard receives, it either crashes while reading the VP lines missing from the withholding report, or silently generates a LIPE file and attaches it to another return.

Add an `is_lipe_return` field telling whether the return actually produces the LIPE.

Steps to reproduce:
- Install `l10n_it_xml_export` and `l10n_it_edi_withholding_reports` on an Italian company with monthly returns
- Open Accounting > Reporting > Tax Return
- Review and submit the withholding returns up to February
- Review then submit the March withholding return --> The LIPE export wizard opens, and the export fails on the withholding report.

opw-6255016

Forward-Port-Of: odoo/enterprise#125263

Steps to reproduce:
- In a PoS session, ring up orders 16, 17, 18, 19, 20 back to back.
- Hold order 17 before finishing it, letting 18, 19 and 20 complete (and so get recorded) first, then confirm order 17 last.
- Cancel order 19 (or otherwise exclude it, e.g. invoice it individually).
- Generate a consolidated invoice covering these orders.

Issue:
A consolidated invoice line grouping several PoS orders is named as a "first-last" receipt range (e.g. "18-20"). Grouping itself relies on `sequence_number`, a gapless counter assigned when the order is recorded in the database - the only field that reliably proves no order was skipped. The receipt reference shown to the customer is reserved earlier, client-side, the instant the ticket is opened, and does not move together with `sequence_number` whenever an order is held (or otherwise finishes) later than orders opened after it. The resulting line can then be named with a range that visually overlaps with, or omits, receipts that are actually reported on a different line, misrepresenting what the consolidated invoice covers.

Root Cause:
`sequence_number` (point_of_sale/models/pos_order.py) is only assigned once an order's row is created in the database, in recording order. The receipt reference (`pos_reference`/`name`) is assigned client-side the moment the ticket is opened (`setNextOrderRefs` in pos_store.js) and is unaffected by how long the order later takes to complete. `_split_pos_orders_in_lines` only checked `sequence_number` continuity to decide which orders share a line, while the line name (built from the first/last receipt reference, sorted) implicitly assumed the two would always move together.

Fix:
- l10n_my_edi_pos: `_split_pos_orders_in_lines` now also requires the receipt reference to be continuous - same device, and the number incrementing by one, via the new `pos.order._get_myinvois_reference_key()`
  - before merging two orders into the same line, on top of the existing `sequence_number` check. An order recorded out of ticket order now gets its own line instead of being merged into one with a misleading name.
- l10n_my_edi: extracted the line-naming logic into an overridable `_get_consolidated_line_name`, which only compresses to a "first-last" range when the names are genuinely sequential, and lists every reference individually otherwise, as a safety net for any other flow relying on this base method.

[task-6166533](https://www.odoo.com/odoo/my-tasks/6166533)

**Steps to reproduce:**
- Create a quotation
- Add order lines until reaching 200 (duplicating helps), save and ensure that the pager appeared (1-200/201)
- Drag one of the lines with the handle to reorder them
- Discard all changes (X shaped button) 

You will have an evaluation error

**Behavior:**
When loading a list of records exceeding the limit, only parts of the records are saved in `_cache`.
When triggering a reordering of said list, all records need to be loaded including the ones on other pages: https://github.com/odoo/odoo/blob/d4eff7b14d37a9b59c95d304542a5a12629bc90b/addons/web/static/src/model/relational_model/static_list.js#L1139-L1149 `_getResIdsToLoad()` gets all Ids missing from the cache, these are then passed through `._createRecordDatapoint` and will then be stored in `_cache`.
The issue is that the Datapoints are getting created with only `activeFields` as data, which in our case are `id` and `sequence`

When discarding the changes `._checkValidity()`is called on each Datapoint: https://github.com/odoo/odoo/blob/d4eff7b14d37a9b59c95d304542a5a12629bc90b/addons/web/static/src/model/relational_model/record.js#L423-L429 And then `._isInvisible()` is called.
This is where the issue happens, since only `sequence` and `id` are stored, when we try evaluate `combo_item_id`, which is the condition to see if sequence is invisible, `combo_item_id` is not found and we get an Evaluation Error.

This commit prevents going into `._checkValidity()` by adding `this.isInEdition` to the check leading to it, requiring that the record is in 'edit' mode which is not the case for records created with `_createRecordDatapoint()`

opw-6399024

**Steps to reproduce:**
- Install l10n_din5008 and Accounting.
- Enable Snailmail from Accounting → Settings.
- Create a German customer (Fiscal Country: Germany).
- Create and post a customer invoice using the DIN5008 report layout.
- Select Send by Post.
- Enable Developer Mode and navigate to Settings → Technical → Email → Snailmail Letters.
- Open the generated letter and send it.

**Observed behavior:**
The address blocks are incorrectly aligned when the DIN5008 report is rendered for snailmail. The information block and recipient address do not follow the expected vertical positioning.

**Cause:**
The DIN5008 layout previously applied vertical alignment rules to its table cells. These rules were removed while adapting the layout to the invoice table structure and its customizations, such as the position column and line numbering.

While this alignment is no longer required for the regular DIN5008 invoice layout, the snailmail layout relies on it to correctly position the sender/invoice information and recipient address blocks.

**Fix:**
Add a `snailmail` class to the DIN5008 invoice section when `snailmail_layout` is present in the rendering context.

Restore the required vertical alignment rules scoped to this class so they only affect snailmail reports, without changing the regular DIN5008 layout.

**References**

* **PR:** [#201225 – DIN5008 layout improvements](https://github.com/odoo/odoo/pull/201225)
* **Ticket:** [6387869](https://www.odoo.com/odoo/project/49/tasks/6387869)

opw-6387869

Forward-Port-Of: odoo/odoo#285891

# How to reproduce
- Set the current employee's schedule to one with :
    - Schedule Type : Flexible
    - Total : a different amount than "Full Time Equivalent"
- Go to My Timesheets
- Add a new line with some Time Spent > 0
- Hover the bottom right cell of the grid (this is the total overtime for the week)

# The issue
The computation of the overtime for the week is based on "Full Time Equivalent" instead of "Total". This is inconsistent with the Planning app and the All Timesheets view.

# Cause
This [PR] introduced the usage of `full_time_required_hours` to compute the total overtime. This field was used because `hours_per_week` ("Total") was thought to be computed using `resource.calendar.attendance`. However, that is not the case when the schedule is flexible : https://github.com/odoo/odoo/blob/46d3fee5812b8406aac2244baa76b0daeef358c2/addons/resource/models/resource_calendar.py#L220 https://github.com/odoo/odoo/blob/46d3fee5812b8406aac2244baa76b0daeef358c2/addons/resource/models/resource_calendar.py#L163-L166

[PR]: https://github.com/odoo/enterprise/pull/81057

opw-6303520