When posting an invoice, the system creates:
- Journal Entry: Dr 131 (Receivable) / Cr 511

Then the system creates a deferral entry:
- Deferral entry: Dr 511 / Cr 3387 (Payable)

Falsifying the Balance sheet report, in the accounts receivable and accounts payable indicators

The issue was that account 3387 was configured as `Payable`, which caused the system to generate both Receivable (131) and Payable (3387) for the same partner. This is incorrect because account 3387 represents "Unearned Revenue", which is a  current liability, not a payable account.

By changing the account type from `Payable` to `Current Liabilities`,
the deferral entry now correctly reflects that 3387 is a current liability account, preventing the incorrect reconciliation behavior where both receivable and payable entries were created for the same partner.

After this fix:
- Entry: Dr 131 (Receivable) / Cr 511
- Deferral: Dr 511 / Cr 3387 (Current Liabilities)

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#238807
Forward-Port-Of: odoo/odoo#237493

Currently, an error occurs when user marks multiple Manufacturing Orders as Done.

**Steps to Reproduce ([Video](https://drive.google.com/file/d/1XfkMB001rMiyulRGrP4dlJFDYByo_5Bv/view?usp=drive_link)):**
 - Install the `mrp` module.
 - Go to `Settings` and enable `Units of Measure & Packagings`.
 - Go to `Products and `create two products` with different `units of measure`.
 - Go to `Manufacturing Orders`, create a manufacturing order by `adding one of the products`, and then `create work order` in the Work Orders section and `confirm` it.
 - Create another `manufacturing order` with the `same quantity` for the second product and add a `Work Order` for it as well and `confirm` it.
 - Go to the `list view`, select `both orders`, and click `Mark as Done` from the `Actions` menu.

**Error:**
```
ValueError: ValueError('Expected singleton: uom.uom(4, 6)') while evaluating
"if records:\n                res = records.filtered(lambda mo: mo.state in {'confirmed', 'to_close', 'progress'}).button_mark_done()\n                if res is not True:\n                    action = res"
ValueError: Expected singleton: uom.uom(4, 6)
```

After [this commit], which improves the performance of button_finish, when a user marks multiple orders as done with the same quantity but different uom , it creates all_vals_dict based on the vals[1] data as the key and the work order as the value[2]. Then it  stores two or more work orders with different UoMs under the same vals key. When attempting to write multiple work orders[3], the precision rounding is calculated, which raises the error[4] due to multiple UoMs.

The commit ensures that when writing records, precision_rounding is calculated separately for each Work Order's UoM.

[this commit]: https://github.com/odoo/odoo/pull/223715/commits/b857d192085a38b612335223d04f8bdff91b898c

[1]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L698-L703

[2]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L706

[3]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L708

[4]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L477

sentry-7050854871

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

Forward-Port-Of: odoo/odoo#238086

Similar to: 0104cee

Steps to reproduce:
--------------------
1. Install hr_timesheet
2. Create a new project and a task
3. On the task, add a timesheet line with some time (e.g., 16 hours)
4. Open the project dashboard > create a new project update >
observe the timesheet time
5. Go to Timesheets > Configuration > Settings
6. Set "Encoding method" to "Days/Half-days"
7. Reopen the project dashboard > create another project update >
observe the timesheet time again

Issue:
------
Incorrect value displayed in the Timesheets. (e.g., 16 Days instead of 2 Days)

Cause:
-------
After commit 28b69da, the UoM model was restructured, changing how conversions 
between hours and days are computed. https://github.com/odoo/odoo/blob/aeda822db05b218fd1271c7666307950b7a98512/addons/hr_timesheet/models/project_project.py#L137-L143

The `total_timesheet_time` value is now already stored in the final unit (e.g., days). 
Whenever a new project update is created, the division in `create()` performs an
unnecessary second conversion on an already converted value, causing the incorrect display.
https://github.com/odoo/odoo/blob/583bacdc8ad2b87b99b11d1e12dacf6e42edf22b/addons/hr_timesheet/models/project_update.py#L36-L37

Solution:
----------
This commit ensures accurate conversion of timesheet values between hours and days.

opw-5184077

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

Forward-Port-Of: odoo/odoo#237532

__
## Short functional explanation of the error
Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in company A, then switch back to company B.
In company B, we create a project and a task, and assign this task. The working time to assign will stay at 0.

## Reproduction Steps
1. Switch to company A and create a timeoff starting before today and ending later.
2. Switch back to company B. Create a project, a stage and a task.
3. Enable the debugger.
4. The field Working Time to Assign is invisible by default, so open studio, click on View, and check
Show Invisible Elements.
5. Click on the tab Extra info and on the block Working time to assign. Uncheck Invisible.
6. Close studio and assign someone to the task. Make sure that you do this operation at a different time than the one recorded for the last stage change.

### Expected behavior
The hours under Working Time to Assign should compute the difference between the last time the task got its stage changed and the time of assignation

### Unexpected behavior
Nothing happens

## Origin of the issue
When computing the working time to assign, we also take into consideration leaves:
if this happened during public holidays, we consider that it took no working time to get assigned.
However, when a holiday is set in another company, the Working Time to Assign duration will be impacted, as the domain to retrieve the corresponding leaves is the following:
https://github.com/odoo/odoo/blob/c7e965a61b7ce856c2daa8e2574cf4c60caf7a20/addons/resource/models/resource_calendar.py#L537-#546

The company isn't taken into account in the domain, applying the holiday for every company.
_________________________________________
opw-5222883

Forward-Port-Of: odoo/odoo#236043

When refunding an order that originally had a global discount, if you didn't refund the discount, the refund total amount would exceed the original order total. This would cause issues when trying to generate a global invoice for the mexican localization.

Steps to reproduce:
-------------------
* Activate the global discount option in any PoS
* Open PoS and make a sale with a global discount
* Refund the sale without including the discount
* Go to the backend
* Go to the order list and select the 2 orders you made
* Now try to create a global invoice
> Observation: The global invoice is in error because the negative lines
  cannot be distributed correctly.

Why the fix:
------------
To avoid this issue with the global invoice we simply prevent the user to generate a refund with a greater amount than the original order. We only apply this limit to the mexican localization because it's the only module that is affected by this issue. Other localizations can still refund without restrictions even if this work flow does not really make sense.

opw-4899501

Forward-Port-Of: odoo/enterprise#100780
Forward-Port-Of: odoo/enterprise#93101

Description
-----------
Following odoo/odoo@238a41e35280256382f6509182b9e900fb4f7aba, the domain for `sale.order.line` in `_get_sale_order_items_query` was modified to search based on the relevant `order_id` `id` or `project_id`. `project_id` is not indexed, leading to a heavy non-selective scan on the primary key for databases with many `sale. order` records. There is poor selectivity with the filter on `sale. order.line` resulting in a heavy join between `sale.order` and `sale.order.line`.

This commit adds the missing index, allowing for `Bitmap Heap Scan` on both indexes and leveraging the selectivity of the project being currently opened.

Benchmark
---------
On a database with 3.5M `sale.order`, 12M `sale.order.line`, opening the "Settings" page of a project with a few sale lines associated with it took:

|              | Before | After |
|--------------|--------|-------|
| Timing (hot) | 9.1s   | 5ms   |

Reference
---------
opw-5280364

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

Forward-Port-Of: odoo/odoo#238995

Steps to reproduce:
- Enable Rental pickings
- Create a rental for a product, for 4 quantity
- Process the delivery
- Open the barcode app and open the reception
- Scan the product once and validate

Issue:
The receipt is validated without issues nor warning, despite being incomplete.

This is due to a bad mix of two changes:
- #60801, which always sets the rental receipt as return of the delivery
- #48788, which removes the backorder check for returns in barcode

For regular returns made in barcode, it makes sense to avoid the backorder check, as from here we're processing a full picking return and we'd have the confirmation pop every time.

However, things are different for rental receipts, as despite them being set as returns of the delivery, they're proper receipts that need to handle the partial receipt.

To avoid the issue, rather than removing the backorder check whenever there's a return linked to the picking, now also checks that there isn't a rental order linked to the picking.

opw-5265874

Forward-Port-Of: odoo/enterprise#101387

When doing a name_search with positive operators (=, ilike, in) the resulting query combines domains with the OR operator. This works fine when the leaves are all on the same table (product_product or product_template) as postgresql uses a Bitmap OR when everything is properly indexed.

When leaves are on multiple tables however postgresql has to plan a Seq Scan. For instance, let's take a simple domain on product.product of the form `['|', ('name', 'ilike', 'test'), ('default_code', 'ilike', 'test')]`. Because `name` is an inherited field via `product_tmpl_id`, the resulting query has the where clause `join_table.name ilike %s OR product_product.default_code ilike %s` with `join_table` the table you get after joining product_product and product_template. Since it's an `OR` condition, postgresql does not know in advance whether a given row will pass this condition. There's no way to filter the tables before the join. The condition moves therefore to a `Join Filter` node and postgresql has to scan the whole join table to fetch the correct tuples.

Same thing when there's a subquery. In case of a where clause `cond OR cond OR subquery`, postgresql does not know in advance whether or not a given row is gonna pass the subquery condition. So it has to scan the whole table.

In both cases this becomes a bottlneck when the number of products increaases. This commit introduces the use of `UNION ALL` instead of `OR`. There's one SubPlan for each individual table in the domain. The results are then appended to get the final products matching the conditions. Thanks to each table having its own SubPlan postgresql can now properly hit indexes for each table, greatly improving the performances.

#### speedup

In a database with 2.5M product_product, the name_search on product with a partner_id in the context and the ilike operator goes from 8s -> 5ms.

In another database with 500k product_template, the name_search on template with a partner_id in the context and the ilike operator goes from 1.8s -> 5ms.

opw-4921944
opw-5103287
opw-5049054
opw-5256691
opw-5221753

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

Forward-Port-Of: odoo/odoo#229275