## Dependent PR
https://github.com/odoo/enterprise/pull/98463

## Description of the issue/feature this PR addresses:
Users are blocked when trying to use the **Settle Due** feature in Point of Sale if the ZATCA (l10n_sa_edi_pos) integration is enabled.

## Current behavior before PR:
When a PoS order is created using a "Pay Later" payment method, an invoice is correctly generated and sent to ZATCA.

However, when the user later tries to settle that customer's due balance (using the **Settle Due** option), the l10n_sa_edi_pos module incorrectly forces the Invoice option to be enabled and makes the field read-only. This blocks the user because:

- Settlement orders do not contain any lines, so a new invoice cannot be generated.
- The original invoice was already sent to ZATCA, and the settlement payment should not be sent as a new e-invoice.

Thus, the user cannot proceed with the settlement.

## Desired behavior after PR is merged:
After this fix, the **Invoice** checkbox will no longer be forced or marked as read-only during **Settle Due** operations. The field will default to False, aligning with standard Odoo behavior for settlements and allowing the user to complete the payment.

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#244654
Forward-Port-Of: odoo/odoo#233769

## Description of the issue/feature this PR addresses:
The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation.

## Current behavior before PR:
When a user initiates a **Settle Due** payment for a customer, Odoo creates a new order and sets the `is_settling_account` flag to True. If the user proceeds to the payment screen but then navigates back (to the product screen) instead of completing the payment, the flag remains True.

This is problematic because the user can then add regular products to this same order and check out. The order is processed as a normal sale, but it is incorrectly flagged as a settlement, which can lead to error on codes depending on this.

## Desired behavior after PR is merged:
After this fix, if a user leaves the payment screen during a **Settle Due** operation, the `is_settling_account` flag on the order will be correctly reset to False. 

task-id - 5144679

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

Forward-Port-Of: odoo/enterprise#104866
Forward-Port-Of: odoo/enterprise#98463

Issue
-----
Commit 76196c4c5f2ff01354931df6ad615f1b2c4d9a22 introduced logic to select the rate based on the requested currency. This causes problems when the requested currency does not match the one set up on the Fedex account, because the 'actualRateType' gets set to payor instead of preferred for the rate's 'rateType', which means

`d['rateType'] == rating_result['actualRateType']`

is false, so `actual` is empty, leading to an error when doing `actual['totalNetCharge']`.

Solution
-----
In the request we send, we hardcode

`'rateRequestType': ['PREFERRED']`

so we can look for a match using 'PREFERRED' as a prefix of `rateType`.

The Fedex API lists all possible values of the enum `rateType`

https://developer.fedex.com/api/en-us/catalog/ship/v1/docs.html

<details>
<summary>Enum values as per the API</summary>

"enum": [
	"INCENTIVE",
	"NEGOTIATED",
	"PAYOR_ACCOUNT_PACKAGE",
	"PAYOR_ACCOUNT_SHIPMENT",
	"PAYOR_CUSTOM_PACKAGE",
	"PAYOR_CUSTOM_SHIPMENT",
	"PAYOR_LIST_PACKAGE",
	"PAYOR_LIST_SHIPMENT",
	"PAYOR_RETAIL_PACKAGE",
	"PAYOR_RETAIL_SHIPMENT",
	"PREFERRED_ACCOUNT_PACKAGE",
	"PREFERRED_ACCOUNT_SHIPMENT",
	"PREFERRED_CUSTOM_PACKAGE",
	"PREFERRED_CUSTOM_SHIPMENT",
	"PREFERRED_INCENTIVE",
	"PREFERRED_LIST_PACKAGE",
	"PREFERRED_LIST_SHIPMENT",
	"PREFERRED_NEGOTIATED",
	"PREFERRED_RETAIL_PACKAGE",
	"PREFERRED_RETAIL_SHIPMENT",
	"RATED_ACCOUNT_PACKAGE",
	"RATED_ACCOUNT_SHIPMENT",
	"RATED_CUSTOM_PACKAGE",
	"RATED_CUSTOM_SHIPMENT",
	"RATED_LIST_PACKAGE",
	"RATED_LIST_SHIPMENT",
	"RATED_RETAIL_PACKAGE",
	"RATED_RETAIL_SHIPMENT",
	"UNKNOWN"
],

</details>

There are only 3 possible prefixes: `PAYOR`, `PREFERRED` & `RATED`, so replacing the other 2 by `PREFERRED` should be safe.

-----
Ticket:
opw-5482949

Forward-Port-Of: odoo/enterprise#105156

Behavior before:
Exporting the TPAR report could fail with an error indicating that the GST amount exceeded the
gross paid for certain vendors. Some payment lines were excluded from the SQL query,
leading to discrepancies in the report.

Behavior after:
The SQL query has been updated to include all relevant payment lines, including those in
asset_cash accounts. This ensures that the gross paid is calculated correctly, allowing the
TPAR report to be exported without errors.

Root Cause:
The previous query only considered asset_current and liability_current accounts, ignoring
asset_cash accounts. This omission caused the gross paid amount to be understated relative to
the total GST paid.

Steps to Reproduce:

1. Create a vendor bill.

2. Navigate to the Bank Reconciliation page (Accounting → Dashboard → Bank Journal).

3. Create a bank statement line for the bill amount.

4. Validate the statement line with the corresponding invoice line.

5. Generate the TPAR report — the payment amount should now be correctly included.

OPW: 5148697

Forward-Port-Of: odoo/enterprise#102700
Forward-Port-Of: odoo/enterprise#99874

Issue
-----
Commit 76196c4c5f2ff01354931df6ad615f1b2c4d9a22 introduced logic to select the rate based on the requested currency. This causes problems when the requested currency does not match the one set up on the Fedex account, because the 'actualRateType' gets set to payor instead of preferred for the rate's 'rateType', which means

`d['rateType'] == rating_result['actualRateType']`

is false, so `actual` is empty, leading to an error when doing `actual['totalNetCharge']`.

Solution
-----
In the request we send, we hardcode

`'rateRequestType': ['PREFERRED']`

so we can look for a match using 'PREFERRED' as a prefix of `rateType`.

The Fedex API lists all possible values of the enum `rateType`

https://developer.fedex.com/api/en-us/catalog/ship/v1/docs.html

<details>
<summary>Enum values as per the API</summary>

"enum": [
	"INCENTIVE",
	"NEGOTIATED",
	"PAYOR_ACCOUNT_PACKAGE",
	"PAYOR_ACCOUNT_SHIPMENT",
	"PAYOR_CUSTOM_PACKAGE",
	"PAYOR_CUSTOM_SHIPMENT",
	"PAYOR_LIST_PACKAGE",
	"PAYOR_LIST_SHIPMENT",
	"PAYOR_RETAIL_PACKAGE",
	"PAYOR_RETAIL_SHIPMENT",
	"PREFERRED_ACCOUNT_PACKAGE",
	"PREFERRED_ACCOUNT_SHIPMENT",
	"PREFERRED_CUSTOM_PACKAGE",
	"PREFERRED_CUSTOM_SHIPMENT",
	"PREFERRED_INCENTIVE",
	"PREFERRED_LIST_PACKAGE",
	"PREFERRED_LIST_SHIPMENT",
	"PREFERRED_NEGOTIATED",
	"PREFERRED_RETAIL_PACKAGE",
	"PREFERRED_RETAIL_SHIPMENT",
	"RATED_ACCOUNT_PACKAGE",
	"RATED_ACCOUNT_SHIPMENT",
	"RATED_CUSTOM_PACKAGE",
	"RATED_CUSTOM_SHIPMENT",
	"RATED_LIST_PACKAGE",
	"RATED_LIST_SHIPMENT",
	"RATED_RETAIL_PACKAGE",
	"RATED_RETAIL_SHIPMENT",
	"UNKNOWN"
],

</details>

There are only 3 possible prefixes: `PAYOR`, `PREFERRED` & `RATED`, so replacing the other 2 by `PREFERRED` should be safe.

-----
Ticket:
opw-5482949

Forward-Port-Of: odoo/enterprise#105156

Versions
--------
- 18.0+

Steps
-----
1. Have a way to check the `specific_property_product_pricelist` field;
2. create a pricelist for EU countries;
3. delete all other regional pricelists;
4. create a new partner in a EU country;
5. create a new partner outside a EU country;
6. create a new partner without a country.

Issue
-----
Inconsistent behavior:
- EU partner has no `specific_property_product_pricelist` value set, as it's identical to the default `property_product_pricelist`.
- The other partners do have a `specific_property_product_pricelist` value set to the default value, as if a user manually assigned them.

Cause
-----
In the `_inverse_product_pricelist` method, the `default_for_country` pricelist is an empty recordset if the partner has no `country_id` or none of the pricelists have a country groups with the partner's `country_id` in it.

Solution
--------
Introduce a `_get_country_pricelist_multi` method that can be used by `_get_partner_pricelist_multi` and `_inverse_product_pricelist` to ensure that they both return the same result for any given country (including none), and use this as the `default_for_country`.

> [!Note]
> An alternative approach could be to replace the `_inverse_product_pricelist` method with an `onchange` method, as the docstring of the `_get_partner_pricelist_multi` method states:
>> First, the pricelist of the specific property (res_id set), this one is created when saving a pricelist on the partner form view.
>
> This suggests a behavior that more closely resembles the purpose of an `onchange` method, instead of an `inverse`.

opw-5385213

Enterprise PR: https://github.com/odoo/enterprise/pull/103116 (only modifies a test)

Forward-Port-Of: odoo/odoo#245530
Forward-Port-Of: odoo/odoo#241736

Issue
-----
Commit 76196c4c5f2ff01354931df6ad615f1b2c4d9a22 introduced logic to select the rate based on the requested currency. This causes problems when the requested currency does not match the one set up on the Fedex account, because the 'actualRateType' gets set to payor instead of preferred for the rate's 'rateType', which means

`d['rateType'] == rating_result['actualRateType']`

is false, so `actual` is empty, leading to an error when doing `actual['totalNetCharge']`.

Solution
-----
In the request we send, we hardcode

`'rateRequestType': ['PREFERRED']`

so we can look for a match using 'PREFERRED' as a prefix of `rateType`.

The Fedex API lists all possible values of the enum `rateType`

https://developer.fedex.com/api/en-us/catalog/ship/v1/docs.html

<details>
<summary>Enum values as per the API</summary>

"enum": [
	"INCENTIVE",
	"NEGOTIATED",
	"PAYOR_ACCOUNT_PACKAGE",
	"PAYOR_ACCOUNT_SHIPMENT",
	"PAYOR_CUSTOM_PACKAGE",
	"PAYOR_CUSTOM_SHIPMENT",
	"PAYOR_LIST_PACKAGE",
	"PAYOR_LIST_SHIPMENT",
	"PAYOR_RETAIL_PACKAGE",
	"PAYOR_RETAIL_SHIPMENT",
	"PREFERRED_ACCOUNT_PACKAGE",
	"PREFERRED_ACCOUNT_SHIPMENT",
	"PREFERRED_CUSTOM_PACKAGE",
	"PREFERRED_CUSTOM_SHIPMENT",
	"PREFERRED_INCENTIVE",
	"PREFERRED_LIST_PACKAGE",
	"PREFERRED_LIST_SHIPMENT",
	"PREFERRED_NEGOTIATED",
	"PREFERRED_RETAIL_PACKAGE",
	"PREFERRED_RETAIL_SHIPMENT",
	"RATED_ACCOUNT_PACKAGE",
	"RATED_ACCOUNT_SHIPMENT",
	"RATED_CUSTOM_PACKAGE",
	"RATED_CUSTOM_SHIPMENT",
	"RATED_LIST_PACKAGE",
	"RATED_LIST_SHIPMENT",
	"RATED_RETAIL_PACKAGE",
	"RATED_RETAIL_SHIPMENT",
	"UNKNOWN"
],

</details>

There are only 3 possible prefixes: `PAYOR`, `PREFERRED` & `RATED`, so replacing the other 2 by `PREFERRED` should be safe.

-----
Ticket:
opw-5482949

Forward-Port-Of: odoo/enterprise#105156

When printing many receipts quickly using a USB printer, this error was occasinally occuring:

```
WARNING ? odoo.addons.iot_drivers.iot_handlers.drivers.printer_driver_base: Failed to query ESC/POS status
ERROR   ? root: Could not set configuration: [Errno 16] Resource busy
```

This would cause `python-escpos` to be disabled and fallback to just CUPS printing.

The issue was caused by two threads trying to access the printer at the same time, which could happen in two ways:
- IoT thread with `python-escpos` and CUPS try to access the printer at the same time.
- Two IoT threads with `python-escpos` try to access the printer at the same time (this can happen if two receipt actions are received at the same time).

Both of these scenarios should now prevented:
- Now, if we are using `python-escpos`, we also use it to print the receipt as well as checking the status. CUPS is never used so there should be no interference from it.
- We now have an `escpos_lock` (per printer, not global) that is acquired when accessing the printer via `python-escpos`. This ensures that different threads cannot both try to access the printer at the same time.

task-5490942

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

Forward-Port-Of: odoo/odoo#245122
Forward-Port-Of: odoo/odoo#244031

**Steps to reproduce:**
- Create a storable product "P1"
  - Product category: AVCO

- Create a purchase order with 100 units of P1 at $10
- Confirm the PO and validate the receipt
- Go to Inventory -> Reporting -> Stock

- P1 unit cost is $10 and total value is $1000

- Click on $1000
  - Select the first stock move
  - Action -> Adjust valuation
    - New value: $2000 -> Save

- Go back to Inventory -> Reporting -> Stock

**Problem:**
- The unit cost becomes $2,000 and the total value $200,000

When a valuation adjustment is made on an AVCO product, a `product.value`
record is created with the new total valuation value.

However, `product.value.value` can represent two different things:
- for a standard price update, `value` contains the new unit cost
- for a stock move valuation, `value` contains the total value of the move

When `run_avco` processes a `product.value` coming from a move valuation,
it incorrectly treats the value as a unit price and multiplies it by
the quantity

opw-5460829

Forward-Port-Of: odoo/odoo#244957

Currently, an error occurs when uploading `encrypted or incomplete` 
PDF files (missing EOF marker) while creating a quotation document 
header or footer.

**Steps to reproduce:**
- Install the `sale_pdf_quote_builder` module.
- Navigate to: Sales > Configuration > Headers/Footers.
- Upload encrypted file [1], or incomplete file [2].

**Error:**
`PyPDF2.errors.DependencyError: PyCryptodome is required for AES algorithm`
`PyPDF2.errors.PdfReadError: EOF marker not found`

**Root cause:**
At [3], `_get_form_fields_from_pdf` and `_ensure_document_not_encrypted` directly 
call `pdf.PdfFileReader`, when it fails to read or decrypt the file, Python raises 
an error.

**Fix:**
This commit prevents errors when users upload unreadable or encrypted PDF files.

[1]:
https://drive.google.com/file/d/1moSlwXHkqcV6_7zHBNhLMLi-9Ye_xDGJ/view?usp=sharing

[2]:
https://drive.google.com/file/d/16O4LLH8dL0RWmbOx4HrcooFUyesWaVi-/view?usp=sharing

[3]:
https://github.com/odoo/odoo/blob/694f1d0fb03b56dd41a59eb676e56622634cc91b/addons/sale_pdf_quote_builder/utils.py#L11

sentry-6928220164
opw-5227601

Forward-Port-Of: odoo/odoo#245264
Forward-Port-Of: odoo/odoo#230712

**Steps to reproduce:**
- Create a portal user
- Go to the documents app
- Click on the marketing folder
- Share the marketing folder through a link (Anyone with a link = viewer + discoverable)
- Copy the share link
- Login with the portal user in an incognito window
- Paste the share link in an incognito browser
- Click on "brand 1" folder, result nothing is showing while there should be a folder and a picture
- Click on "brand 2"
- Click back on "brand 1" and now the folder and picture are visible
- If you click on a subfolder of "brand 1" you also get an error

**Issue:**
Discoverable subfolders accessed using `accessToken` are not available on
the first read of a user and this happens for each level of the
hierarchy (refresh is needed each time).

When using sharing link to display folders with a user,
the subfolder document access is created on `/documents/touch/` using
`_from_access_token`.

But on the js side the call is delayed (with debounce) and occurs after
the `web_search_read`. This means that subfolders are only accessible
after a refresh or by switching back and forth between folders.
Also, even after the folder is displayed, if there are other subfolders
in it, going deeper in the hierarchy won't work as well without a refresh
due to the `search_panel_select_range` missing the new folder.

**Fix:**
Not sure on the best way to fix this, the issue will always be related to
performance. Current fix checks if a reload is needed by sending a flag in the
`/documents/touch/<access_token>` request result when a new document
access was created.

opw-5156297

Forward-Port-Of: odoo/enterprise#104845
Forward-Port-Of: odoo/enterprise#99820

### Issue:
Due to this issue, by clicking twice on `Reward` button on SO, reward line unit price will be reset to zero.

#### To reproduce:
1- Create a `Buy X Get Y` program:
   rule: minimum quantity: 3, product: `Large Desk Wood`
   reward: 1 `Large Desk Wood` for free
2- Create a SO, and add a line with 3 `Large Desk Wood`
3- Click on `Reward` button. A new line should be automatically
   created. The unit price should be the product sale price and
   line `Amount` should be 0.
4- Re-click on reward. The reward line price unit is set to zero.

Expected: The reward line price unit should remain as product sale price with a discount of 100 and line.amount of 0.

### Cause and Fix:
In `_reset_loyalty`, price_unit is set to zero.
The method `compute_amount` depends on `price_unit`, which means setting `price_unit` will make amount to be recomputed: https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/sale/models/sale_order_line.py#L843-L844 https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/sale/models/sale_order_line.py#L848 https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/account/models/account_tax.py#L1613

Which leads to `_compute_price_unit`. In this compute, the unit price will not be recomputed if `technical_price_unit` and `price_unit` differ.
https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/sale/models/sale_order_line.py#L606-L611 https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/sale/models/sale_order_line.py#L588-L595

So IMO if we want to recompute `price_unit`, we need to also reset `technical_price_unit` in `_reset_loyalty`.

opw-5467623

Forward-Port-Of: odoo/odoo#244290

This PR fixes the bug of not making the source location persistent when changing it from the form view.

To reproduce the bug:
1- Create a product tracked by lot.
2- Create 3 different lot locations with each having a quantity of 100. 
3- Create an out delivery of 140 and notice 100 are assigned from the first lot and 40 are assigned from the second lot.
4- Set the scanning source location to be mandatory in Barcode for deliveries.
5- Go to Barcode app, navigate to the delivery, you find it mandatory to scan a source location.
6- Scan the source location for the first lot location, choose the product and click on the edit pen icon.
7- Choose another lot location as your source location, let it be the third lot location and confirm.
8- Choose to assign the qty by clicking on the +100 button.
= See that the new chosen source location is not persistent.

The fix:
After this PR, if you follow the steps up to step 7 and after you confirm your new source location, the Barcode makes the lines inactive again and asks you to scan the source location (since it's mandatory) and it also shows the new source location on the line.

Another fix this commit addresses is that when you scan a source location, only the lines with this location are active to choose/edit not all the lines.

Task-4809491

Forward-Port-Of: odoo/enterprise#97777

### [FIX] mail: properly handle col overflow in bootstrap row
Problem:
The grid conversion logic only finalized a row when iterating through the
last column in the input list. If a row reached exactly 12 grid spans
while more columns remained (e.g., a `col-12` in the middle), the logic
did not start a new row. As a result, remaining columns overflowed the
current row visually.

Cause:
In a single row, if a column had a size 12 and was followed by another column of
any size, it would crash because the algorithm did not reset the index to the
start of the next row.

Steps to reproduce:
- Add a Marketing block.
- Reduce the size of the left card from the left side.<img width="719" height="580" alt="image" src="https://github.com/user-attachments/assets/1e62eaf7-6ab1-4120-b643-62427ce3ec3a" />
- Save.
- Traceback.

### [FIX] mail: ensure -md variant of col and offsets are prioritized
Prior to this commit, if an element had a mix of `col-x` and `col-md-y` classes,
the regexes used in `convert_inline` would not guarantee that they would be used
consistently.

How to reproduce:
- create a new mailing and add the "three columns" snippet
- resize from the right the middle column (reduce the size and revert back to
  the original size)

Issue:
- when sending the email, the columns are not aligned horizontally in a desktop
  layout

Solution:
Prioritize usage of `-md` variants to compute the size of a column/offset, when
available (these are the one used by the mass_mailing editor for desktop mode),
and use any otherwise.

opw-5439481

Co-authored-by: Damien Abeloos <abd@odoo.com>
Co-authored-by: Thomas Josse <thjo@odoo.com>
Co-authored-by: Walid Sahli <wasa@odoo.com>

Forward-Port-Of: odoo/odoo#241851

Since https://github.com/odoo/odoo/pull/227477, using falsy ids ids illegal

This commit adds an additional filter to the domain used to browse `ir.model.data` to compute the following fields: `(menus|views|reports)_by_module` in order to avoid selecting any that would contain a falsy `res_id` and thus cause the above-mentioned assertion to fail.

One way to reproduce this in a new trial:
- Create a new trial with several modules: `account`, `crm`, `project`, `sales`
- Install `web_studio`
- Uninstall `base_automation`
- Traceback
```
  File “/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py”, line 5200, in browse
    assert all(ids) or all(isinstance(x, NewId) or x for x in ids), “Invalid falsy real id”
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Invalid falsy real id
```

This is due to an `ir.model.data` containing a falsy res_id in the internal code of `saas_trial` (`installed-17`)

This fix will avoid any additional traceback like this one.

opw-5865316

Forward-Port-Of: odoo/odoo#245469

### Issue:
The stripe payments are failing to due setting currency decimals.

#### Steps to reproduce:
1- In USD currency form in developer mode, set the rounding factor
   to `0.001000`, so we have 3 decimal places.
2- From `Decimal Accuracy` set Price Unit to 4 digits.
3- Refresh the page.
4- Create a SO and add a line. Set the price to `200.7647`.
5- Refresh the page again and generate a payment link.
6- Pay through stripe. As you see payments fail.

### Cause:
This is due to rounding the amount before sending to stripe:
https://github.com/odoo/odoo/blob/824e0c42c62de7f570f106860e7dcbf1f7344c14/addons/payment_stripe/models/payment_transaction.py#L160-L165

We are rounding the amount to the minor currency unit.

However, we make a compare between `tx_amount` and the amount paid through stripe:
https://github.com/odoo/odoo/blob/824e0c42c62de7f570f106860e7dcbf1f7344c14/addons/payment/models/payment_transaction.py#L726-L732

Which are not equal. We should use minor current unit as `precision_digits` to fix this issue.

opw-5496825

Forward-Port-Of: odoo/odoo#245593
Forward-Port-Of: odoo/odoo#245059

Steps to Reproduce
 1. Create a database in Odoo 19.0 with the stock_account module installed.
 2. Enable Dropshipping from Inventory → Settings.
 3. Create a product with a category whose Cost Method is set to Average Cost (AVCO).
 4. Create a user with Inventory / User access rights only (no Inventory Administrator rights).
 5. Create a dropship order using the product and validate the picking.

```
You are not allowed to access 'Product Value' (product.value) records.

This operation is allowed for the following groups:
	- Inventory/Administrator

Contact your administrator to request access if necessary.
```

Issue:-
During picking validation, moves are getting [done](https://github.com/odoo/odoo/blame/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock/models/stock_picking.py#L1265) if move is is_dropship enable which lead to [update_standard_price](
https://github.com/odoo/odoo/blob/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock_account/models/stock_move.py#L169)  if product cost_method is [avco.](https://github.com/odoo/odoo/blob/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock_account/models/product.py#L462-L476) So, it call run_avco during that getting [the _get_manual_value](
https://github.com/odoo/odoo/blob/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock_account/models/stock_move.py#L409) it through access error

Fix:-
To fix this sudo is added during getting _run_avco

opw-5431121
upg-3762999



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

Forward-Port-Of: odoo/odoo#242841

[FIX] test_l10n_be_hr_payroll_account: fix the test of 13th month full leave

Bug production: It is a runbot error occurred in test_13th_month_full_leave (version: master);
    1 - Install and update l10n_be_hr_payroll,l10n_be_hr_payroll_account,test_l10n_be_hr_payroll_account,hr_holidays,resource modules in localhost
    2 - Execute the test test_13th_month_full_leave and it will fail, also in the same class (Test13thMonth) many other tests were failing.

Bug cause:
    1 - In test test_13th_month_full_leave, for all year the sick day timeoff is allocated. (year: 2025), generate work entries for 2025 and expecting payslip amount must be 0 but it is not.
    2 - When I looked to _get_paid_amount -> _get_paid_amount_13th_month -> _compute_presence_prorated_fixed_wage: Some days in the year was not counted as sick day and since few days are not counted, the payslip amount is > 0.
    3 - By diving deeper: in function _get_calendar_days: date_to = min(date_max, leave.date_to.date()), from this line, I observed that leave.date_to is calculated 1 days before sometimes.
    4 - In hr.leave model -> _compute_date_from_to -> hour_from, hour_to = holiday._get_hour_from_to(holiday.request_date_from, holiday.request_date_to) -> In here hour_from and hour_to is (0,0) when the calendar (id = 1) standard 40h/week is used.
    5 - Since it returns (0,0) and converted to UTC in the next line, the date_to becomes 1 day before the expected date_to.
    6 - After finding that, the standard 40h/week calendar returns (0,0) for work start hour and work end hour, I looked to 'resource.calendar' model.
    7 - In function _get_default_attendance_ids, hour_from and hour_to returns 0,0 for typical 40 hours/week calendar which is not true.
    8 - This standard calendar with id = 1 is used in other 4 tests in class Test13thMonth and they were failing as well, now all of them are fixed.

Bug solution:
    1 - Fixing the hour_from and hour_to of standard 40h/week calendar from (0,0) -> (8, 16).

task - 5853076
Runbot Error

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

Bug production: It is a runbot error occurred in test_13th_month_full_leave (version: master);
1 - Install and update l10n_be_hr_payroll,l10n_be_hr_payroll_account,test_l10n_be_hr_payroll_account,hr_holidays,resource modules in localhost 2 - Execute the test test_13th_month_full_leave and it will fail, also in the same class (Test13thMonth) many other tests were failing.

Bug cause:
1 - In test test_13th_month_full_leave, for all year the sick day timeoff is allocated. (year: 2025), generate work entries for 2025 and expecting payslip amount must be 0 but it is not. 
2 - When I looked to _get_paid_amount -> _get_paid_amount_13th_month -> _compute_presence_prorated_fixed_wage: Some days in the year was not counted as sick day and since few days are not counted, the payslip amount is > 0. 
3 - By diving deeper: in function _get_calendar_days: date_to = min(date_max, leave.date_to.date()), from this line, I observed that leave.date_to is calculated 1 days before sometimes.

Bug solution:
1 - In _get_calendar_days, leave.date_from and leave.date_to is converted to the employee's timezone from UTC.

task - 5853076
Runbot Error

## Dependent PR
https://github.com/odoo/enterprise/pull/98463

## Description of the issue/feature this PR addresses:
Users are blocked when trying to use the **Settle Due** feature in Point of Sale if the ZATCA (l10n_sa_edi_pos) integration is enabled.

## Current behavior before PR:
When a PoS order is created using a "Pay Later" payment method, an invoice is correctly generated and sent to ZATCA.

However, when the user later tries to settle that customer's due balance (using the **Settle Due** option), the l10n_sa_edi_pos module incorrectly forces the Invoice option to be enabled and makes the field read-only. This blocks the user because:

- Settlement orders do not contain any lines, so a new invoice cannot be generated.
- The original invoice was already sent to ZATCA, and the settlement payment should not be sent as a new e-invoice.

Thus, the user cannot proceed with the settlement.

## Desired behavior after PR is merged:
After this fix, the **Invoice** checkbox will no longer be forced or marked as read-only during **Settle Due** operations. The field will default to False, aligning with standard Odoo behavior for settlements and allowing the user to complete the payment.

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#245163
Forward-Port-Of: odoo/odoo#233769

## Description of the issue/feature this PR addresses:
The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation.

## Current behavior before PR:
When a user initiates a **Settle Due** payment for a customer, Odoo creates a new order and sets the `is_settling_account` flag to True. If the user proceeds to the payment screen but then navigates back (to the product screen) instead of completing the payment, the flag remains True.

This is problematic because the user can then add regular products to this same order and check out. The order is processed as a normal sale, but it is incorrectly flagged as a settlement, which can lead to error on codes depending on this.

## Desired behavior after PR is merged:
After this fix, if a user leaves the payment screen during a **Settle Due** operation, the `is_settling_account` flag on the order will be correctly reset to False. 

task-id - 5144679

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

Forward-Port-Of: odoo/enterprise#105129
Forward-Port-Of: odoo/enterprise#98463

## Versions
saas-18.3+

## Issue
Non admin users get an access error when trying to validate a direct debit mandate.

## Steps to reproduce
As admin user:
- Navigate to "Users":
  - Select Marc Demo:
    - Under "Access Rights", in the "Accounting" section, set his "Accounting" role to "Invoicing & Banks";

As Marc Demo:
- Navigate to "Direct Debit Mandates":
  - Create a new mandate for Deco Addict and its first IBAN record;
  - Click on the "Validate" button.

## Cause
Issue introduced by the `action_validate_mandate` method override from b63eb2d6b91be28f4837309b5d972cc0b05846e0 Non admin users have no permissions on `payment.provider` while `_read_group` checks read rights on model via https://github.com/odoo/odoo/blob/ac084b1010faf49b63844ecc96284d567e59de2e/odoo/orm/models.py#L1632

## Fix
Allow `payment.provider` access only on mandate validation as only `account.group_validate_bank_account` users can create a new mandate.

opw-5255694

Forward-Port-Of: odoo/enterprise#105428
Forward-Port-Of: odoo/enterprise#103673

**Issue**
When producing a large number of serial-tracked products, a RecursionError
can occur.

**Steps to reproduce**
- Create three products tracked by serial number (ensure MTO and Manufacture
  routes are enabled).
- Create a BoM for product A containing product B.
- Create a BoM for product B containing product C.
- Create a BoM for product C containing another product.
- Create a manufacturing order of 100 units for product A and confirm it.
- Produce the 100 units on the child MO of product C (100 backorders are created).
- On the main MO (product A), click on "Prepare MO".
- Attempt to produce product B.
→ RecursionError: maximum recursion depth exceeded.

**Cause**
While setting `move_finished_ids`:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/mrp/models/mrp_production.py#L806

the `deadline_date` of the final move is updated:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L742C1-L743C63

This deadline is then propagated to chained moves:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L539C1-L541C55
via:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L559C1-L562C61

This propagation retriggers the `move_finished_ids` setter recursively on other
moves. The recursion depth grows with the number of generated moves, eventually
exceeding Python's maximum recursion limit.

opw-[5265424](https://www.odoo.com/web#id=5265424&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#239648

## Summary

This PR fixes a bug where the `login_date` field is not updated when users authenticate via LDAP.

**Fixes:** #244847

## Problem

When a user logs in via LDAP authentication, the `login_date` (Latest Authentication) field remains empty or keeps its old value. This happens because the `_login` method in `auth_ldap` returns early after successful LDAP authentication, bypassing the standard call to `_update_last_login()` that normally happens in the base `res.users` implementation.

## Technical Analysis

In `addons/auth_ldap/models/res_users.py`, the `_login` method:
1. Catches `AccessDenied` from the base implementation
2. Attempts LDAP authentication
3. On success, immediately returns the auth dictionary

This bypasses `user._update_last_login()` which is called in `odoo/addons/base/models/res_users.py` after credential verification.

## Solution

Modified the LDAP login flow to:
1. Extract `uid` from `_get_or_create_user()`
2. Call `_update_last_login()` on the user before returning
3. Return the auth dictionary with the extracted `uid`

```python
uid = Ldap._get_or_create_user(conf, login, entry)
# Update last_login as it would be done in base _login method
user = self.env['res.users'].browse(uid)
user.with_user(user)._update_last_login()
return {
    'uid': uid,
    'auth_method': 'ldap',
    'mfa': 'default',
}
```

## Testing

Added a test assertion to verify that a `res.users.log` entry is created after LDAP login, which populates the `login_date` field.

## Steps to Verify

1. Install `auth_ldap` module
2. Configure a valid LDAP server
3. Log in with an LDAP user
4. Check Settings > Users & Companies > Users
5. ✅ The "Latest Authentication" field should now show the login timestamp

---

[Gittensor contribution - GlobalStar117]

This reverts commit https://github.com/odoo/odoo/commit/0ffb96dedc776552564cec28140340ec38dee9d1.

The commit was incomplete and while it prevented the crash, the resulting table
did not match the expected layout.

Original issue:

Problem:
The grid conversion logic only finalized a row when iterating through the
last column in the input list. If a row reached exactly 12 grid spans
while more columns remained (e.g., a `col-12` in the middle), the logic
did not start a new row. As a result, remaining columns overflowed the
current row visually.

Cause:
In a single row, if a column had a size 12 and was followed by another column of
any size, it would crash because the algorithm did not reset the index to the
start of the next row.

Steps to reproduce:
- Add a Marketing block.
- Reduce the size of the left card from the left side.<img width="719" height="580" alt="image" src="https://github.com/user-attachments/assets/1e62eaf7-6ab1-4120-b643-62427ce3ec3a" />
- Save.
- Traceback.

Solution:
This more thorough fix properly handles all problematic aspects:
- filter conflicting `col-x` instructions on a single element to keep only one
  size
- ensure that a gridIndex of 12 does not cause a crash in the algo
- properly add all effective `td` in a row in all circumstances (there where
  cases where the final row could be omitted)

opw-5439481

Co-authored-by: Damien Abeloos <abd@odoo.com>
Co-authored-by: Thomas Josse <thjo@odoo.com>
Co-authored-by: Walid Sahli <wasa@odoo.com>

**Steps to reproduce:**
- Make a rounding method, put 1.00 as the value and nearest as the method
- Make a product without tax, the price should be 16.50
- Go to the PoS, order that product
- On the payment screen, click Cash, the value is rounded to 17
- Input "20" to change the payment line's value
- The change is "-4", which doesn't make sense as the price to pay was 17

**Why the fix:**
Before this commit, we used the round function, which is symmetric, meaning that as round(1.23) with a
precision of 0.1 and UP method will return 1.3, the same with round(-1.23) will return -1.3, meaning the rounding method will return the same number and just change the sign depending on if the input is positive and negative.

This causes inconsitencies, because clicking Cash would set the price to pay to 17, but paying 20 would set the change to -4.

With an assymetric rounding we prevent this problem, as it inverts the rounding method if the value is negative. In our case, this means that the change will be rounded DOWN, to -3.

opw-5476694

Issue
-----
Commit 76196c4c5f2ff01354931df6ad615f1b2c4d9a22 introduced logic to select the rate based on the requested currency. This causes problems when the requested currency does not match the one set up on the Fedex account, because the 'actualRateType' gets set to payor instead of preferred for the rate's 'rateType', which means

`d['rateType'] == rating_result['actualRateType']`

is false, so `actual` is empty, leading to an error when doing `actual['totalNetCharge']`.

Solution
-----
In the request we send, we hardcode

`'rateRequestType': ['PREFERRED']`

so we can look for a match using 'PREFERRED' as a prefix of `rateType`.

The Fedex API lists all possible values of the enum `rateType`

https://developer.fedex.com/api/en-us/catalog/ship/v1/docs.html

<details>
<summary>Enum values as per the API</summary>

"enum": [
	"INCENTIVE",
	"NEGOTIATED",
	"PAYOR_ACCOUNT_PACKAGE",
	"PAYOR_ACCOUNT_SHIPMENT",
	"PAYOR_CUSTOM_PACKAGE",
	"PAYOR_CUSTOM_SHIPMENT",
	"PAYOR_LIST_PACKAGE",
	"PAYOR_LIST_SHIPMENT",
	"PAYOR_RETAIL_PACKAGE",
	"PAYOR_RETAIL_SHIPMENT",
	"PREFERRED_ACCOUNT_PACKAGE",
	"PREFERRED_ACCOUNT_SHIPMENT",
	"PREFERRED_CUSTOM_PACKAGE",
	"PREFERRED_CUSTOM_SHIPMENT",
	"PREFERRED_INCENTIVE",
	"PREFERRED_LIST_PACKAGE",
	"PREFERRED_LIST_SHIPMENT",
	"PREFERRED_NEGOTIATED",
	"PREFERRED_RETAIL_PACKAGE",
	"PREFERRED_RETAIL_SHIPMENT",
	"RATED_ACCOUNT_PACKAGE",
	"RATED_ACCOUNT_SHIPMENT",
	"RATED_CUSTOM_PACKAGE",
	"RATED_CUSTOM_SHIPMENT",
	"RATED_LIST_PACKAGE",
	"RATED_LIST_SHIPMENT",
	"RATED_RETAIL_PACKAGE",
	"RATED_RETAIL_SHIPMENT",
	"UNKNOWN"
],

</details>

There are only 3 possible prefixes: `PAYOR`, `PREFERRED` & `RATED`, so replacing the other 2 by `PREFERRED` should be safe.

-----
Ticket:
opw-5482949

Forward-Port-Of: odoo/enterprise#105156

The `_parse_bnb_data` method assumed that the Bulgarian National Bank (BNB) provides exchange rates against BGN (Bulgarian Lev). However, since Bulgaria joined the Eurozone on January 1, 2026, the BNB now provides rates against EUR.

This caused the error "Your main currency (EUR) is not supported by this exchange rate provider" when Bulgarian companies with EUR as their main currency tried to sync exchange rates.

refs:

We can compare the data here from 31 December using the WayBackMachine:
https://web.archive.org/web/20251231193558/https://www.bnb.bg/Statistics/StExternalSector/StExchangeRates/StERForeignCurrencies/index.htm

Compared to today:
https://www.bnb.bg/Statistics/StExternalSector/StExchangeRates/StERForeignCurrencies/index.htm

And see the comparison used to be to BGN but is now for EUR

Steps To Reproduce:
1. Create a company for Bulgaria with EUR as the main currency.
2. Go to Accounting Settings -> Automatic Currency Rates.
3. Select "[BG] Bulgaria National Bank" as the service provider.
4. Click the sync button.
5. Error appears: "Your main currency (EUR) is not supported by this exchange rate provider. Please choose another one."

The fix updates the base currency from BGN to EUR, matching the current BNB XML format which now provides rates against EUR.

Note: Companies with BGN as main currency will now get the same error, which is expected since the BNB no longer provides BGN-based rates. This behavior was discussed and confirmed with the PO.

Ticket [link](https://www.odoo.com/odoo/project.task/5483771)
opw-5483771