Issue before this PR:
=========================
- Currently, when printing a `Packages` report that contains `multiple packages` all `Package with Content` reports are printed as a `single continuous document` without any line or page separation between packages.

- This leads to issues because each `Package with Content` report is meant to be printed individually and physically attached to its corresponding package during packing and logistics operations. It creates `confusion and a risk of mislabeling`, as users must `manually interpret and separate package boundaries` when handling printed documents.

Steps to Reproduce:
=========================
1. Install the `Inventory` app.
2. Go to Configuration → Settings and enable the `Packages` option.
3. Create a new transfer with multiple product lines and click `Mark as Todo`.
4. In Detailed Operations, assign `different packages` to at least two different product lines and `Validate` the transfer.
5. Open the `Actions` menu, select `Print → Packages`.
6. Open the generated PDF. All packages are printed on the same page, without any page or line separation.

**Packages report before this PR:**

<img width="500" height="300" alt="combined" src="https://github.com/user-attachments/assets/6a6b8cb5-bcf3-488e-b95a-7670db8fc6ad" />

Cause of the issue:-
=========================
In the file `report_package_barcode.xml`, a `t-foreach` loop is used to iterate over the packages included in the report. However, the report template does not define any `page break or visual separation` between iterations. As a result,
each package is rendered consecutively in a single, continuous page instead of being split into separate pages.

After this PR:-
=========================
This PR ensures that, when printing a `Packages` report containing `multiple packages`, each `Package with Content` starts on a new page. This clear separation allows users to easily identify and handle `individual package details`, reducing confusion and the risk of mislabeling, while preserving the existing report layout and content.

**Packages report after this PR:**

<img width="491" height="500" alt="breaked (1)" src="https://github.com/user-attachments/assets/d87a52e5-8b54-49d4-911a-2e07e487c0d8" />

TaskID-5025192

Forward-Port-Of: odoo/odoo#241762

Why this commit
---

When adding a rental accessory product from the cart page suggested products, the [add_to_cart](https://github.com/odoo/enterprise/blob/19.0/website_sale_renting/controllers/cart.py#L52-L58) was triggered without the rental start and end dates(None was taken by default). As a result, the system uses [default rental duration](https://github.com/odoo/enterprise/blob/19.0/website_sale_renting/models/sale_order.py#L95-L99) for comparison and considers the accessory as having a different rental period then on the sale order and raised an error
 preventing it from being added to the cart.

This issue did not occur when adding the same product from its product page, as the rental context was correctly provided there.

After this Commit
---
The rental start and end dates from the current sale order are  passed when adding accessory products from the cart page suggested products. This ensures that rental period consistency checks succeed and the accessory can be added without raising an invalid operation error.

Steps to Reproduce
---
1. Create two rental products A and B.

2. Configure product B as an accessory of product A.

3. Add product A to the cart with any rental period(except default).

4. From the cart page, attempt to add product B from suggested products.

5.Observe the error about mixing different rental periods.

Here is the video demonstrating on how the error is reproduced :


https://github.com/user-attachments/assets/3d5e6f96-cebd-4221-8592-1bdb6ae40ec7



Expected Result

The accessory product is added to the cart using the same rental period as the existing cart's rental period.

OPW: 5823691

Forward-Port-Of: odoo/enterprise#107343
Forward-Port-Of: odoo/enterprise#106426

Issue before this commit:
=========================
Creating a scrap order from a specific workorder in the shopfloor
view raises a traceback: `The method 'mrp.workorder.action_scrap' does not exist.`

Additionally, in the scrap form view, the `Lot/Serial Numbers field is displayed for 
non-tracked(e.g. consumables such as screw) products`, incorrectly prompting the 
user to add a lot/serial number.

Steps to Reproduce:
=========================
- Install the mrp module.
- Create a Manufacturing Order for a product with at least 
   one operation (e.g. Desk Combination).
- Open the shopfloor view.
- Enter a specific workcenter (e.g. Assembly 1).
- Open the three-dot menu and create a scrap order.
- Confirm the scrap order.
- A traceback is raised.

Cause of the issue:
=========================
The method action_scrap was removed from mrp.workorder 
in [this PR](https://github.com/odoo/odoo/pull/210299), However,  from the JavaScript side, 
the scrap option still triggers a call on the mrp.workorder model 
when the user clicks Scrap in the shopfloor view.

With This Commit:
=========================
Reintroduce the action_scrap method on mrp.workorder so 
users can correctly create scrap orders from a specific workcenter in the 
shopfloor view without triggering a traceback.

Fix the visibility condition of lot_ids so the Lot/Serial Numbers field is hidden
for non-tracked (consumable) products and is shown only for trackable products (lot/serial).

Enterprise PR: https://github.com/odoo/enterprise/pull/108259

Task: 5958933

Version – saas-18.4

### Issue:
When an applicant has both a partially signed offer and a fully signed offer,
deleting the partially signed one also deletes the employee that was created
from the fully signed offer.

### Steps to Reproduce:

- Create two offers for an applicant.
- Fully sign the first offer and partially sign the second one.
- Delete the partially signed offer.
 The employee created from the fully signed offer is also deleted.

### Cause:
Due to this issue, the employee record is incorrectly deleted from the system,
which is not expected behavior.

### Fix:
Improved the employee deletion logic by deleting the employee only when:
- the employee is archived, and
- they do not have any other offers besides the one being deleted.

### Impact:
The employee will no longer be deleted when another partially signed offer for
the same applicant is removed.

---

Task – 5347109

Forward-Port-Of: odoo/enterprise#108634
Forward-Port-Of: odoo/enterprise#100991

**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.
- Go to the MO C and split into 100 mo
- Go to the MO B and split into 100 mo
-> RecursionError: maximum recursion depth exceeded.

**Cause**
While splitting, this method is called:
https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/mrp/models/mrp_production.py#L2031 which ultimately calls:
https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/stock/models/stock_move.py#L658-L661 This retriggers `_compute_packaging_uom_id` for all moves in `move_orig_ids` or `move_dest_ids`, and accessing the full recordsets causes recursive recomputation leading to a RecursionError.

opw-5265424

Forward-Port-Of: odoo/odoo#247839

**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.
- Go to the MO C and split into 100 mo
- Go to the MO B and split into 100 mo -> RecursionError: maximum recursion depth exceeded.

**Cause**
While splitting, this method is called:
https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/mrp/models/mrp_production.py#L2031 which ultimately calls:
https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/stock/models/stock_move.py#L658-L661 This retriggers `_compute_packaging_uom_id` for all moves in `move_orig_ids` or `move_dest_ids`, and accessing the full recordsets causes recursive recomputation leading to a RecursionError.

opw-5265424

Forward-Port-Of: odoo/enterprise#106999

#### Issues:
VAT Book should download for all selected companies with same CUIT as the current one.

#### Step to reproduce:
- In a company in Argentina ("Parent Company")
- Create a branch "Child Company A" with no CUID
- Create a branch "Child Company B" with a different CUID than parent
- Go to "Child Company A"
- Either:
  - i.  Select both "Parent Company" and "Child Company A" but not "Child Company B"
  - ii. Select all 3 "Parent Company", "Child Company A" and "Child Company B"
- In Accounting > Report > Tax Return :
- Download the VAT Book (wheel > "VAT book(ZIP)")

#### Current behavior:
i.  Get Invalid Operation
ii. Download the VAT Book for "Parent Company" only

#### Expected behavior:
- Download the VAT Book for both "Parent Company" and "Child Company A"

A previous call to get_options provide the client with the info about which selected companies have the same CUIT as the current company. Therefore companies in the options are the correct ones.

opw-5385585

Forward-Port-Of: odoo/enterprise#108466
Forward-Port-Of: odoo/enterprise#101898

Steps to reproduce:
1. Create a fully restricted folder in Documents.
2. Share it with a portal user as an editor.
3. Insert a file into the folder.
4. Log in as the portal user and access the Documents portal.
5. The view crashes and the file is not visible.

Cause:
Recent changes added `write_date` to the `many2one_avatar_user` widget
for image cache-busting. When portal views load, the frontend requests
this field for the document's `owner_id`. Since portal users lack read
access to `res.users`, this triggers an Access Error and crashes the
view. Furthermore, clicking the avatar opens a popover with a "View
Profile" button that also crashes for portal users, as they cannot
access backend form views.

Solution:
1. Register a new `many2one_avatar_user_no_unique_cache` widget that
inherits the standard avatar but drops the `write_date` requirement.
2. Apply this widget to the `owner_id` field in Documents portal
views to prevent the ACL error while keeping the avatar visible.
3. Update the avatar card popover to only show the "View Profile"
button if the current user is internal (`user.isInternalUser`).

Task-5977195

*: account,sale,stock_delivery

Since [19.0](https://github.com/odoo/odoo/pull/217277#issue-3198442339), read access rights are checks on comodels when trying to read the value of a many2many fields you have read acccess to. This change highlight numerous access right issues in basic flows for users with minimal access.

Here is a list of examples (each performed with every other access rights disabled):
- With a `stock user`, open the delivery list or form view
 #### > Access error
- With a `purchase user` create and confirm a PO > Upload Bill
####  > the Bill will be created but an access error will prevent the draft bill from opening.
- With a `sale user` create and confrim an SO > Create invoice
####  > the invoice will be created but an access error will prevent the draft invoice from opening.

## Solutions:

### Use case: Open an invoice (`acount.move`) linked to one of your SO/PO with a basic `sale`/`purchase` user:

1) For basic `sale` and `purchase` users to be able to open the `account.move` Form on which they have read, update, create, delete access rights, it is necessary for the `payment_count` to be compute sudo since it is used in the view:
https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/account/views/account_move_views.xml#L859 And these users do not have the read access of the `account.payment` model.

Similarily the `_compute_asset_ids` needs to be compute sudo because it relies on the related `asset_ids` of `account.move.line`s or on values of these `account.asset`s for which the users shoud not have read access: https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/models/account_move.py#L27-L30 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/models/account_move.py#L317-L323 and the `asset_ids`, `count_asset`, `asset_id_display_name` and `draft_asset_exists` are all used in the view.

#### Note for master:

IMO, the `asset_ids` field of the `account.move` model should probably be in a separate compute to not be computed in sudo and removed from the views as it is currently used only to determine if there is or not `asset_ids`. An information that is provided by the `count_asset`. E.G. here:
https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L10 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L35-L40 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L44-L52

2) For basic `purchase` users to open the invoice linked to one of their PO, it is necessary that the `sale_order_count` is computed in sudo as they do not have access to the related `sale_line_ids` field and the field is used in the `account.move` form:
https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/sale/models/account_move.py#L46-L49 https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/sale/views/account_views.xml#L53

### Use case: Open a `stock.picking` views as basic stock user:

3) The basic `stock` users have a read access on the `delivery.carrier` model and should also on the related `delivery.zip.prefix` and `delivery.price.rule` models. First as it make sense functionally but also as it currently blocks them on basic flows. For instance basic stock users can not open the `stock.picking` list or form view as the `carrier_id` is part of these view:
https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/stock_delivery/views/delivery_view.xml#L125-L132 This is problematic as this field has a domain relying on the related `allowed_carrier_ids` field:
https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock_delivery/models/stock_picking.py#L23-L24 As such, when the view is opened, the related field needs to be read. However, the `_compute_allowed_carrier_ids` fails if you do not have read access rights on the `delivery.zip.prefix` model: https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L198 https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L70-L72 Similarily `delivery.price.rule` model should be readable for `stock` users in order to be able to get be able to rely on the `price_rule_ids` when necessary such as here:
https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L492-L496

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

opw-5461135
opw-5417749

Forward-Port-Of: odoo/odoo#249138
Forward-Port-Of: odoo/odoo#247531

*: account_asset, sale_lazada

Since [19.0](https://github.com/odoo/odoo/pull/217277#issue-3198442339), read access rights are checks on comodels when trying to read the value of a many2many fields you have read acccess to. This change highlight numerous access right issues in basic flows for users with minimal access.

Here is a list of examples (each performed with every other access rights disabled):
- With a `stock user`, open the delivery list or form view
 #### > Access error
- With a `purchase user` create and confirm a PO > Upload Bill
####  > the Bill will be created but an access error will prevent the draft bill from opening.
- With a `sale user` create and confrim an SO > Create invoice
####  > the invoice will be created but an access error will prevent the draft invoice from opening.

## Solutions:

### Use case: Open an invoice (`acount.move`) linked to one of your SO/PO with a basic `sale`/`purchase` user:

1) For basic `sale` and `purchase` users to be able to open the `account.move` Form on which they have read, update, create, delete access rights, it is necessary for the `payment_count` to be compute sudo since it is used in the view:
https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/account/views/account_move_views.xml#L859 And these users do not have the read access of the `account.payment` model.

Similarily the `_compute_asset_ids` needs to be compute sudo because it relies on the related `asset_ids` of `account.move.line`s or on values of these `account.asset`s for which the users shoud not have read access: https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/models/account_move.py#L27-L30 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/models/account_move.py#L317-L323 and the `asset_ids`, `count_asset`, `asset_id_display_name` and `draft_asset_exists` are all used in the view.

#### Note for master:

IMO, the `asset_ids` field of the `account.move` model should probably be in a separate compute to not be computed in sudo and removed from the views as it is currently used only to determine if there is or not `asset_ids`. An information that is provided by the `count_asset`. E.G. here:
https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L10 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L35-L40 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L44-L52

2) For basic `purchase` users to open the invoice linked to one of their PO, it is necessary that the `sale_order_count` is computed in sudo as they do not have access to the related `sale_line_ids` field and the field is used in the `account.move` form:
https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/sale/models/account_move.py#L46-L49 https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/sale/views/account_views.xml#L53

### Use case: Open a `stock.picking` views as basic stock user:

3) The basic `stock` users have a read access on the `delivery.carrier` model and should also on the related `delivery.zip.prefix` and `delivery.price.rule` models. First as it make sense functionally but also as it currently blocks them on basic flows. For instance basic stock users can not open the `stock.picking` list or form view as the `carrier_id` is part of these view:
https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/stock_delivery/views/delivery_view.xml#L125-L132 This is problematic as this field has a domain relying on the related `allowed_carrier_ids` field:
https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock_delivery/models/stock_picking.py#L23-L24 As such, when the view is opened, the related field needs to be read. However, the `_compute_allowed_carrier_ids` fails if you do not have read access rights on the `delivery.zip.prefix` model: https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L198 https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L70-L72 Similarily `delivery.price.rule` model should be readable for `stock` users in order to be able to get be able to rely on the `price_rule_ids` when necessary such as here:
https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L492-L496

opw-5461135
opw-5417749

Forward-Port-Of: odoo/enterprise#107732
Forward-Port-Of: odoo/enterprise#106694

Step to Reproduce:
- install UAE Payroll localization and attendance
- create employee and running employee contract and give basic salary, housing, transportation and other allowance.
- work entry source should be attendance
- create a payslip and compute sheet.

Issue:
- The values for payslip lines are not as expected.
- The rate per hour for basic salary , housing, transportation and other allowances was being calculated based on employee's attendance work entries, not the planned working schedule.

Reason:
- When using attendance-based contracts, the hourly rates for basic salary, housing, transportation, and other allowances should be calculated based on the working schedule's hours per day, if a working schedule is available.

Solution:
- Instead of sum_worked_hours which takes working hours of employee's work entries, use total_number_of_days multiplied by the hours per day from the working schedule.

task-5270185

Forward-Port-Of: odoo/enterprise#108863
Forward-Port-Of: odoo/enterprise#103282

Problem
------------------
The salary inputs selection widget only displays the main salary rule, not the dependent rules, so when a new dependent rule is created after the main one was added to the employee form, it is not possible to select the the new rule to display.
Navigation:
1. Payroll > Configuration > Rules > New > Condition Based On: Salary Input > Input On: Employee > Save
2.  Employees > Select Employee > Payroll > Add Inputs > Select Rule > Save
3. Configuration > Rules > New > Condition Based on: Salary Input > Input On: Employee > Depends On: Previous Rule > Save
4. Employees > Select Employee > Payroll > Add Inputs > New Rule is not available

Objective
----------------------
Version 19.0 doesn't filter out existing rules, so it is possible to select the prerequisite rule again and add the new dependent rule, but later commits changed the search domain to filter out inputs that were already selected. Some of the changes should probably have been included in the 19.0 version. Need to back port the changes and edit the search domain to show dependent rules that have not been selected yet.

Solution
---------------------------
Option B from the task specifications to show the dependent salary rules when "Add Inputs" is clicked if it's not already displayed even if the prerequisite rule is displayed. Edited the payroll structure search domain to find rules that are not displayed and either do not have prerequisites OR have a prerequisite that is already displayed.

Task: 5942461

Forward-Port-Of: odoo/enterprise#108985
Forward-Port-Of: odoo/enterprise#107719

**Steps to reproduce:**
- Install l10n_ro_saft
- Switch to a Romanian company (e.g. RO Company)

- Create an asset model:
  * Method: Straight Line
  * Duration: 12 Months
- Configure a "Fixed Assets" account:
  * Automate Asset: Create and validate
  * Asset Model: [the asset model created above]
- Create a bill:
  * Vendor: [create a new vendor]
  * Bill Date: [last month]
  * Invoice Line: [A line with the fixed asset account]
- Confirm the bill

- Go to "Accounting / Reporting / Audit Reports / General Ledger"
- Select the current month (The fixed asset account should be present)
- In the cog menu, select "SAF-T (D406 Asset Declaration)"

**Issue:**
A traceback is raised while trying to display the name of a supplier.

**Cause:**
To display the supplier name of an asset, a dict having the id of the customer or supplier as key (i.e. partner_detail_map) is used. This dict is build by getting the list of all partners linked to a posted journal item on an asset (or liability) account in the period of the report.
In this case, it's the current month.
However, the created bill has been posted the month before.
So no journal item is found for the vendor that has been created just for the bill and therefore there is no key for him in the dict, which leads to the error when trying to get the id of the supplier of the asset in the dict.

**Solution:**
Instead of just fetching the posted entries linked to a receivable or payable account in order to get the list of the potential customers and suppliers, we also fetch the depreciation lines that are linked to an asset account and can still be in draft.


opw-5499918

Forward-Port-Of: odoo/enterprise#109014
Forward-Port-Of: odoo/enterprise#105987

Steps to reproduce:
1. Create a fully restricted folder in Documents.
2. Share it with a portal user as an editor.
3. Insert a file into the folder.
4. Log in as the portal user and access the Documents portal.
5. The view crashes and the file is not visible.

Cause:
Recent changes added `write_date` to the `many2one_avatar_user` widget
for image cache-busting. When portal views load, the frontend requests
this field for the document's `owner_id`. Since portal users lack read
access to `res.users`, this triggers an Access Error and crashes the
view. Furthermore, clicking the avatar opens a popover with a "View
Profile" button that also crashes for portal users, as they cannot
access backend form views.

Solution:
1. Register a new `many2one_avatar_user_no_unique_cache` widget that
inherits the standard avatar but drops the `write_date` requirement.
2. Apply this widget to the `owner_id` field in Documents portal
views to prevent the ACL error while keeping the avatar visible.
3. Update the avatar card popover to only show the "View Profile"
button if the current user is internal (`user.isInternalUser`).

Task-5977195

Steps to reproduce
------------------
1. Install `pos_settle_due`
2. Enable "One-Click Payment" from the configs, and make sure it has some valid payment methods (Cash, Card, etc).
3. Open PoS, and click "Settle Invoices" for a client having a "Total Due" > 0
4. Select the invoice(s)
5. Fast settle the invoice by directly paying on the product screen, using one of the fast payment methods on the bottom.

-> The order is payed, however, it only has the fast payment line, while it should also have an additional equivalent "pay later" line, with a negative amount, balancing the amount payed with the fast payment method.

Why the issue
-------------
If we settled this invoice from the payment page, this issue does not happen, i.e. an equivalent "pay later" payment line is created.

That additional "pay later" line is created when calling the `validateOrder` method on the `payment_screen`, which in `pos_settle_due`, is overriden to also add the "pay later" payment lines under certain conditions.

After introducing the "One-Click Payment" feature in #216523, we needed to be able to validate the order in two different places:
1. On the payment screen, that was already taken care of, by the method `validateOrder` mentioned just above, that is normal validation.
2. On the products screen, when using fast payment, that is fast validation.

For that reason, the validation code has been moved from the payment screen to the class `OrderPaymentValidation` which will be used by the two flow: the normal validation and the fast validation.

However, we have forgot to move the `pos_settle_due` specific validation code from payment_screen to the new `OrderPaymentValidation`, hence, the `pos_settle_due` validation that creates the "pay later" PL is only executed from the payment_screen, never from fast validation.

The fix
-------
Now, we move the `pos_settle_due` validation code from `payment_screen` to an override of `OrderPaymentValidation` so it's executed when for both normal and fast validation.

Notes
-----
- We keep the methods in `payment_screen` for backward compatibility, they will be removed in master.
- We replace the usage of `props.isDepositOrder` in the `payment_screen` with `order.is_settling_account`, as they will have both the same value, but `order.is_settling_account` is available on the order, so  it can be used for both normal and fast flows, while `props.isDepositOrder` was only available in the payment screen during normal valuation. On master, we can remove the prop `isDepositOrder` in favor of `order.is_settling_account === true`.

opw-5488587

Forward-Port-Of: odoo/enterprise#108396
Forward-Port-Of: odoo/enterprise#105660