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

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