**Issue**:
If the date of some stock moves is anterior to the creation date of the product
in the database, the associated valuation is replaced by the initial standard
price of the product.

**Steps to reproduce**:
- Create a new product with a standard price of 0 and AVCO cost method
- Create a PO for that product with a unit cost of 1,000,000, confirm it and
  validate the receipt
- Go to Accounting > Review > Inventory > Inventory Valuation
  -> Observe that the valuation correctly takes the purchase into account
- Go back to the receipt, unlock it and change the effective date to one week
  in the past
- Go back to Inventory Valuation
  -> Observe that the valuation no longer takes the purchase into account
- Change the valuation date to yesterday
  -> Observe that the valuation takes it into account again

**Cause**:
When a product is created, a `product.value` record is instantiated with
today’s date:
https://github.com/odoo/odoo/blob/bbaf38aa99143be4679cf951c5c0f1a1c8ecf716/addons/stock_account/models/product.py#L174
https://github.com/odoo/odoo/blob/bbaf38aa99143be4679cf951c5c0f1a1c8ecf716/addons/stock_account/models/product.py#L202

In the AVCO computation, a manually set product value (`product.value`) takes
precedence over move values when it is anterior, either here:
https://github.com/odoo/odoo/blob/bbaf38aa99143be4679cf951c5c0f1a1c8ecf716/addons/stock_account/models/product.py#L309-L312
or here:
https://github.com/odoo/odoo/blob/bbaf38aa99143be4679cf951c5c0f1a1c8ecf716/addons/stock_account/models/product.py#L334-L338

Since the stock move date is set one week in the past, the initial product value
(0.0) takes precedence over the move valuation. When the valuation date is moved
forward to yesterday, this initial product value is ignored and the move value
is correctly applied again.

**Solution**:
Setting the initial `product.value` date to the product creation date is
arbitrary, as it makes inventory valuation depend on when the product was
encoded rather than on real stock history. Instead, set the date of the first
`product.value` to the earliest possible epoch, ensuring that any real stock
move always takes precedence in AVCO valuation.

opw-5882080

Forward-Port-Of: odoo/odoo#247407

### Issue:
When deleting a payslip run, the documents from the payslips of the run are not deleted. This results in a traceboack when opening the document app.

### Steps to reproduce:
- Have a payslip run with payslips
- Go to a payslip, validate and generate the document
- Then cancel and reset to draft
- Reset the Payslip Run to draft
- Delete it
- Open the Documents app

### Cause:
The payslips are linked to the run with a `ondelete='cascade'` relation. 

https://github.com/odoo/enterprise/blob/03b2a7dae0e5c5ad3142ec2da8f3de5c9b1957f4/hr_payroll/models/hr_payslip.py#L110-L113

This means that deleting the run also deletes its payslips on a database level, bypassing the ORM. As the document is not directly linked by a relational field but instead by `res_model` and `res_id`, these fields are not updated and therefore are still pointing to a record that is no longer in DB.

### Solution:
Extend the `unlink()` method in `hr.payslip.run` and unlink the documents there.

opw-5501061

Forward-Port-Of: odoo/enterprise#109510
Forward-Port-Of: odoo/enterprise#105969

### Steps to reproduce:
- Download Sales app
- Then, tick Configuration -> Settings -> Promotions, Loyalty & Gift Card
- From the sales app top bar, Products -> Discount and Loyalty -> New
- Rule = Default & Reward = any discount for 100 points
- From the 'Loyalty Cards' smart button, create a new loyalty card for a test customer and set its balance to 100 points
- Create 2 "Quotations" with product below 50$ and claim reward. Don't confirm the quotes
- Select the previous quotes and click "Confirm Orders" smart button
- Verify that the created loyalty card has a balance of -100

### Cause of Issue:
When multiple quotations are confirmed in bulk, the system processes their eligibility for rewards one by one. https://github.com/odoo/odoo/blob/3656171994450d11151565efdb4b9dd0468cefa8/addons/sale_loyalty/models/sale_order.py#L150-L153 Hence, each quote will pass the check because the check since they individually require a number of points less than or equal the current loyalty card balance. Then https://github.com/odoo/odoo/blob/3656171994450d11151565efdb4b9dd0468cefa8/addons/sale_loyalty/models/sale_order.py#L166-L167 The change is caluclated collectively, which lowers the balance to a negative amount.

### Fix:
Since the `change` is calculated before any change is done in the database, it is suitable to raise an error to the user at this point if the change is going to turn the balance negative.

opw-5929187

Issue
-----
When doing delivery -> return -> re-delivery, only one label is received even when there are mutliple packages to be "re-delivered".

Steps to reproduce
-----
- Create a UPS delivery
- Multiple packages
- Validate transfer
- Return
- Validate IN
- Return again
- Add the UPS under the "additional info" tab
- Ensure still multiple packages
- Validate OUT

Cause
-----
When preparing the shipping data, we go through

https://github.com/odoo/enterprise/blob/913e55abc4a9aa58509aa2a60d378fb552de554d/delivery_ups_rest/models/delivery_ups.py#L120-L121

which leads us to do

https://github.com/odoo/odoo/blob/89733b0e4d1e9a57dd25f552db4e6330a6b14cdf/addons/stock_delivery/models/delivery_carrier.py#L142-L155

so we end up with a single package to send to the delivery service. The reason `is_return_picking` is true is because the compute method only checks for an existing move with an `origin_returned_move_id`.

https://github.com/odoo/odoo/blob/89733b0e4d1e9a57dd25f552db4e6330a6b14cdf/addons/stock_delivery/models/stock_picking.py#L53-L58

From a delivery flow perspective, it doesn't make much sense to consider outgoing shipments as returns.

-----
Ticket:
opw-5866100

Forward-Port-Of: odoo/odoo#251789
Forward-Port-Of: odoo/odoo#246946

## Description

There was a desync issue with popup states between normal mode and edit mode. That caused:
- Hidden popups contributed extra dropzones during drag-and-drop
- Hidden popups lost `d-none` class after dropping unrelated snippets

## How to reproduce

### Bug 1: extra dropzones from hidden popup desync
1. Enter website edit mode.
2. Drop popup in the page
3. Drag another snippet as you were adding it to the page
4. An additional dropzone appears below the invisible popup snippet

### Bug 2: hidden popup loses `d-none` class
1. Enter edit mode.
2. Drop a popup.
3. Close it so `.s_popup` gets `d-none`.
4. Drop any other snippet on the page arbitrarily.
5. Popup loses `d-none` class.

## Expected behavior after fix

- Popup hidden/shown state remains stable across editor refreshes and
snippet drops.
- Drag-and-drop no longer creates extra dropzones from hidden popups.

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

Forward-Port-Of: odoo/odoo#251517
Forward-Port-Of: odoo/odoo#250625

[FIX] hr: fix job title search access error

Bug reproduction: Select marc demo -> employee app -> try to search something for job title -> Access error appears for no hr ones
Bug cause: Only users/managers can access to hr_version model and since marc demo has not, it receives this error.
Bug solution: I put store=True and compute_sudo for job_title and by that way everyone can search for job_title without access.

In the task [MOHF] showed another traceback about job title search. I fixed that in this commit as well.

Bug 2 reproduction: employee app -> try to search something for resume -> it will give error (there is no version_ids)
Bug 2 cause: There is no version_ids in the employee.public model, in the search version_ids.job_title is used but job_title can be used directly.
Bug 2 solution: I used job_title in the search instead of using version_ids.job_title.

task - 6000488

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

This commit aligns the Italian e-invoicing (FatturaPA) generation for One Stop Shop (OSS) transactions with the requirements of the Italian Revenue Agency ( Agenzia delle Entrate).

Current behavior:
Invoices for intra-EU B2C sales (OSS) are generated with a single line containing the foreign VAT rate. This is rejected or considered non-compliant by the SDI because foreign VAT cannot be typically exposed in the standard way for Italian electronic invoices.

New behavior:
The XML generation logic has been updated to follow the specific codification required for OSS operations:

1. Invoice Lines (`DettaglioLinee`):
   - The product line is reported with 0% VAT and Nature 'N7' (VAT paid in another EU member state).
   - A new, separate line is injected to represent the VAT amount, classified with Nature 'N2.2' (Non-taxable/Other).

2. Tax Summary (`DatiRiepilogo`):
   - The original foreign tax lines are excluded from the summary.
   - Synthetic summary lines are added for the 'N7' (Taxable Base) and 'N2.2' (VAT Amount) categories.

Implementation details:
- Added `_l10n_it_is_oss_tax` helper to identify OSS taxes.
- Modified `_l10n_it_edi_get_line_values` to split OSS lines.
- Modified `_l10n_it_edi_get_tax_values` to adjust the tax summary.

task-4711509

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#252368
Forward-Port-Of: odoo/odoo#243740

Before this commit, when using the full composer and accidentally closing it with some content, the composer content was recovered on the basic composer and formatting was lost.

This happens because restore of content only works in the basic composer, and basic composer does not support rich HTML like the full composer.

This commit adds a new UX/UI to restore formatting when accidentally leaving the full composer:

When some content has been restored from full composer, opening the chatter composer momentarily disables everything but the full composer button, in addition to show a popover suggesting the user to decide to either continue with Full Composer and restore formatting, or restore content in the small composer without the formatting.

Most of the time people want to restore formatting from the full composer, but at the same time the full composer can be a frustrating experience that may incite to just continue with the more reliable small composer. This new popover support both use-cases.

Task-5910961

<img width="1219" height="175" alt="Screenshot 2026-02-26 at 17 28 06" src="https://github.com/user-attachments/assets/13d8e1ca-4186-445e-8422-a14c31f8570f" />

Forward-Port-Of: odoo/odoo#252318
Forward-Port-Of: odoo/odoo#247245

*:{sale_,}stock, mrp_subcontracting

### Sate of the art:

Since the refactoring of 19.0 removing the procurement groups and introducing stock references  2713876dbc70d3984e584a9037a2206dcda4e84a, the `partner_id` is not propagated in pull flows. While the following fix 3bd213c24536fa6d40a7d7a44d4c553947f82c84 addresses some of these propagation issues, it only propagates the partner in case of a move chain for mto moves generated by mto rule. The current PR addresses some of the mtso use cases such as the mtso multi-step pull delivery and the mtso resupply subcontractor on order.

## 1. mtso multi-step pull delivery

### Steps to reproduce:

- In the settings enable: Multi-Step Routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Put your warehouse in deliveries in 3 steps
- Inventory > Configuration > Warehouse Management > Routes
- Modify you 3 steps Delivery (pick, pack, ship) route:
    - Change the rules to be in pull Stock -> Pack -> Out -> Cust
    - Change the rules: Pack -> Out -> Cust to be in mtso and not mto
- Create and confirm a sale order for a partner A
- The pick, pack and ship should be created
#### > The delivery partner (contact) is only set on the ship

### Cause of the issue:

As the route has been modified to be handled by pull rules, it is generated from end to start by subsequent move confirmations. However, as, the pull rules Pack -> Out -> Cust are in mtso, the associated moves will be created with a `make_to_stock` `procure_method`.
https://github.com/odoo/odoo/blob/5143840911e1f05be3f5f5c7fa786f05e4966312/addons/stock/models/stock_rule.py#L304-L305
Hence, when a procurement is created because of the `mts_else_mto` rule in the `_action_confirm`, the procurement will not set any `move_dest_ids` nor `partner_id`:
https://github.com/odoo/odoo/blob/5143840911e1f05be3f5f5c7fa786f05e4966312/addons/stock/models/stock_move.py#L1549-L1552
https://github.com/odoo/odoo/blob/5143840911e1f05be3f5f5c7fa786f05e4966312/addons/stock/models/stock_move.py#L1688-L1690
https://github.com/odoo/odoo/blob/5143840911e1f05be3f5f5c7fa786f05e4966312/addons/stock/models/stock_move.py#L1699
In other words, the pick and pack moves will not be part of a move chain (with `move_dest_ids`), and the `partner_id` is not propagated.

While the move chain `move_dest_ids` propagation is indeed only intended for mto moves (created by mto rules) since the mtso refactoring: a72382063ee662010729d983fbf6fb6305b8adf2 the `partner_id` should be propagated for pull rule in `mts_else_mto` to avoid losing the delivery partner that used to be propagated by procurement groups which were removed in 19.0 by 2713876dbc70d3984e584a9037a2206dcda4e84a Since the associated fix: 3bd213c24536fa6d40a7d7a44d4c553947f82c84 the `partner_id` can now be propagated via the `procurement_values` but is currently only propagated in case of mto moves:
https://github.com/odoo/odoo/blob/5143840911e1f05be3f5f5c7fa786f05e4966312/addons/stock/models/stock_move.py#L1699

## 2. Resupply subcontractor on order

### Steps to reproduce:

- In the settings enable: Multi-Step Routes, Subcontracting
- Inventory > Configuration > Warehouse Management > Routes
- Set the rule of the "Resupply Subcontractor on order" route to mtso
- Create a subcontracting bom for a finished product (FP) with a storable
  component (comp) for subcontractor: Bob
- Create and confirm a PO for 1 unit of FP with Bob as vendor
#### > Bob is not set as delivery contact on the resupply delivery for comp

### Cause of the issue:

When the rule is in MTO, so is procure method of the move raw for comp in the subcontracted MO. As such, the procurement generated at its confirmation will provide a `move_dest_ids`:
https://github.com/odoo/odoo/blob/c2cb705c078015bff0bc673e83a205d7657918e0/addons/stock/models/stock_move.py#L1688-L1698
which allows to propagate the subcontractor once the procurement is run because of these lines:
https://github.com/odoo/odoo/blob/c2cb705c078015bff0bc673e83a205d7657918e0/addons/stock/models/stock_rule.py#L307
https://github.com/odoo/odoo/blob/37c787ed7ca129bbccd02a073b1e03729b22c2b8/addons/mrp_subcontracting/models/stock_rule.py#L15-L20
In the present case, since the rule is in mtso, the `procure_method` of the raw move will be mts and the `move_dest_ids` will not be propagated. So that `partner_id` is never set as the subcontractor.

### Note about the fix:

When the rule `procure_method` is `mts_else_mto`, at the time we enter override of the `_get_stock_move_values` of `mrp_subcontracting`:
https://github.com/odoo/odoo/blob/37c787ed7ca129bbccd02a073b1e03729b22c2b8/addons/mrp_subcontracting/models/stock_rule.py#L15-L20
the only reference to the subcontractor is the one contained in the `production_ids` of the `reference_ids` of the procurement values which does not look like a reliable link as:
- Multiple `reference_ids` could be set in the values of the procurement
- Multiple `productions_ids` could be linked to the `reference_ids`
- Without the link to the subcontracted move raw nothing indicates that we trigger the creation of a move destined for a subcontractor

By contrast, the current proposition rely on the move that should have been set as `move_dest_ids`in the mto flow and mitigate these uncertainties.

opw-5402407
opw-5883477

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

Forward-Port-Of: odoo/odoo#251564
Forward-Port-Of: odoo/odoo#250307

Steps to reproduce:
---------------------------
1. Install the `project_account_budget` and `account_accountant` modules.
2. Create a new project and add an Analytic Account for it from the settings page
3. Open the Project Kanban, click the three dots on the project card, and select Project's Updates.
4. Click Add Budget button and open the budget wizard.
5. Add a budget line in the wizard with a planned amount expressed as a negative value for an expense (for example: -10000).
6. Create a Vendor Bill using the same analytic account with an amount of 1000.
5. Confirm the bill.
6. Go back to Project's Updates and click New button to view the budget summary.

Observation:
---------------------------
The budget summary displays incorrect signs and percentages in Activities summary, for example:
```
-10.0% (-1,000.00) of the -10,000.00 budget has been spent. 110.0% (-11,000.00) of the budget is remaining.
```
This incorrectly shows -10% spent and 110% remaining instead of 10% spent and 90% remaining (-9,000).

Issue:
---------------------------
The project cost (already negative) was negated again when computing the spent amount in
https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/project_account_budget/models/project_update.py#L16 Double-negating the cost makes it positive, which then gets added to the expense budget instead of reducing it, producing inverted percentages and signs.

Solution:
---------------------------
For expense budgets (negative budgets), do not apply an extra negative sign when calculating the project cost so the spent, remaining, and percentage values are computed correctly.

After the fix:
```
10.0% ($ 1,000.00) of the $ -10,000.00 budget has been spent. 90.0% ($ -9,000.00) of the budget is remaining.
```

opw-5357854

Forward-Port-Of: odoo/enterprise#109638
Forward-Port-Of: odoo/enterprise#102126

Steps to reproduce:
---------------------------
1. Install the `project_account_budget` and `account_accountant` modules.
2. Create a new project and add an Analytic Account for it from the settings page
3. Open the Project Kanban, click the three dots on the project card, and select Project's Updates.
4. Click Add Budget button and open the budget wizard.
5. Add a budget line in the wizard with a planned amount expressed as a negative value for an expense (for example: -10000).
6. Create a Vendor Bill using the same analytic account with an amount of 1000.
5. Confirm the bill.
6. Go back to Project's Updates and click New button to view the budget summary.

Observation:
---------------------------
The budget summary displays incorrect signs and percentages in Activities summary, for example:
```
-10.0% (-1,000.00) of the -10,000.00 budget has been spent. 110.0% (-11,000.00) of the budget is remaining.
```
This incorrectly shows -10% spent and 110% remaining instead of 10% spent and 90% remaining (-9,000).

Issue:
---------------------------
The project cost (already negative) was negated again when computing the spent amount in
https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/project_account_budget/models/project_update.py#L16 Double-negating the cost makes it positive, which then gets added to the expense budget instead of reducing it, producing inverted percentages and signs.

Solution:
---------------------------
For expense budgets (negative budgets), do not apply an extra negative sign when calculating the project cost so the spent, remaining, and percentage values are computed correctly.

After the fix:
```
10.0% ($ 1,000.00) of the $ -10,000.00 budget has been spent. 90.0% ($ -9,000.00) of the budget is remaining.
```

opw-5357854

Forward-Port-Of: odoo/enterprise#109638
Forward-Port-Of: odoo/enterprise#102126

…tion

Currently, under certain conditions, reconciling a batch payment with a bank statement may not be possible as the system tries to create an unbalanced move.

Steps to reproduce:
- Have the main company in USD and EUR as foreign currency
- Have a bank journal with currency EUR (Bank EUR)
- Create an xchange rate for today (1.1)
- Make a Payment (EUR), it should not have an associated move
- Put the payment in a batch
- Update the exchange rate for today (1.2)
- Create a Bank transaction in the journal Bank EUR matching the payment amount
- Open the bank reconciliation screen and reconcile the transaction with the batch

Expected result:
Everything is reconciled.

Actual result:
User gets an error message saying that the account move is not balanced.

Analysis:
The issue occurs because the reconciled payment amount is converted to the company currency using the date provided in the payment.  However the rate was changed in the meanwhile, so it does not match the amount that was used to create the exchange entry values.

opw-5164405

Forward-Port-Of: odoo/enterprise#98495

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

### Steps to reproduce:
- Download Payroll app
- From the top bar 'Employees' > 'Employees', create a new employee
- From the top bar 'Work Entries' > 'Work Entries', add 2 Attendance work entries on different days, with different creation days (either wait 24h between creations, or adjust one create_date in DB)
- Click on any empty cell, you'll find the "Replace by Attendance" smart button replicated

> If you activate debug mode and click on any cell > **UncaughtPromiseError > OwlError**

### Cause of issue:
https://github.com/odoo/enterprise/blob/482b4564b3a81e914d6eead9a7b85a23b7cac3dc/hr_work_entry_enterprise/static/src/work_entries_gantt_model.js#L110-L138 `formattedReadGroup` is called with both `work_entry_type_id` and `create_date:day`. If the user has created several work entries of the same type on different days, we would get multiple group results having the same `work_entry_type_id`. These duplicated records later produce an Owl crash because the button list uses `t-key="workEntry.id"`. 
https://github.com/odoo/odoo/blob/72be98d705e225f663b65e289e11d0b8642ec6f8/addons/hr_work_entry/static/src/views/work_entry_calendar/work_entry_multi_selection_buttons.xml#L16-L17

### Fix:
Since the goal of the above method is to extract the favorite work entries to later use in smart buttons and `userFavoritesWorkEntriesIds.map((r) => r.work_entry_type_id?.[0]).filter(Boolean)` extracts all the entries' `work_entry_type_id` (including duplicates), the easiest way to get rid of these duplicates is to create a `Set`.

opw-5953671

Issue
-----
Orders created through the MPS aren't grouped in a single RFQ.

Steps to reproduce
-----
- Create a product with a vendor
- Add it to the MPS with the buy route
- Change the forecast to 2
- Order
- Change the forecast to 5
- Order
- Go to RFQs

> There are 2 different RFQs

Cause
-----
When doing `_run_buy`, no existing PO is found

https://github.com/odoo/odoo/blob/98e3020bcffaf449291d1e6664ba613761f37331/addons/purchase_stock/models/stock_rule.py#L102

so a new one gets created. The reason why the existing PO is not found is because we add `date_planned_mps` to the search domain

https://github.com/odoo/enterprise/blob/42102423069c2cebbc01eb4d1d8f9b6215358639/mrp_mps/models/stock_rule.py#L10-L15

However, `values['date_planned']` is a datetime.date, whereas `date_planned_mps` is a datetime.datetime in DB.

https://github.com/odoo/enterprise/blob/42102423069c2cebbc01eb4d1d8f9b6215358639/mrp_mps/models/purchase_order.py#L10

This poses some problems with timezones, as the client and db dates might differ. We can avoid the problem by converting the date to datetime.

-----
Ticket:
opw-5171041

# Steps to reproduce:
* Enable **Developer Mode**.
* Go to **Accounting → Configuration → Accounting → Accounting Reports**.
* Create a new report and enable **Composite Report**.
* Add a new line of type **Journal Report**.
* Save the report and create a menu item from the gear icon.
* Open the report from the reporting menu.
* Try to download the report in **PDF** format.

# Observed behavior:
* PDF export fails with a traceback.
* Composite reports containing journal report sections cannot be exported as PDF.

# Cause
When exporting a composite report to PDF, the export flow iterates over each embedded sub-report and generates the HTML body used for PDF rendering.

* The composite export relies on the base [`export_to_pdf`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_report.py#L5875) implementation from `account.report`, which directly calls `_get_pdf_export_html()` for each sub-report.

* For standard reports, this works as expected because they use the base [`_get_pdf_export_html`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_report.py#L5944) method, which renders flat report lines into the default PDF template.

* Journal reports, however, rely on a completely different PDF structure. Their templates expect `document_data` (journal entries grouped by journal/document) instead of flat report lines.

* This `document_data` is generated exclusively by the journal report’s custom handler via its own [`export_to_pdf`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_journal_report.py#L240) flow.

* The handler builds the required `document_data` using [`_generate_document_data_for_export`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_journal_report.py#L261C9-L261C22).

* When a journal report is embedded inside a composite report, the composite export logic bypasses the custom handler and forces the report through the base `_get_pdf_export_html()` pipeline.

* Since the base pipeline does not generate `document_data`, the journal report PDF template fails at render time with `KeyError: 'document_data'`.

In short, journal reports embedded in composite reports were incorrectly routed through the standard PDF export pipeline instead of their specialized handler-based one.



# Fix:
* Add PDF export support to the journal report custom handler.
* Centralize common print option logic in a shared helper.
* Update composite report export logic to delegate PDF generation to custom handlers when available.
* Journal reports inside composite reports now export to PDF correctly.

opw-5477551

Forward-Port-Of: odoo/enterprise#109644
Forward-Port-Of: odoo/enterprise#105040

## Issue
When requesting a signature from the *"User"* role, the relation being used is `res.partner`, instead of `res.users`.

## Steps to reproduce
1. Install *Sign* (`sign`)
2. Upload a PDF
3. Add a Signature block, set the *Filled by* field to *"User"* and validate
4. Click *Sign Now*
5. **The User field displays all the existing `res.partner`s, instead of the `res.users`.**

<img width="558" height="363" alt="5976810" src="https://github.com/user-attachments/assets/3bee36c8-6bdf-4bb1-8adf-7c3fe0092147" />

## Cause
The field appears in `sign_send_request_views.xml`:

https://github.com/odoo/enterprise/blob/9d96ecb2a8049e444823128034d0e57acd61d36a/sign/wizard/sign_send_request_views.xml#L11

and the `signer_x2many` widget is defined here:

https://github.com/odoo/enterprise/blob/9d96ecb2a8049e444823128034d0e57acd61d36a/sign/static/src/fields/signer_x2many.js#L37-L51

where the `partner_id` relation is set to `res.partner` instead of `res.users` (since https://github.com/odoo/enterprise/commit/34f72ad06d5).

opw-5976810

Issue:
---
Due to this issue, generating PDF Quote using Quote Builder leads to traceback.

Steps to reproduce:
---
1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall pypdf2 and install pypdf==5.4.0)
2- Enable Quote Builder.
3- Create a SO and in quite builder tab, select a document.
4- Print -> PDF Quote.

This will lead to traceback.

Cause:
---
There is a requirement change on https://github.com/odoo/odoo/pull/233600, as pypdf2 will not be
supported in future. Instead we use pypdf==5.4.0.

In pypdf 5.4.0 it is required to have `Fields` present in `Acro Form` (introduced in [1] v3.13.0):
https://github.com/py-pdf/pypdf/blame/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/_writer.py#L1060-L1061

FIX:
---
We could add an empty `fields` dictionary when it's not present. The entry should be `/Fields`:
https://github.com/py-pdf/pypdf/blob/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/constants.py#L362-L370

Note:
---
In this fix, we replace `is_upper_version_pypdf2` with specific version comparison.
To be precise `getNumPages` is depreciated in version 1.28.0 [2].

References:
---
[1]- https://github.com/py-pdf/pypdf/commit/dcf997a028e993b215457c5629cb4e78186e11c0
[2]- https://github.com/py-pdf/pypdf/blob/3ab1581a51f446f86dd445662005f8747941c2b6/pypdf/_writer.py#L507-L514

opw-5784464

… request

ARCA requires numeric fields such as unit price and quantity to have a maximum of 12 integer digits and 6 decimal places. If these fields are sent with more than 6 decimals, AFIP rejects the invoice with errors like:
`Code 1814: Campo Cmp.Items.Pro_precio_uni invalido. El valor debe tener 12 enteros y 6 decimales como máximo.`

To ensure compliance, values are formatted before sending the request to ARCA.

**Precision rationale**
ARCA WS documentation mentions 4 decimal places, while the WS error message itself refers to 6 decimals, and in practice the service accepts up to 6 decimals without rejection.

In this implementation, we intentionally use 2 decimal places. The reason is consistency with the rest of the monetary amounts in the invoice: line totals, invoice total, taxes, and related amounts are all rounded to 2 decimals, even in cases where the documentation allows higher precision (e.g., 3 decimals).

Before the changes in rounding precision, the stable version already rounded values according to line rounding. In real-world accounting scenarios, the vast majority of use cases operate with 2 decimal places. Keeping this behavior ensures consistency across calculations and avoids discrepancies caused by mixed rounding strategies.

For a stable release, this was considered the safest and most predictable option, even though the WS technically allows higher precision.

Stable version changes are covered in the following commits:
https://github.com/odoo/odoo/pull/243987/changes/8a21ec45f9d72a7c80d9c1f8398fe01e298ae775
https://github.com/odoo/odoo/pull/246347/changes/79ceeed707ef274f19a04e741f6cb8ac60c44321


<img width="780" height="435" alt="image" src="https://github.com/user-attachments/assets/9f25a0e8-b9d2-4ad2-bbcf-e988c7f8a4c9" />

[WSFEX - Manual de desarrollador](https://www.afip.gob.ar/ws/WSFEX/WSFEX-Manualparaeldesarrollador.pdf)

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

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

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

Instead of first taking all the quantity indicated by the move line, before checking available quantity

opw-5946439

Step to reproduce:
- Install point_of_sale
- Enable Identify Customer on the Card payment method
- Create an order with a customer and refund it
- Use Card as the payment method
- Close the POS session
- Go to Invoicing → Customers → Payments

Observation:
- Two payment records are created
- Both payments have payment_type = inbound
- The refund payment should be outbound

Cause:
- When Identify Customer is enabled, `_create_split_account_payment` is used to create payment records
- The method does not adjust payment_type for refund transactions

Fix:
- Add helpers to swap destination and outstanding accounts
- Set `force_outstanding_account_id` instead of `outstanding_account_id`, as the former has priority
- Ensure refund payments are created as `outbound`

few related fix: https://github.com/odoo/odoo/commit/303a9061da85048f14a3ca7b1e13df0ab34da99e
https://github.com/odoo/odoo/commit/718fac6832ecd343bf26d41fa5ae5b1ab74f4228
https://github.com/odoo/odoo/commit/684415b9ff2e151506da561016dbfa991bfa8dc8

opw-5437456


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

Steps to reproduce:
-------------------------------------
1. Install `hr_appraisal_skills` module
2. Create a new employee and assign at least one skill to the employee
3. Set the Next Appraisal Date to today
4. Go to Scheduled Actions > Appraisal: Run employee appraisal > Run Manually
5. Open the newly created appraisal for the employee

Observation:
-------------------------------------
In the Skills tab, the employee's skills are not populated even though the appraisal is already in the confirmed stage

Issue:
-------------------------------------
When the cron  `_run_employee_appraisal_plans` creates an appraisal, it is created directly in `pending` state via  `create()`. The skill-copying logic only lived in the  `write()` override, which triggers on state transitions from 'new' to 'pending'. Since  `create()` bypasses  `write()`, Employee skills were never copied to cron-created appraisals

https://github.com/odoo/enterprise/blob/451dce92a087086fc3d5d5f610626312f32bcd13/hr_appraisal_skills/models/hr_skills.py#L12-L15

Solution:
-------------------------------------
Add a `create()` override to call `_copy_skills_when_confirmed` when an appraisal is created directly in the `pending` state, ensuring employee skills are properly copied.

opw-5491433