*: stock_landed_costs, purchase_{stock,mrp}, stock_dropshipping, sale_mrp, pos_mrp, repair, mrp_landed_costs, mrp_subcontracting_{dropshipping,landed_costs}, point_of_sale, {project_,}stock_account

Adapts the test skipped to fast merge the valuation refactoring made in https://github.com/odoo/odoo/commit/08b62a4bbcc6f9a391b2cc00a621ef4c76100229.

<img width="482" height="297" alt="table" src="https://github.com/user-attachments/assets/ba57f350-2a9e-4a51-990d-fabe14f5a56a" />

 (*) Includes the one sale_project_stock_account test re-enabled through the TestAnalytics subclass.

It is organised as one commit per module. Two of the re-enabled tests surfaced genuine bugs in the new valuation model; those commits also carry the related fixes: purchase_mrp, project_stock_account Every other commit changes tests-only.

Only one skipped test remains: point_of_sale TestUi.test_05_ticket_screen, a browser tour with no stock-valuation content that was swept into the mass skip by mistake and fails for an unrelated reason (it is left to a separate point-of-sale tour investigation).

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

Forward-Port-Of: odoo/odoo#277339
Forward-Port-Of: odoo/odoo#275246

Steps to reproduce the bug:
- Warehouse configured for 2-Step Manufacturing
- Component "C1":
    - Routes: MTO + Buy
    - Tracking: By Unique Serial Number
    
- Create a Finished product:
    - Route: Manufacture
    - Tracking: By Unique Serial Number
    - BoM:
        - component "C1": 1 unit
- Create and confirm the Manufacturing Order
- Generate/assign the serial number for the finished product immediately, before the related purchase order is even confirmed
- Confirm the Purchase Order
- Receive the component
- Transfer the component to WH/Pre-Production
- Click Produce All

Problem:
A Consumption Warning was displayed stating that the consumed quantity differs from the expected quantity, even though the consumed quantity was exactly equal to the BoM quantity and no manual quantity change was performed. Clicking "Set Quantities & Validate" completed the MO successfully, hiding the inconsistency.

`_get_consumption_issues()` only counts a raw move's quantity as "consumed" when `move.picked` is `True`
[(odoo/addons/mrp/models/mrp_production.py#L1791)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L1791).
Generating the finished product's serial number calls `_set_qty_producing()` 
[(odoo/addons/mrp/models/mrp_production.py#L1402)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L1402).
, which itself only sets `move.picked = True` when `move.quantity` is truthy 
[(odoo/addons/mrp/models/mrp_production.py#L1443)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L1443).

At that point the MTO component had not been received yet, so `move.quantity` was still 0 and `picked` was never set. Once the component was later received and transferred to Pre-Production, `_action_assign()` correctly reserved the raw move (`quantity` became correct), but nothing ever went back to flip `picked` to `True`, since `_set_quantities()` 
[(odoo/addons/mrp/models/mrp_production.py#L2932)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L2932).

only calls `_set_qty_producing()` again when `qty_producing` is still falsy, which was no longer the case. `_get_consumption_issues()` therefore still counted the consumed quantity as 0 against the expected BoM quantity.

Solution:
In `pre_button_mark_done()`, for auto productions (single unit being produced), after `_set_quantities()` runs, also mark as `picked` any non-manual-consumption raw move that is not yet `picked` but whose reserved `quantity` already exactly matches its own `product_uom_qty`. This is scoped to auto productions only, since on a multi-unit production a raw move's aggregate `quantity` can equal its `product_uom_qty` by coincidence (reservation for future backorder steps) even though only part of it is meant to be consumed for the current step.

opw-6421531

Forward-Port-Of: odoo/odoo#281258

When a recurring product (with `allow_one_time_sale = True`) is sold as a one-time purchase (no subscription plan), the stock forecast report and replenishment logic incorrectly treat it as an active subscription. This results in infinite projected future outgoing moves for standard sales.

This occurs because the logic only checks if `recurring_invoice` is True on the product, ignoring whether the parent order actually has a `plan_id`.

This commit fixes the issue by:
1. Updating `_get_stock_subscription_lines` in `sale.order.line` to filter out lines using `_subscription_is_one_time_sale()`.
2. Updating the domains in `stock.forecasted_product_product` to require `order_id.plan_id != False` for subscription forecasts, while correctly routing one-time sales (`order_id.plan_id == False`) back to the standard sale domain.
3. Adapting existing tests to verify that one-time sales do not generate future subscription stock forecasts.

Task-6193648

Forward-Port-Of: odoo/enterprise#116889

When an incoming mail server has the "Keep Original" option enabled, a
copy of every incoming mail is stored as original_email.eml. Because it
is not a document of the invoice, the system unattaches it, however
it may still be used as main attachment in case no other PDF or image
was attached to the message.

Steps to reproduce:
- Configure an incoming mail server with "Keep Original" enabled, using
  an alias pointing to a vendor bill journal.
- Send a mail to that alias containing an xml embedding a PDF.
- Open that bill

Issue:
The invoice's main attachment points to the .eml file.
This occurs because it is set before the PDF is extracted from the xml.
Then, when import extracts the PDF, it is added as attachment on the invoice,
but we already have a main attachment that won't be overwritten.
However, once a pdf or image is added as attachment, the system will show
the (broken) preview.

opw-6431726

Forward-Port-Of: odoo/odoo#285409
Forward-Port-Of: odoo/odoo#280318

Since https://github.com/odoo/enterprise/pull/97488, the images are shared across spreadsheets and the attachments are no longer related to a specific record. Due to the management of the IrAttachment access rights, it means that those attachments are not accessible by anyone by default and we rely on the access_token to display them in the webclient.

However, the method that builds the final xlsx file fetches the images from the server and did not use the access token, meaning that it could never access the attachment. Such situation raised a UserError that was caught by the webclient.

How to reproduce:
- As admin, create a spreadsheet and insert an image inside of it
- try to download the spreadsheet as an xlsx file

counterpart of https://github.com/odoo/enterprise/pull/126384

Task-6432724

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

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

Forward-Port-Of: odoo/odoo#281018

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. In Debug mode, go to Aliases
2. Click on any active Alias, ex. customer-care
3. Click on "Open Parent Document" smart button
4. Click on "Tickets" smart button and observe error

### Description of the issue/feature this PR addresses:
**Issue:** When navigating from an email alias to its parent document (e.g., a Helpdesk Team), the web client incorrectly retains the  `active_id` and `active_model` of the alias in the context.

**Solution:** We updated the `action_view_ticket` method in `helpdesk.team` to explicitly inject the correct `active_model` and `active_id` into  the context before calling `_for_xml_id`. This overwrites the polluted Alias data before the window action is evaluated.

### Current behavior before PR:
Clicking the "Tickets" smart button passes the old alias context into the action. This bad data flows into the ticket view, which attempts to look up a Helpdesk Team using the Alias's ID to generate the empty list help message, resulting in a `MissingError`.

### Desired behavior after PR: 
The Python action sanitizes the context at the source, ensuring that the XML action and subsequent view evaluations receive the correct Helpdesk Team ID. Ultimately, the view will load normally without crashing.

opw-6395638

Forward-Port-Of: odoo/enterprise#129939
Forward-Port-Of: odoo/enterprise#125232

When the quantity of a make-to-order manufacturing order is changed, its finished move is copied to propagate the extra quantity downstream. In some cases (after splitting then merging back productions) that copy is not merged back, so the order ends up with two finished moves for the same product.

On validation, two things then go wrong:
- _post_inventory writes the produced quantity on each finished move,
  so both get the full quantity and the production is doubled
- mrp_account._cal_price prices the finished move and calls
  ensure_one(), which raises "Expected singleton" for an average/fifo
  product, so "Produce All" fails

Split the produced quantity across the finished moves with unit_factor (like _set_qty_producing already does), and price them as a whole instead of expecting a single finished move.

Steps to reproduce:
- Create a BoM for product A with the MTO route, and a component B
- Create a Sale Order for 30 units of A, confirm it
- Split the MO into 3 productions of 10, merge two of them
- On the third, Update Quantity 10 -> 15, then Produce All
- The product should be produced once (15, not 30), with A valued in
  average/fifo it instead of an error.

opw-6242504
opw-6310972
opw-6307025
opw-6354739

Forward-Port-Of: odoo/odoo#282596
Forward-Port-Of: odoo/odoo#269254

Problem:
In Calendar, dragging a slot opens the quick create dialog. Typing a
subject and clicking the expand button in the dialog header creates the
event, but the form that opens is empty, and saving it creates a second
event for the same slot.

Cause:
`FormViewDialog` stores the id of the record it saved in `currentResId`,
which `onExpand` passes as `res_id`. `saveRecord` sets it only in the
branch that runs when no `onRecordSave` prop is given.
`AttendeeCalendarController` passes one since 30478fe855cd
(odoo/odoo#239435), so `currentResId` stays false and the action opens a
new record.

Solution:
Set `currentResId` in the shared branch of `saveRecord`. It is private to
`FormViewDialog`, so a consumer passing `onRecordSave` cannot set it.

Steps to reproduce:
- Open Calendar.
- Drag a slot in the week view to open the quick create dialog.
- Type a meeting subject.
- Click the expand button in the dialog header.
- Observe that the form opens on a new record while the event is created.

Ticket [link](https://www.odoo.com/odoo/project/49/tasks/6476930)

opw-6476930

Forward-Port-Of: odoo/odoo#285899

Currently, an exception is raised when a user attempts to send an
invoice to SUNAT using the `Send to SUNAT` option and the invoice
is not a valid LATAM document code.

Error:
`XMLSyntaxError Start tag expected, '<' not found, line 1, column 1 (<strin...`


This issue originates from the recent refactoring in [1]. When the
LATAM document type is unsupported, or when invoice export fails,
`_l10n_pe_edi_generate_invoice_bstr()` returns an error message instead
of valid XML (see [2]).

The result is subsequently passed to `objectify.fromstring()`(see code ref [3]),
which expects a valid XML payload. As a consequence, XML parsing fails
and an exception is raised.

This commit fixes the issue by updating `_l10n_pe_edi_generate_invoice_bstr()`
to return the generated XML content and any associated errors separately,
instead of returning an error message as the XML payload.

This prevents error messages from being processed as XML and allows
them to be properly surfaced to the user as validation errors, rather
than causing an exception during XML parsing (see [4]).

[1]: https://github.com/odoo/enterprise/commit/ec7160d3d0871794ed592354fff00fd64797e302#diff-832d0127b086c66c0d5800028ee92f007e33f6c1052c6f16a1709f29da1186f9
[2]: https://github.com/odoo/enterprise/blob/5ddef3263d4d9788b894ea465fb183e53d4c9e89/l10n_pe_edi/models/account_move.py#L1092-L1104
[3]: https://github.com/odoo/enterprise/blob/db85dcfcf2afb584bc40d3a4fb94c4838bd355c9/l10n_pe_edi/models/account_move.py#L535
[4]: https://github.com/odoo/enterprise/blob/5ddef3263d4d9788b894ea465fb183e53d4c9e89/l10n_pe_edi/models/account_move_send.py#L80-L84

sentry-7554239976

Users who only have accounting rights (not the Settings > Users Companies > Access Rights group) get an access error on the Companies model when generating the BOE file for the Modelo 115 tax reports, even though exporting a BOE file has nothing to do with editing company configuration and should be available to any accountant.

Steps to reproduce:
-------------------
* Log in as a user with accounting rights only (not part of the Companies > Access Rights group)
* Go to Accounting > Reporting > Tax Return, open the Mod 115 report
* Click the gear icon > BOE > Generate BOE

> Observation:
An AccessError is raised: "You are not allowed to modify 'Companies' (res.company) ... This operation is allowed for the following groups:
Access Rights", even though the user is not trying to edit the company.

Why the fix:
------------
The BOE wizard shared by Mod 111/115/303 declares a `company_partner_id` field, related to `company_id.partner_id`, with `readonly=False`. That field is invisible in every view and only exists to compute the domain of `partner_bank_id`; it was never meant to be edited by the user. Because it is declared writable, the ORM attaches an inverse to the related field, so saving the wizard (which happens when generating the BOE, since the field, though invisible, is still part of the view and thus of the saved values) writes `company.partner_id` back onto `res.company`, even though the value never actually changes. That implicit write requires write access on res.company, which is only granted to the Access Rights group, causing the error for regular accountants. Dropping `readonly=False` keeps the field as a plain readonly related field, still usable for the bank account domain, without ever triggering that spurious write.

opw-6388869

Forward-Port-Of: odoo/enterprise#129924
Forward-Port-Of: odoo/enterprise#126661

Since `company_id` on `worksheet.template` changed due to this a973d7d from a Many2many to a Many2one field.

For example, in v17, a single worksheet template linked to 3 companies via the m2m field was returned as 1 record when opening Design Template. After the upgrade in v18, company_id became m2o, and the same data is split into 3 separate records (one per company).

When trying to add a customization via Studio, the search [fetches](https://github.com/odoo/enterprise/blob/18.0/worksheet/controllers/main.py#L12) records based on the model set on the worksheet. In the new version, Studio
[creates](https://github.com/odoo/enterprise/blob/18.0/worksheet/models/worksheet_template.py#L112)
 a new model, but for existing records the
model is the same across the 3 worksheet records tied to the same template. This causes the search to match all 3 records and raise a SingletonError.

```py
Traceback (most recent call last):
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2856, in __call__
    response = request._serve_db()
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2331, in _serve_db
    raise self._update_served_exception(exc)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2329, in _serve_db
    return service_model.retrying(serve_func, env=self.env)
  File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 188, in retrying
    result = func()
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2384, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2599, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_http.py", line 353, in _dispatch
    result = endpoint(**request.params)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 838, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/src/enterprise/19.0/industry_fsm_report/controllers/main.py", line 9, in edit_view
    action = super().edit_view(view_id, studio_view_arch, operations, model, context)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 838, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/src/enterprise/19.0/worksheet/controllers/main.py", line 17, in edit_view
    worksheet_template_to_change._generate_qweb_report_template()
  File "/home/odoo/src/enterprise/19.0/worksheet/models/worksheet_template.py", line 490, in _generate_qweb_report_template
    new_arch = self._get_qweb_arch(worksheet_template.model_id, report_name, form_view_id)
  File "/home/odoo/src/enterprise/19.0/worksheet/models/worksheet_template.py", line 460, in _get_qweb_arch
    if 'name' in row_node.attrib and row_node.attrib['name'] not in self._get_qweb_arch_omitted_fields() and row_node.attrib['name'] in form_view_fields:
  File "/home/odoo/src/enterprise/19.0/worksheet/models/worksheet_template.py", line 378, in _get_qweb_arch_omitted_fields
    'x_%s_id' % self.res_model.replace('.', '_'), 'x_name',  # redundant
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1657, in __get__
    record.ensure_one()
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5942, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: worksheet.template(3, 14, 18)
```

OPW: 6389190

Forward-Port-Of: odoo/enterprise#127463
Forward-Port-Of: odoo/enterprise#126773

**Problem:**
Since this PR https://github.com/odoo/odoo/pull/261798, both cogs lines have an 
analytic account, which causes the cogs 
to not appear on the project profitability 
report because cogs lines balance each other

**Steps to reproduce:**
- enable 'anglo saxon accounting' and 'analytic accounting'
settings
- create a storable product with automated std 
category, a cost of 10 and on hand quantity
- create a service product and set the 
'create on order' field to 'project'
- confirm a SO for 1 unit of the product and 
1 unit of the service
- validate the delivery and create and confirm invoice
- from the sale order, click on the project smart button
- from the project click on the dashboard smart button

**Current behavior:**
the cogs section don't appear in the profitability report

**Expected behavior:**
it should appear with a line with a value of -10

**Cause of the issue:**
since this PR https://github.com/odoo/odoo/pull/261798, both 
cogs line are linked to the analytic account. 
That's the expected behaviour but in the case of 
the project profitability reports, it prevents the user 
the see the cost of the product in the cogs section.

That's because, inside the 
_get_revenues_items_from_invoices() method, 
bot cogs_line are added to the cogs_line list.
https://github.com/odoo/odoo/blob/141cb292dc5e456161119e19f7a91665feaa0198/addons/sale_project/models/project_project.py#L699-L700

So when computing the amount_to_invoice for 
the costs ml_type, the balance of the lines 
will zero out each other and amount_to_invoice 
will be 0.
https://github.com/odoo/odoo/blob/141cb292dc5e456161119e19f7a91665feaa0198/addons/sale_project/models/project_project.py#L703-L716

As a consequence, the cost of goods sold 
section won't be created
https://github.com/odoo/odoo/blob/141cb292dc5e456161119e19f7a91665feaa0198/addons/sale_project/models/project_project.py#L718-L719

**fix:**
only the line with an account of internal type 
'expense' reflects the actual cost of the product 
sold in the context of the project.
So when computing the profitability report 
that's the only line we should consider

**test:**
test_report_invoice_items_anglo_saxon_automatic_valuation
checks that the cogs section is well displayed in the 
project profitability report.
In the PR (mentionned above) which sets the analytic 
account on the stock cogs line, lines were  
added in the test to manually remove the analytic 
account on the stock cogs line to make the test pass.

With the fix of this PR we can remove those additional 
lines in the test and it will check our use case well again.

opw-6412409

Forward-Port-Of: odoo/odoo#284270
Forward-Port-Of: odoo/odoo#283144