Changing the analytic account on the journal entry generated by a company-paid expense creates an unwanted auto-balancing line.

## Steps to reproduce
1. Create an expense paid by the company.
2. Confirm and generate the expense report.
3. Reset the expense’s journal entry to draft and add an analytic account on the first line.
→ An auto-balancing line is added to the entry, and the remaining lines are incorrectly debited.

## Cause
For company-paid expenses, the generated journal entry represents a *payment* rather than an *invoice*.
In `_prepare_product_base_line_for_taxes_computation`, this causes the method to use `product_line_amount_currency` as the price unit, which excludes taxes.

However, in `hr_expense`, the same method always defines `special_mode['total_included'] = False`.
This combination leads `_get_tax_details` to call `_eval_tax_amount_price_included` instead of `_eval_tax_amount_price_excluded`, reapplying the tax on the lines.
As a result, the move becomes unbalanced and Odoo generates an auto-balancing line to compensate.

## Solution
Keep the special mode as *total excluded* for payments generated by company-paid expenses, since their tax and product lines are already handled separately in the corresponding `account.move`.

**opw-5166707**


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

Forward-Port-Of: odoo/odoo#243052
Forward-Port-Of: odoo/odoo#233841

This fixes two overrides of `unlink()` that break when module `mail` is being uninstalled.
It also fixes the uninstalling system to comply to the spec of the `ondelete` decorator.

### Add warnings when some model/field could not be deleted

The uninstallation process tries to delete all the records created by the modules being uninstalled.  It uses a best-effort strategy, i.e., it skips the records that cannot be deleted, whatever the reason.  But some records are very likely to cause problems, namely `ir.model` and `ir.model.fields` records, because skipping them implies not cleaning up their corresponding table's schema.

For instance, if a column is not dropped, reinstalling the corresponding module will possibly cause inconsistencies, because
 - the column contains old values for existing records, which won't be recomputed (if the field is computed);
 - the column contains NULLs for records created between the uninstallation and the reinstallation of the module.

We therefore add a warning in those cases, in order to detect and fix those potential issues as soon as possible.

### Make ondelete decorator work as documented

A method decorated with `@api.ondelete(at_uninstall=False)` should be called except when the method's module is being uninstalled.  Currently the method is skipped when *any* module is uninstalled.

The fix consists in adding the set of modules being uninstalled in the attribute `registry.uninstalling_modules`, which may be used to detect uninstallation and determine which modules are being uninstalled.

### Replace MODULE_UNINSTALL_FLAG by new conventional flag 'force_delete'

We turn constant `MODULE_UNINSTALL_FLAG` into an explicit conventional flag, and rename it `force_delete` for the sake of simplicity.  The idea is to decouple the flag from uninstallation.  The caller simply uses
```py
records.with_context(force_delete=True).unlink()
```
to bypass some deletion hooks, which typically prevent deletion by raising some exception, in order to avoid data inconsistencies.  On the callee's side, one has to explicitly detect the flag and skip the checks, like in:
```py
@api.ondelete(at_uninstall=False)
def _prevent_deleting_confirmed(self):
    if self.env.context.get('force_delete'):
        return
    if any(record.state == 'confirm' for record in self):
        raise UserError(_("You cannot delete confirmed records!"))
```
Note that the uninstallation process uses the convention by automatically adding `force_delete=True` in the `context` for deleting records.

### Fix issue module mail uninstallation

Two overrides of `unlink()` on models `ir.model` and `ir.model.fields` fail when uninstalling module "mail", because their code relies on some columns and those columns have been dropped already.  This causes some table and column to remain after uninstallation.  When reinstalling module "mail", errors like follows are logged:
```
column "mail_message_id" of relation "mail_tracking_value" contains null values
```
The fix consists in turning the overrides in proper "ondelete" methods, which are skipped when module "mail" is uninstalled.


https://github.com/odoo/enterprise/pull/103651

Task: [#5420237](https://www.odoo.com/odoo/project/1737/tasks/5420237)

---

There is a constraint on the `pos.config` model that prevents opening a POS session when multiple online payment methods are configured for the same POS config. However, from the `pos.payment.method` model, it is still possible to add multiple online payment methods to a single POS config, which then prevents opening a session.

In addition, if a session is already open, it is no longer possible to resolve the situation:

* From `pos.payment.method`: the POS session must be closed before removing the POS config from an online payment method.
* From `pos.config`: the payment methods field is read-only when there is an open session.

We had to delete one of the online payment methods from the database directly to be able to open the POS session again.

To prevent this inconsistent state, a constraint is added on `pos.payment.method` to ensure that each POS config has at most one online payment method.

Forward-Port-Of: odoo/odoo#240343

Whenever an error occurs during the ZATCA onboarding steps—such as
providing a company name that exceeds 127 bytes in binary representation
(for example, 64 Arabic characters without whitespace result in exactly
127 bytes; see refs [1] and [2])—the system returns a traceback to the
user instead of a clear and user-friendly error message.

Error:
`TypeError: argument should be a bytes-like object or ASCII string, not 'NoneType'

This is due to the check-in `_l10n_sa_request_production_csid` for an 'error'
key, not present in the response when an OTP is invalid because in these cases,
the `_l10n_sa_call_api` returns the response_data directly.

This fix improves the behaviour by displaying a user-friendly alert message
with the error returned by ZATCA, instead of a traceback.

This ensures a better experience and compliance with CCSID onboarding flows.

[1]: https://zatca1.discourse.group/t/organization-name-is-too-long-issue-csr/7571
[2]: https://zatca1.discourse.group/t/organisation-name-with-restriction-of-64-characters/960

sentry-7169834710

Forward-Port-Of: odoo/odoo#242810

Currently, an error occurs when user creates an attendance with Planning as the Work Entry Source.

**Steps to Reproduce([Video](https://drive.google.com/file/d/1vGIZswZ-0D_ISAKn8LltYlGgQ7gzI6oA/view)):**
 - Install the `hr_work_entry_planning_attendance` module.
 - Go to `Employees` and create a `new employee` or open an `existing one`.
 - In the `Payroll` section, set `Work Entry Source` to `Planning`.
 - Go to `Planning` and create a planning slot for this employee `(if it does not exist)` with `Allocated Time` set to less than 100%.
 - Go to `Attendance` and create `an attendance for this employee` within the planning slot start and end dates.

**Error 1:**
`AttributeError: 'method_descriptor' object has no attribute 'min'`

**Error 2:**
`TypeError: Intervals.__init__() takes from 1 to 2 positional arguments but 4 were given`

**Cause:**
When the Work Entry Source is set to Planning and an attendance is created for that employee, the system updates overtime (if any) and retrieves the scheduled working time from the planning slot.
If the planning slot has less than 100% allocated time, it is split day by day, keeping only a portion of each day’s working hours based on the allocation percentage. While creating a datetime at the very start or end of a day, an error occurs due to incorrect access of the min or max attribute from datetime. 
Another issue occurs when creating intervals using the start and end dates: an error is raised because separate start and stop arguments are passed instead of a list of interval tuples.

**Fix:**
This commit ensures that the correct datetime.min.time() / datetime.max.time() values are used and that intervals are provided in a list-of-tuples format.

[1]- https://github.com/odoo/enterprise/blob/ee8919530ef5835d539b3ade47fa450f736b22a3/hr_work_entry_planning_attendance/models/hr_employee.py#L56-L57

[2]- https://github.com/odoo/enterprise/blob/ee8919530ef5835d539b3ade47fa450f736b22a3/hr_work_entry_planning_attendance/models/hr_employee.py#L60

**No Task ID**

Forward-Port-Of: odoo/enterprise#103662

Steps to reproduce:
-
  1. Configure a warehouse for multi-step delivery (e.g., Pick + Ship).
  2. Create a Sales Order for a product and fully process the delivery, including all steps.
  3. Create a Helpdesk ticket for that customer.
  4. From the ticket, click the "Return" button to open the wizard and select the sales order.

Issue:
-
The return wizard incorrectly defaults to the first operation in the delivery chain (e.g., the internal 'PICK' operation) instead of the final, customer-facing 'OUT' operation.

Cause:
-
Since picking is ordered by 'priority, scheduled_date asc, id desc', records are sorted by scheduled_date, this often resulted in selecting an internal 'PICK' operation instead of the final 'OUT' operation, making a more specific filter necessary.

Fix:
-
The code now explicitly filters for pickings with the type code 'outgoing' and sets it as the default delivery order.

task-4948134

Forward-Port-Of: odoo/enterprise#103883
Forward-Port-Of: odoo/enterprise#93154

Steps to reproduce
------------------
1. In PoS settings, set the "Tax Display" to "Tax-Excluded Price"
2. Enable customer display
3. Open a PoS session, and open the customer display simultaneously
4. Add products, notice that the total in PoS is price included as expected. However, the total in cusromer display is tax excluded, so customer thinks he will be pay less.

Why it happens
----------------
In the refactors done in 9538698f13d5763b4, we mistakenly set the order.amount (i.e. total amount) to follow the config "Tax Display". However, that price should always be tax incl.

In this PR, we now use the `currencyDisplayPriceIncl` getter, instead of the config dependent `currencyDisplayPrice`.

Additional enhancements
-------------------------
In additional to total price, we also display the taxes amount not. And In case of "Tax-Excluded" price config, also display the subtotal (total price excluded). **That follows exactly the UI of the main cart in the products page**.

So now we have
----------------
Tax included: 
<img width="558" height="659" alt="image" src="https://github.com/user-attachments/assets/51415c5c-2234-48dd-a974-572a6b090714" />

Tax excluded: 
<img width="550" height="661" alt="image" src="https://github.com/user-attachments/assets/2c664716-49ab-44eb-bb30-ad42206bc849" />


opw-5401560

Forward-Port-Of: odoo/odoo#239250