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

Steps to reproduce:
-------------------------
1. Install Salary Configurator module.
2. Create a new user and assign Officer rights in Employees and Recruitment.
3. Login with that user.
4. Create a new application and move it to 'Contract proposal' stage.
5. Click on the 'Generate Offer' button.

Observation:
-------------------------
An Access Error occurs, denying Read access to the `final_yearly_costs` field.

Issue:
-------------------------
In earlier versions, users had an additional access right that allowed them to access contract fields. After the HR modules were refactored, only HR Administrators and Payroll Users retained access to those fields. As a result users with only Officer rights in HR encountered an access error when generating an offer.

Solution:
-------------------------
Use `sudo()` to bypass access restrictions for the `final_yearly_costs` field when generating the offer.

opw-5243280

Forward-Port-Of: odoo/enterprise#102250
Forward-Port-Of: odoo/enterprise#99478

In #92208 the CAF system was improved to find the next starting value in the right sequence if there are multiple in the system. If no CAFs are found, it will reset to the document types starting number.

This worked except in the case where there are multiple CAFs that are currently marked active in a document type. As it tries to access `caf.start_nb` it hits an ensure_one() which throws a traceback whenever you open most account.moves on the DB.

Steps to reproduce:
- Modify the CAF for Doc Type 33 (Electronic Invoices) to have a smaller range than 1 - 999,999 (1 - 5)
- Create Two new CAF files also for Doc Type 33 that start after this value (6 - 10 and 11 - 15 for example).
- Mark the original to be spent via cancelling it and try to open an invoice. It will find both of the new CAFs and try to get the start_nb of the recordset.

In discussion with the PO, when we have multiple CAFs, we should pick by the lowest start number as it will allow for any gaps that might exist be filled.

opw-5414350

Forward-Port-Of: odoo/enterprise#102385

**BUG:** 
Traceback when **suggesting** deleting a BOM step from the shopfoor. 

**STEPS TO REPRODUCE:** 
- Open a shopfloor MO (with PLM installed)
-- Add a suggestion step (MO > cog> Update instructions > Improvement Suggestion > Add a step). 
-- Add a second suggestion step after the first one.
-- Delete the second suggestion step  (MO > cog> Update instructions > Improvement Suggestion > Delete a step).
-- Add a third suggest suggestion step after the second one we just suggested deleting.
-- > Traceback 

**ORIGIN:** 
First, when adding the suggestions:
 - 2 Quality Check (QC) are created on the **new_bom_id** in `add_quality_check_from_tablet.save()` 
 - 2 Quality Point (QP) are also created in  `add_check_in_chain()`, (only in mrp_workorder_plm override) 
- The 2nd new QC is linked to previous QC in `_insert_in_chain`

Secondly, when deleting the 2nd added suggestion (_on the same MO, as suggestions are linked to the new bom_id and wont appear on other MOs until ECO is validated_):
- The QP of the second QC is deleted (but the QC itself is not deleted) here:

https://github.com/odoo/enterprise/blob/f91b0c8c41f40a71cbea3cd4f5ccc6873af3c004/mrp_workorder_plm/wizard/propose_change.py#L72-L74

Finally, when adding a new suggestion after the one we just suggested deleting, in `_add_check_in_chain`, a traceback happens by trying to access the QP point we deleted in the resequencing part of  `_add_check_in_chain` here:
https://github.com/odoo/enterprise/blob/eb716c18944ec50c9c8c74a2888ed5f3032a7b08/mrp_workorder_plm/models/mrp_workorder.py#L62-L63

**FIX:**
We accept that not all QCs must have QPs  `[0]` -> `[:1]` (see note on another approach idea) changing

```diff
- point = check.point_id if check.point_id.operation_id == operation else points.filtered(lambda p: p._get_sync_values() == check.point_id._get_sync_values())[0] 
+ point = check.point_id if check.point_id.operation_id == operation else points.filtered(lambda p: p._get_sync_values() == check.point_id._get_sync_values())[:1] 
```

**NOTES:**
-1 Another fix could have been to delete the QC at the same time as the QP but I did not find any `remove_from_chain` function to safely remove the QC from the chain of QC. Along those lines we could rethink the sequencing / resequencing of QC and QP as the logic seems to differ between both. 
-2 Added some comments to remove the field and the line setting the `is_deleted` field in master as it was not used anywhere in the code (the color highlighting in the ECO is done with `<list decoration-danger="change_type=='remove'" ...>`)

Upgrade PR: https://github.com/odoo/upgrade/pull/9076
ticket #5180122

Forward-Port-Of: odoo/enterprise#101366

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#101752
Forward-Port-Of: odoo/enterprise#93101