**Issue-1:**

Currently, an error occurs when downloading the Annual Statements 
report as PDF.

**Steps to reproduce:**
- Install the `l10n_be` and `accountant` modules.
- Navigate to Accounting > Reporting > Annual Statements.
- Click the `PDF` button to download the report.

**Error:**
`AttributeError: 'AccountReportLineData' object has no attribute 'get'`

**Root Cause:**
After commit [1], all report lines, columns, and annotations were converted 
from dictionaries to custom objects (e.g., `AccountReportLineData`). However, 
the PDF template still uses `.get()` to access values, which is only valid for 
dictionaries. Calling `.get()` on these objects raises an error.

**Fix:**
This commit ensures that the user can download the report without 
any errors by updating the PDF template to access attributes directly 
instead of using `.get()`, similar to [2].


**Issue-2:**

Currently, an error occurs when exporting audit working files.

**Steps to reproduce:**
- Install the `l10n_be` and `accountant` modules.
- Navigate to Accounting > Review > Audit > Working Files.
- Click `New`, set the date, and click `Generate Return`.
- Go back to `Audit`, click the dropdown menu (⋮) and click `Export`.

**Error:**
`AttributeError: 'AccountReportLineData' object has no attribute 'last_comment'`

**Root Cause:**
After commit [1], report lines were converted from dictionaries to custom 
objects. However, `last_comment` was not added to `AccountReportLineData` 
at [3], while it is still accessed during the export process. This results in 
an error.

**Fix:**
This commit ensures that the user can export the audit working files without 
any errors by adding the missing `last_comment` attribute to 
`AccountReportLineData`

[1]:
https://github.com/odoo-dev/enterprise/commit/b92dc397bef029472a40223f51b611cdf5b631dc#diff-e97f74c63a6257470e69eb8122c12d0ce4afa5bc6013176bb69e702849575123

[2]:
https://github.com/odoo/enterprise/blob/d0dce18797ddc7fa68a882bce19ff1552ceff5b9/account_reports/data/pdf_export_templates.xml#L279-L288

[3]:
https://github.com/odoo/enterprise/blob/72f42a09ccd30ec6200ed8a8155f895febb66501/account_reports/utils/report_data_objects.py#L114-L140

opw-6053889
opw-6063978
opw-6070396

The bank reconciliation view was freezing on large databases (50k+ invoices,
90k+ journal entries), making it impossible to expand lines, filter, or interact
with the view in any way. Attempting to open a line would sometimes result in a
timeout.

**Root cause:** The `reconciledLineName` getter was called multiple times per
render cycle — once in `t-foreach` and again in the `t-if` condition. Since OWL
re-evaluates the template on every reactive state change, this created an O(n×m)
computation loop (n renders × m statement lines) that overwhelmed the browser.

**Fix:** Cache the result in OWL reactive state via a dedicated
`_computeReconciledLineName()` method, called once on setup and reactively via
`useEffect` when `line_ids.records` changes. The template is updated to store
`Object.entries(reconciledLineName)` in a `t-set` variable to avoid rebuilding
the array on every iteration.

| Metric | Before | After |
|---|---|---|
| Longest blocking task | 15 091 ms | 5 118 ms |
| Total blocking time | 74 147 ms | 22 481 ms |
| Avg. click response | 2 163 ms | 28 ms |
| Max click response | 14 305 ms | 222 ms |
| Total microtasks executed | 9 917 | 32 484 |

opw-5879798

Forward-Port-Of: odoo/enterprise#111059
Forward-Port-Of: odoo/enterprise#107135

# Description of the issue/feature this PR addresses

In Point of Sale with ZATCA enabled (l10n_sa_edi_pos), invoicing is enforced on all orders.
In 18.0, settlement and deposit flows were both correctly excluded from mandatory ZATCA invoicing using the is_settling_account flag.

From saas-18.2, the Settle Due flow was refactored to include a dedicated settlement product line. 
As a result, is_settling_account now only covers account deposit flows, and is no longer sufficient to identify Settle Due orders.

# Current behavior before PR

With ZATCA enabled on saas-18.2:

- Account deposit flows are still correctly excluded from mandatory invoicing using is_settling_account.
- Settle Due orders are no longer detected by this flag and are treated as standard sales because they now contain order lines.
- This causes ZATCA invoice enforcement to be applied to Settle Due orders, even though the original invoice was already reported.
- Additionally, mixed orders combining settlement lines and new sale items would require partial ZATCA reporting, which is not supported.

# Desired behavior after PR is merged

After this fix:

- ZATCA invoice enforcement is skipped for account deposit flows using the existing is_settling_account flag.
- Even if invoice is checked, the invoice is not sent to ZATCA
- Settle Due orders are correctly identified using the isSettleDueLine() check on order lines and excluded from mandatory ZATCA invoicing.
- Mixed settlement and sale orders are explicitly blocked for ZATCA to avoid inconsistent or partial reporting.

This restores the intended settlement behavior from 18.0 while adapting it to the refactored Settle Due flow in saas-18.2.

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

Forward-Port-Of: odoo/odoo#254195
Forward-Port-Of: odoo/odoo#244712

### Issue:
When we try to print the field service report on multiple tasks, some with worksheets, then everything is duplicated in the PDF.

### Steps to reproduce:
- Install `industry_fsm` and `sale`
- Create two tasks with the same customer
- Add timesheet, products and save a worksheet on one of them (the goal is to have titles on two different pages)
- In list view select both tasks and click Report > Field Service Report
- The downloaded PDF has the report twice

### Cause:
When printing for several records then `_render_qweb_pdf_prepare_streams()` tries to split the document. If the document has more pages than the number of records [we fetch the "Outlines"](https://github.com/odoo/odoo/blob/55a58571fbfa6a6bb0edacd6f9676382cc23630b/odoo/addons/base/models/ir_actions_report.py#L938-L954). These are the biggest sections in the document. In our case these sections are the `<h2>` tags, as there are no `<h1>`: [the main title](https://github.com/odoo/enterprise/blob/6c4b88a1dfe245a63a424e3f51ff803e51ccde61/industry_fsm/report/worksheet_custom_report_templates.xml#L31-L33), [the Timesheet section title](https://github.com/odoo/enterprise/blob/6c4b88a1dfe245a63a424e3f51ff803e51ccde61/industry_fsm/report/worksheet_custom_report_templates.xml#L39), etc. Then we check the pages where these titles are displayed; if we get the same number of pages as the number of records, we use them to split the report.

If not, then we [render the report for each record individually](https://github.com/odoo/odoo/blob/55a58571fbfa6a6bb0edacd6f9676382cc23630b/odoo/addons/base/models/ir_actions_report.py#L974-L976), add them to `collected_streams`. Then add the initial report generated on the recordset and return.

These streams are later merged into one, which explains the duplication:
- Task 1 report individually generated
- Task 2 report individually generated
- Report of the recordset containing the two first reports

### Solution:
The issue was introduced by [this commit](https://github.com/odoo/odoo/commit/7fc1ebd4466a2d9b4a48dfe86332b5844026c4fc) which implements the individual generation without returning. So the individual documents will always be followed by the recordset document.

This commit adds the return directly after the individual reports generation.

opw-6032935

Forward-Port-Of: odoo/odoo#255581

\* = test_website_modules

### Issue:
When accessing a record from the website without logging in, a `404`
error occurs if a public record rule filters records by website related
domain, for example `[('website_id', '=', website.id)]`.

### Steps to reproduce:
- Install the 'website_blog' module and create at least one website.
- Enable debug mode.
- Go to Settings > Technical > Database Structure > Models.
- Open the `blog.post` model.
- Go to the 'Record Rules' tab.
- For the record 'Blog Post: public: published only', change the domain
  from `[('website_published', '=', True)]` to
  `[('website_id', '=', website.id)]`.
- Go to Website > Configuration > Blogs.
- Open a blog (e.g., Travel).
- Select 'My Website' in its 'Website' field.
- Open 'My Website' without logging in.
- Click on the 'Blog' menu and the blog listing will appear correctly.
- Try opening a blog post and a `404` error occurs.

### Reason:
<pre>
┌─────────────────────────────────────────────────────────┐
│                    Request Lifecycle                    │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  User Request (not logged in)                           │
│       ↓                                                 │
│  ┌──────────────────────────────────────┐               │
│  │ 1. _pre_dispatch                     │               │
│  │    ↓                                 │               │
│  │    check_access_rule                 │               │
│  │    ↓                                 │               │
│  │    _eval_context (compute domain)    │               │
│  │    ↓                                 │               │
│  │    get_request_website()             │               │
│  │    ↓                                 │               │
│  │    request.website = None            │  ← Issue      │
│  │    ↓                                 │               │
│  │    Domain evaluation FAILS           │               │
│  │    ↓                                 │               │
│  │    Access DENIED → 404 Error         │               │
│  └──────────────────────────────────────┘               │
│       ↓                                                 │
│  ┌──────────────────────────────────────┐               │
│  │ 2. _frontend_pre_dispatch            │               │
│  │    (NEVER REACHED)                   │               │
│  │    ↓                                 │               │
│  │    request.website initialized ✓     │  ← Too Late   │
│  └──────────────────────────────────────┘               │
│                                                         │
└─────────────────────────────────────────────────────────┘
</pre>
Because `request.website` is initialized later in
`_frontend_pre_dispatch`, access rules evaluated earlier in
`_pre_dispatch` cannot rely on website context. As a result, record
rules depending on `website_id` are evaluated before `request.website`
is available, incorrectly denying access to public records.

### Fix:
Avoid totally relying on `get_request_website` during access rule
evaluation. Use the `request.is_frontend` attribute as a fallback, which
is set earlier, to detect frontend requests and ensure correct access
handling.

task-[4758311](https://www.odoo.com/odoo/project/974/tasks/4758311)

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

Forward-Port-Of: odoo/odoo#255708
Forward-Port-Of: odoo/odoo#213143

When creating a backorder because of missing product, if there is an extra product received it will create a return also create a return for that product.

### Steps to reproduce:

* Create and confirm a purchase ordre for 2 products (A & B)
* Add a product C to the picking order and reduce the quantity of product B received
* Validate the picking ordre
* Create a backorder
* Go back on the PO and open the linked pickings 
-> There is delivery linked for product C

### Observation:

When processing the backorder, it will sync the delivery and the PO with _action_synch_order where it will add the new product to the PO: https://github.com/odoo/odoo/blob/1a62c4333de61a4e1358ef8e229b2e0f5a3e9826/addons/purchase_stock/models/stock_move.py#L88-L89 
The create that is started by the creation of the new POL will trigger _create_or_update_picking that will create a stock move and a picking: https://github.com/odoo/odoo/blob/2855f0f2b0ffbc340e2af4785dde5bf465579ee8/addons/purchase_stock/models/purchase_order_line.py#L97 https://github.com/odoo/odoo/blob/2855f0f2b0ffbc340e2af4785dde5bf465579ee8/addons/purchase_stock/models/purchase_order_line.py#L197-L198

opw-5868172

Forward-Port-Of: odoo/odoo#255640
Forward-Port-Of: odoo/odoo#248433

Under some conditions, it is currently not possible to render the preview of
some layouts

To reproduce the issue:
(Need `l10n_din5008`)
1. Open Settings more times than the number of companies in the database
   - (We actually need to increase the psql sequence of its table...)
2. Configure your document layout
   - Layout: DIN 5008
3. Click "Preview Document"

Error: an error is displayed: "Missing record: Record does not exist or has
been deleted. (Record: res.company(4,), User: 2)"

When clicking on _Preview Document_, we are actually requesting
`/report/pdf/web.preview_externalreport/4`
Where we have both the report name and the `docids` (equal to `4` in the above
example). Since we are calling it from the `res.config.settings`, we provide
the doc IDs with the ID of the `res.config.settings`. However, the report is
based on the `res.company` model:
https://github.com/odoo/odoo/blob/2f64f909d2f20cc8c0a8e95ba7d17348b9b015e6/addons/base_setup/views/res_config_settings_views.xml#L90
https://github.com/odoo/odoo/blob/e602fc2279e85b66c9983741df5d84fab42a3c44/addons/web/views/report_templates.xml#L1006-L1010
As a consequence, the mechanism will try to render the report using the
company with ID equal to the ID of the config settings, which does not make
sense. This is the reason why, at some point, it can lead to a `Missing
Record` error.

That said, the case is working well on previous versions because we were
defining a global `o` variable before rendering the template, cf for
instance on Odoo 19, L896:
https://github.com/odoo/odoo/blob/1c2e17718e6f2a11d93585f0ea3ba3abee5a4a41/addons/web/views/report_templates.xml#L893-L897
Thanks to that variable, DIN 5008 side, we ignore the `docs`, cf here for
instance:
https://github.com/odoo/odoo/blob/dae4fd0000080ba6395b370e25d3f13f1becd74e/addons/l10n_din5008/report/din5008_report.xml#L96

On Odoo 19.1+, this global variable has been removed by [1]. This commit is
actually the result of a script (cf its description). Since the script
hasn't detected the use of `o`, it moved its declaration inside the previous
`t-call`, L829:
https://github.com/odoo/odoo/blob/e602fc2279e85b66c9983741df5d84fab42a3c44/addons/web/views/report_templates.xml#L827-L830
This was a mistake since the global variable is sometimes used. Long story
short, the script didn't see the dynamic `t-call` inside the template of
`web.external_layout`:
https://github.com/odoo/odoo/blob/e602fc2279e85b66c9983741df5d84fab42a3c44/addons/web/views/report_templates.xml#L758-L761

We have therefore decided to revert this part of the commit and apply the
same logic to its siblings `preview_internalreport` and `preview_layout_report`

[1] https://github.com/odoo/odoo/commit/b7ec60d68c6ee23f7684960e33e5bd6290c9d829

OPW-5951003

Forward-Port-Of: odoo/odoo#254198

Steps to reproduce:
- Enable "Expiration Dates" in Inventory settings
- Create a storable product "P1"
  - Add 10 units with "Lot 1"
- Enable expiration dates on product P1
- Add 10 units with "Lot 2" and set an expiration date
- Create a delivery for 10 units of P1
  - Mark as "To Do"
  - Open the move line

-> "Lot 1" is automatically reserved

- Change the lot from "Lot 1" to "Lot 2" -> The expiration date is not updated automatically

- Save and reopen the move line -> The expiration date is correctly set

- Change again to "Lot 1"
- Save and reopen the move line -> The expiration date is not reset and incorrectly keeps the value from "Lot 2"

Cause:
The expiration date was only computed based on `lot_id`, ignoring the
`quant_id` used during reservation. Additionally, the value was not
reset when switching to a lot without an expiration date.

Solution:
- Add `quant_id` to the compute dependencies
- Compute the expiration date based on `quant_id.lot_id`
- Explicitly set an expiration date to today when the
use_expiration_date product is set to True and the lot doesn't have an
expiration date.

Result:
The expiration date is now correctly updated and cleared when changing lots on stock move lines.

opw-5999294

Forward-Port-Of: odoo/odoo#254610

### Steps to reproduce:

- Create a product that is not track inventory (`is_storable = False`)
- Set its cost to 50$ and put it in an avco perpetual valuation category
- Create and receive a purchase order for 10 units
- Set the product as track inventory (`is_storable = True`)
- Inventory > Reporting > Stock
- Click on the `unit cost` of your product line
#### > This opens the `stock.avco.report` according to which the total value of your stock is 500$ and the total quantity is 10 units even though do not have any unit in stock.

### Expected behavior:

The line of the receipt should have been counter balanced by an inventory adjustment line to resets the valuation at the same time as the product has been set to `is_storable`

### Cause of the issue:

There is currently no mechanism to counter balance the stock that should have been present in internal locations if the moves done had been processed with a storable product.

opw-5472902

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

Forward-Port-Of: odoo/odoo#255557
Forward-Port-Of: odoo/odoo#254380

Currently, if a user selects an exchange difference account as a write-off but then
decides to keep the invoice open, the system still fully reconciles the invoice.

Steps to reproduce:
- Create an invoice in foreign currency
- Click 'Register Payment'
- Select company currency
- Change the amount to a lower one
- Select 'Mark as fully paid'
- Add the exchange difference loss/gain account as write off account
- Select 'Keep open'
- Click 'Create payment'

Issue:
Even though the user selected the option to create a partial payment and keep
the invoice open, it is totally reconciled with a difference booked in the
selected exchange account.

Analysis:
This occurs because the use of the exchange account as write off account
trigger a specific flow used in localization where a writeoff is not allowed.
Once the payment registration process is ongoing, the system does not check
that user kept the same choice on how to handle the payment difference.

opw-5468052

Forward-Port-Of: odoo/odoo#254479
Forward-Port-Of: odoo/odoo#251965

[Issue]
1) When a POS downpayment is created, it doesn't set the account.move.lines.is_downpayment = true. So, no POS invoice line was being marked as a down payment. 2) When preparing to create the invoice lines for the sales order, it never checks the original POS Invoice lines for down payments.

[Fix]
1) When creating the invoice lines for the down payment through the POS, set the 'is_downpayment' based on if the product is the POS's down payment product. 2) Create _prepare_invoice_lin,e then filter through the POS invoice lines for downpayments and then set them accordingly.

Steps to Replicate:
1) User creates a Sales Order for a customer,
2) Transfers it to the POS, and the customer makes a down payment. 3) The user creates an invoice on the Sales order to pay the remainder of the bill 4) The account Id on the account.move.line does not match the original account on the POS invoice for the original account.move.line

Video Demo of the issue:
https://drive.google.com/file/d/1FszCJRUF-cCgg8otxu1jj1kmdKauwTGL/view?usp=drive_link

Video Demo of Solution:
https://drive.google.com/file/d/1yrYBdQZFw7YeKxsgsQQx5gHkuGER-7BN/view?usp=drive_link

Forward-Port-Of: odoo/odoo#249180