#### Description of the issue/feature this PR addresses:
Opening the Asset Depreciation Schedule report with a period comparison enabled crashes with KeyError: 'no_format' when prefix grouping is active (large number of assets in one account group). The report becomes unusable for affected customers.

#### Current behavior before PR:
_regroup_lines_by_name_prefix sums each subline column by indexing prefix_subline['columns'][i]['no_format'] directly. Empty columns are built as {} by _build_column_dict (both col_value and col_data are None), so they have no 'no_format' key. With a comparison period enabled, an asset that has no value in the comparison period produces an empty column for that period; once prefix grouping fires (len(lines) >= prefix_groups_threshold, default 4000), the direct lookup hits that empty dict and raises KeyError: 'no_format'.

#### Desired behavior after PR is merged:
The prefix group total treats a missing 'no_format' as 0, matching the sibling caller in account_asset/models/account_assets_report.py that already guards with .get('no_format', 0). The report builds without crashing and the empty comparison column contributes 0 to the prefix group total.

opw-6225639

Forward-Port-Of: odoo/enterprise#119775
Forward-Port-Of: odoo/enterprise#119088

Since https://github.com/odoo/odoo/commit/17893089e8b21c0ecab5e61ed8e2c33f3731b3ac, in certain cases, customers sending large batches of emails to an accounting email alias would report a small number of emails being bounced (ca. 5%).

Context:

1. While processing an email (after matching mail.alias, with the thread going through `message_process`), if an error is uncaught and raised, the mailgate generates a bounce email, as we presume that the email could not be processed correctly.
2. When sending an email with an attachment to an accounting journal alias, depending on the DB configuration, IAP calls for automatic OCR are triggered asynchronously. These calls trigger callbacks from the IAP server, which might hit the DB in parallel while another thread is processing another email. Given their nature, they trigger updates on the relevant account.move, thus triggering downstream computes in the model.
3. When processing an attachment, the account module triggers `_extend_with_attachments`, which tries decoding the attachment in a rollback context (see:
https://github.com/odoo/odoo/blob/31df5033e31c193b4576ef37dfbc5fc683817bc5/addons/account/models/account_document_import_mixin.py#L343-L344). If a SerializationError happens during that process (concurrent update), it will NOT use the retry mechanism of the ORM because the error is caught in the `except Exception` block. Instead, it will try to post a message to the record to inform the user that the attachment could not be processed.
4. The commit mentioned above changes the way `_update_sequence_made_gap` works. One side effect seems to be that every time `made_sequence_gap` is re-assigned (even if the value does not change per se), the ORM tries to update the `write_date` on the flagged invoice that generated a sequence gap.

Bug:
Given the above context, emails might bounce unnecessarily for a valid email alias and a valid email with an attachment if:

1. The journal is not using a slash-based sequence pattern (e.g., using "1234" for the naming instead of "INV/2026/1234"). In that case, `sequence_prefix` == "".
2. The first invoice does not start at "1".
3. When sending a burst of simultaneous emails in a multi-worker setup, each thread will trigger `message_process` and downstream accounting computes while processing the invoice. It will also trigger IAP calls and callbacks asynchronously when automatic digitization is activated.
4. Each draft invoice that is created is named "/", meaning `sequence_prefix` == "", which in turn re-triggers the checks in `_update_sequence_made_gap`.
5. This increases the chances dramatically of a serialization error while all the parallel processes indirectly trigger an update on the `made_sequence_gap` field of invoice "1234".
6. Most of the time, the serialization error is not triggered in the thread processing the email, which correctly retries it. But in the few unlucky cases where it is raised in the thread processing the email, it will be triggered in the transaction rollback in `_extend_with_attachments`. While handling the exception, it triggers a second error because it tries to post a message to the record that was just rolled back: -> `ERROR: current transaction is aborted, commands ignored until end of transaction block` is raised in the thread running `message_process`, which in turn triggers a bounce email.

Example logs (simplified):

```
2026-06-12 14:12:15 [Worker-Thread-101] INFO mail_thread: Routing email (1)
2026-06-12 14:12:15 [Worker-Thread-102] INFO mail_thread: Routing email (2)

2026-06-12 14:12:16 [Worker-Thread-101] INFO iap_tools: dispatching /parse
2026-06-12 14:12:16 [Worker-Thread-102] INFO iap_tools: dispatching /parse

2026-06-12 14:12:18 [Worker-Thread-101] INFO iap_tools: Webhook received,
triggering /get_result
2026-06-12 14:12:18 [Worker-Thread-102] INFO iap_tools: Webhook received,
triggering /get_result

2026-06-12 14:12:19 [Worker-Thread-101] INFO odoo.sql_db:
UPDATE "account_move" SET "made_sequence_gap" = true WHERE "id" = 1234
-> STATUS: OK (Acquired Row Lock)

2026-06-12 14:12:19 [Worker-Thread-102] ERROR odoo.sql_db: bad query:
UPDATE "account_move" SET "made_sequence_gap" = true WHERE "id" = 1234
ERROR: could not serialize access due to concurrent update
psycopg2.errors.SerializationFailure: could not serialize access

2026-06-12 14:12:19 [Worker-Thread-102] ERROR odoo.sql_db: bad query:
SELECT "mail_message"."id" FROM "mail_message" WHERE ...
ERROR: current transaction is aborted, commands ignored until end of
transaction block
psycopg2.errors.InFailedSqlTransaction: transaction is aborted

2026-06-12 14:12:19 [Worker-Thread-102] INFO "POST /saas_worker/smtp" 200
-> triggers Bounce email

```

Proposed Fix:
A) We update the conditions in `check_around` to ignore draft invoices when they are the "previous" entity being checked. Only posted invoices should be considered when doing the gap checks.
B) We add some guard clauses to prevent unnecessary writes to invoices that created sequence gaps. Instead of assigning values directly, we store the result of the check and only assign `made_sequence_gap` explicitly if the value is different from the currently stored value. This prevents unnecessary writes to the record if the value did not change.

Note:
- We chose this approach instead of touching `_extend_with_attachments` and the rollback context directly. Mostly to prevent any unforseen side-effects, given that this methods are used in accounting for all attachments. But it might be worth analysing if those methods might be improved to handle scenarios as described above in multi-worker setups + email handling.
- fixing the rollbackable context might tricky because the serialization error happens at the first `cr.commit()` inside the context manager
- raising explicitly with `except psycopg2.extensions.TransactionRollbackError:` in `_extend_with_attachments`
retries the whole request to the `message_process`, which might not be a good idea

OPW-6272396


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

Forward-Port-Of: odoo/odoo#270251

**Steps to reproduce:**

- Enable "Track orders edits" in the settings
- Enable "Log in with Employees"
- Go to the Restaurant, log in with employee A
- Go to a table, order 3 Sushis
- Go back to the floor plan and change to employee B
- Go back to the table and change the qty of 3 Sushis to 2 Sushis
- Go to the order in the backend and check the chatter
- It will indicate that employee A did the change, but it was employee B

**Why the fix:**

We always used the cashier set on the order to determine who should be put in the chatter, regardless of who is actually connected at that point.

We now use the session's current employee to write who did the change in the chatter.

We do not change the order's employee, because it will be done once the order has been paid.

In the case where we are not logged in but pos_hr is installed, the employee_id might be the id of a res.user, and
browsing it might return the wrong value. To avoid this, we check if the value exists as a hr.employee before assigning the name.

The way we return the value has been changed because the linter wasn't happy about it.

opw-6213504

Forward-Port-Of: odoo/odoo#265582

There's a few problems with kits and cogs
This PR fixes them and unskips most tests 
of the test class.

**Problems:**
- Problem 1 multiple steps delivery 
  - steps to reproduce: 
    - activate 3 steps delivery 
    - create 2 storable products 'comp A' and 'comp B' 
with category standard perpetual
    - for both : set a cost of 10 and on on hand quantity
    - create a storable kit product with category standard perpetual 
    - create a kit bom for the kit product with 1 comp A and 1 comp B
    - confirm a SO for 1 quantity of the kit prod
    - validate only first delivery
    - confirm invoice 
  - Current behaviour: 
 No cogs line 
  - expected behaviour : 
There should be cogs for 20$
- Problem 2 multiple kits in Bom : 
  - steps to reproduce: 
    - (multiple steps delivery not needed)
    - use same products as for problem 1 but, in the Bom, set
    the number of kit products produced to 2
    - confirm a SO for 2 quantity of the kit prod
    - validate all pickings
    - confirm invoice 
  - Current behaviour: 
 Cogs have a value of 10$
  - expected behaviour : 
There should be cogs for 20$
- Problem 3: fifo comp
  - steps to reproduce: 
    - with 1 step delivery
    - create a storable product 'comp A' with fifo perpetual
    category
    - Confirm a PO and validate receipt for 1 comp A at 10
    - Confirm a PO and validate receipt for 1 comp A at 20
    - create a storable product 'kit' with fifo perpetual categ
    - create a kit bom for the kit product with 1 comp A
    - confirm SO for 2 kit
    - deliver 1 quantity and create backorder
    - confirm invoice for 1 
    - COGS line are created for 10$ (as expected)
    - deliver the backorder
    - confirm invoice for 1
  - Current Behaviour: 
  Cogs are created for 15$
  - Expected Behaviour: 
  Cogs should be created for 20$

**Cause of the issues:**
To compute the price_unit used for the cogs we call 
_get_cogs_value()
https://github.com/odoo/odoo/blob/f8741728294a5147c7d2427d9997738096386262/addons/stock_account/models/account_move.py#L122
What we want is the price unit for 1 unit of the kit product
So we want : 
sum(unit price of each comp * quantity of comp in bom)/ quantity of kit in bom
What is done for now : 
Inside the sale_mrp override, for each component of 
the bom we call _get_price_unit() on its move and 
add the value to 'average_price_unit' and then divide
by the quantity of the kit product in the bom
https://github.com/odoo/odoo/blob/f8741728294a5147c7d2427d9997738096386262/addons/sale_mrp/models/account_move.py#L38-L42
Inside the sale_mrp override of _get_price_unit() 
we return _get_kit_price_unit() called on the move,
https://github.com/odoo/odoo/blob/f8741728294a5147c7d2427d9997738096386262/addons/sale_mrp/models/stock_move.py#L15
Inside _get_kit_price_unit(), the variable 'component_qty_per_kit', 
contains the quantity of each component as recorded in the bom 
times the valued quantity (sale order line quantity).
For each comp :  
    - we store the return value of _get_price_unit 
called on its moves in 'price_unit'.
    - we add to 'total_price_unit': 
    price_unit * component_qty_per_kit/ the kit qty in the bom
we then return total_price_unit / valued quantity
So we actually return:
sum(unit price of each comp * quantity of comp in bom* 
valued quantity)/ (quantity of kit in bom * valued quantity)
which is equal to:
sum(unit price of each comp *quantity of comp in bom)
/ quantity of kit in bom
https://github.com/odoo/odoo/blob/38c737c2a4cc29b48235a100cfa9d6152af73826/addons/mrp_account/models/stock_move.py#L40-L44
Problem 1 is caused by the fact that _get_price_unit()
will return 0 if there's only internal moves because
they have a value of 0.
(The problem does not happen with a single component
cause then the fallback on the super method is correct, but 
with multiple comp the super method also returns 0
because _get_cogs_price_unit returns 0 when more than 
one product).
Problem 2 is caused by the fact that we divide by the 
quantity of the kit in the bom (kit_bom.product_qty) here 
(inside _get_kit_price_unit) and again inside _get_cogs_value
as mentionned before.

Problem 3 happens because there is no mechanism 
to account for already posted cogs inside the sale_mrp 
override of _get_cogs_value(), as qty_invoiced
is computed but never used
https://github.com/odoo/odoo/blob/38c737c2a4cc29b48235a100cfa9d6152af73826/addons/sale_mrp/models/account_move.py#L31

**Fix** 
As regards to the super methods (so non kit scenario),
_get_cogs_value() is used to : 
  -  use original invoice if needed
  - use standard price of the product if no moves
  - deduct already posted cogs 
  - calls get _get_cogs_price_unit() to compute price_unit 
based on the moves

All of this is also wanted for kits and don't need adaptation, 
therefore the override should be on the _get_cogs_price_unit
where we do need a different behaviour when the product is a kit
Doing this we benefit from the 'already posted mechanism' 
from _get_cogs_value which solves problem 3

Additionally, instead of calling get_price_unit we can directly 
call the super method _get_cogs_price_unit as we have 
already computed all the components quantities needed 
for our computation and therefore don't need 
_get_kit_price_unit to recompute all of this.
Also, _get_cogs_price_unit will fall back on the product
standard price if the move has no value which solves 
problem 1.
That will also prevent dividing twice by the quantity 
of kit product in the bom (bom.product_qty) 
which solves problem2.

**Tests:**
Out of the 9 existing tests of the class (that were skipped
before this PR) and after adapation to v19 valuation : 
- 2 succeeded before and after the fix : this PR unskips them
- 5 failed before the fix and now suceed with the fix : this PR 
unskips them 
- 2 failed before the fix and after the fix, they were let 
skipped
In addition, 2 tests were added to cover problem 1 and 3
(problem 2 is covered in test test_sale_mrp_kit_bom_cogs)

Forward-Port-Of: odoo/odoo#270075

This is because webclient knows the current value (c), but not the new
available choices, still with the previous one (a, b).

Actually this works correctly if the field is created within a model
class.

```py
if model_cls._setup_done__ and field._base_fields__:
    # the field has been created by model_classes._setup() as
    # Field(_base_fields__=...); restore it to force its setup
    name = field.name
    base_fields = field._base_fields__

    field.__dict__.clear()
    field.__init__(_base_fields__=base_fields)
    field._toplevel = True
    field.__set_name__(model_cls, name)
    field._setup_done = False

    models_field_depends_done.discard(model_cls)
```

It does not works with studio because there are no parent class
(`_base_fields__`), so the if is not reached.

A solution would be to check if the field is a manually created related
and mark the whole model for setup unlike when `_base_fields__` is
present where we only setup this specific field.

opw-6293768

Forward-Port-Of: odoo/odoo#270349

# Introduction note
This PR fixes two bugs introduced by the same commit :
https://github.com/odoo/enterprise/commit/106d70a1ef0ddbd61a74b7cac82dfce1e316beaa

The original commit fixed multiple issues regarding the display of recurring plans when
the One-time purchase option was enabled, but it also introduced new ones.

Theses new issues are due to multiple new checks on `allow_one_time_sale`, but this
variable only indicates that the One-time purchase option is available to the user, not that
it is actually selected. So the fixes of the original commit works when first loading the page,
but fails when the content of the page is updated.

# Shared steps
- Activate Subscriptions & eCommerce modules
- Create a subscription product, enable 'Accept One-Time' and publish it on the website

# Bug 1
 
## How to reproduce
- Add atleast two recurring plans to the product
- Go to the product page on the website
- Select one of the recurring plans
- Increase the quantity of the product

## The problem
The recurring plan selection is removed

## Cause
The condition `!combination_info.allow_one_time_sale` was added on the `t-att-checked` of the recurring plan selection display. This correctly fixed the issue when first loading the page, but when the user changes the price or the variant, the recurring plan are
recomputed and rerendered :

https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/static/src/interactions/product_page.js#L37-L40

When that is the case, that condition blocks the proper display of the selected recurring plan.

## Proposed Solution
When loading the recurring plan selection, what defines wich plan is selected is the
`subscription_default_pricing_plan_id` variable, which is based on the
`plan_id` value given in the request to the server :
https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/models/product_template.py#L222

We make it so if no `plan_id` is sent to the server and `allow_one_time_sale` is
enabled, then the server does not give back any `subscription_default_pricing_plan_id`

opw-6131532

# Bug 2

## How to reproduce
- Add an attribute with values A & B for the product
- Define atleast two recurring plans for the variant with attribute B
- Publish the product
- Go to the product page
- Select the variant with attribute B

## The problem
The recurring plan is not displayed. If the order of the attribute is reversed, then it works as expected.

## Cause
The pricings are correcly sent to the front-end but they are not added to selection because
of the check on  `allow_one_time_sale` :
https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/static/src/interactions/product_page.js#L42-L50

opw-6132160

Forward-Port-Of: odoo/enterprise#115446

**Issue**
Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request.

**Steps to reproduce**
- Have two companies A and B and two users u1 and u2
- user u2 only have access to company A
- With user u1:
	- Create two vendors v1 and v2 without any company assigned
	- Create vendor pricelists for a product for each vendor and assign the company A to the pricelist
- Add the company B for the vendor v2
- With user u2:
	- Open approval application
	- Try to create an approval for an RFQ for that product (the vendor v1 will be automatically selected)
	- Save it -> An access error is thrown

**Cause**
Saving the approval request computes `has_no_seller`, which calls `_select_seller`: https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/views/approval_product_line_views.xml#L9 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L32 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L62-L70 Which filtered the right seller
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L759 By preparing the sellers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L721 https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L712 Please note that `self.seller_ids` contains both sellers (even v2) By filtering the suppliers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_supplierinfo.py#L104-L105 But at that point, one of the supplier in `self`, can be accessed, thus an access error is thrown while trying to access its associated `partner_id`.

opw-6203910

Forward-Port-Of: odoo/odoo#269552

**Issue**
Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request.

**Steps to reproduce**
- Have two companies A and B and two users u1 and u2
- user u2 only have access to company A
- With user u1:
	- Create two vendors v1 and v2 without any company assigned
	- Create vendor pricelists for a product for each vendor and assign the company A to the pricelist
- Add the company B for the vendor v2
- With user u2:
	- Open approval application
	- Try to create an approval for an RFQ for that product (the vendor v1 will be automatically selected)
	- Save it -> An access error is thrown

**Cause**
Saving the approval request computes `has_no_seller`, which calls `_select_seller`: https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/views/approval_product_line_views.xml#L9 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L32 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L62-L70 
Which filtered the right seller
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L759 
By preparing the sellers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L721 https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L712 
Please note that `self.seller_ids` contains both sellers (even v2) By filtering the suppliers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_supplierinfo.py#L104-L105 
But at that point, one of the supplier in `self`, can be accessed, thus an access error is thrown while trying to access its associated `partner_id`.

opw-6203910

Forward-Port-Of: odoo/enterprise#120251

The website appointment calendar fills availabilities one month at a time and the update_available_slots route maps the calendar month index to an absolute month from datetime.now(). This only matches the displayed months when the first one is the current month. When the first bookable slot is later, a punctual appointment starting in a future month or any appointment whose "at least X hours before start time" lead time pushes the first slot past the current month, navigating forward requests the wrong month and the reached month renders empty.

In update_available_slots, take the lead time into account when computing the reference month so it lands on the first displayed month: the start datetime for a punctual appointment starting in the future, otherwise now plus the minimum schedule hours. The navigated month index is then added to that reference. This extends https://github.com/odoo/enterprise/commit/f0e5b14a823cf97218f4094d287a328e2744fd73 which only handled the future start datetime.

Steps to reproduce:
1. Open the Appointments app
2. Open an appointment type, set Schedule to Weekly and Allow Bookings to On specific dates with a range ending a few months out
3. Set the "at least N hours before start time" field to 360
4. Save and click the Preview button in the header
5. Pick a resource or staff member to reach the calendar
6. Click the right arrow to navigate to the next month

=> the next month shows "Sorry, we have no more slots available for this month"

opw-6206293

Forward-Port-Of: odoo/enterprise#120715