### State of the art:

Control point for the manufacturing operation type are not expected to create QC when they refer to components.

### Steps to reproduce:

- Create a BOM for a final product FP:
    - 1 X COMP (consumable)
- Create a Quality Control Point:
    - Control: Quanity
    - Operations: Manufacturing
    - Product: COMP
- Create and confirm an MO for 1 unit of FP
#### > A QC is created for the component

### Cause of the issue:

Quantity quality checks related to MOs are expected to be created by `_create_quality_checks_for_mo`, which ensures that only moves referring to the production are considered:
https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/quality_mrp/models/stock_move.py#L23-L29
However, each time a `stock.move.line` is created, it triggers the related "quantity" control points if it is not filtered out of the applicable lines:
https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/quality_control/models/stock_move_line.py#L28-L35
The issue is that move lines related to `move_raw_ids` are always considered applicable:
https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/quality_mrp/models/stock_move_line.py#L31-L34
and that the `_create_check` triggers "quantity" control points that directly refer to the `product_id` of the move line:
https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/quality_control/models/stock_move_line.py#L79-L88

Note, however, that `_create_check` ignores control points of move lines related to a raw move if they do not refer to any product_ids, due to `_get_quality_points_all_products` (which is only called to find control points without a set `product_ids`):
https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/quality_mrp/models/stock_move_line.py#L20-L24
This explains why the test `test_04_quality_check_on_quantity` did not trigger the creation of quality checks for components.

### opw-5137594

Forward-Port-Of: odoo/enterprise#97217

Steps to reproduce
-----
- Create a Sendcloud delivery method
- Select a delivery service with "Locker or service point" as "Last mile" (eg  "bpost @ bpack")

> "Use Sendcloud locations" is set to false

Cause
-----
There is a problem with the values retrieved from the Sendcloud API call, more specifically the `available_functionalities` > `last_mile` value.

The Sendcloud API (of both previous and current beta version) specifies the possible values to only be the following
- `home_delivery`
- `mailbox`
- `pobox`
- `service_point`
- null
https://api.sendcloud.dev/docs/sendcloud-public-api/shipping-options/operations/create-a-shipping-option
https://api.sendcloud.dev/docs/sendcloud-public-api/branches/v2/shipping-products/operations/list-shipping-products

However, it seems like they have added some new undocumented values `locker` and `locker_or_service_point`.

To detect whether to use drop-off locations, we do
https://github.com/odoo/enterprise/blob/5b64c63301bc814c7c9d99146af6a86d37563762/website_delivery_sendcloud/models/delivery_sendcloud.py#L51-L53

Where we compare the retrieved value with the string 'Service point'
https://github.com/odoo/enterprise/blob/5b64c63301bc814c7c9d99146af6a86d37563762/website_delivery_sendcloud/models/delivery_sendcloud.py#L13

In our "Locker or service point" case, this does not work because the `in` operator makes a case sensitive comparison.

Solution
-----
Functionally, both lockers and service points work the same. The user should be prompted a map on which they choose where the delivery should be dropped off.

So we can add `Locker` and `Locker or service point` as accepted values and enable the use of sendcloud locations for both.

-----
Ticket:
opw-5217796

Forward-Port-Of: odoo/enterprise#98875

before this commit, when trying to reprint a past order it would not work. Instead it would print the last order no matter what order is selected.

Steps to reproduce:
1. setup an DB with an italian POS
2. make 2 sales with a different product (easier tracking)
3. open the "orders" view
4. try to reprint the ticket of the firt order result: the receipt of the second order is printed

the reason for this is that we were using the printer's built in command "printDuplicateReceipt" which is inteded for printing the very last receipt.

With this commit, we changed the behavior and invoke another printer command. That command is meant to reprint any receipt, based on the provided reference. After this commit, trying to print any past receipt will print that exact receipt.

IMPORTANT NOTE:
In theory, the printer command can reprint any number of receipts. We decide that we will only use it to reprint the one receipt selected by the user. This moves the complexity of parsing date strings and ranges to the command component and therefore will keep the rest of the code cleaner.

opw-5008702
opw-4882480

Forward-Port-Of: odoo/enterprise#96122

Steps to reproduce:
--------------------
1. Install helpdesk_timesheet
2. Create a new team with timesheets enabled
3. Create a new ticket and add a timesheet line with some time (e.g., 20 hours)
4. Open the team’s settings and observe the Timesheets stat button
5. Go to Timesheets > Configuration > Settings
6. Set "Encoding method" to "Days/Half-days"
7. Reopen the team’s settings and observe the Timesheets stat button again

Issue:
------
Incorrect value displayed in the Timesheets stat button.
(e.g., 160 Days instead of 2.5 Days)

Cause:
------
After commit d23ca81, the UoM model was restructured, changing how conversions between hours and days are computed. The field `factor_inv`, previously used in the computation of total_timesheet_time, was removed.

Earlier, `factor_inv` handled this conversion correctly. After its removal, the computation now directly uses factor, which leads to incorrect values when converting to days. https://github.com/odoo/enterprise/blob/92bb923ffe185b7744adeadcc8f2972f9a64effb/helpdesk_timesheet/models/helpdesk_team.py#L32-L36

For ex:
Consider unit_amount = 20 minutes:

**Before**
Case 1: Encoding method = Hours/Minutes
(unit_amount_sum / product_uom.factor) * uom_team.factor
(20 / 1) * 1 = 20 Hours --> CORRECT

Case 2: Encoding method = Days/Half-days
(unit_amount_sum / product_uom.factor) * uom_team.factor
(20 / 1) * 8 = 160 Days --> INCORRECT

**After**
Encoding method = Days/Half-days
(unit_amount_sum * (1.0 if helpdesk_ticket.encode_uom_in_days else product_uom_factor)) / uom_team.factor
(20 * 1) / 8 = 2.5 Days --> CORRECT

Reference: The [UoM’s factor ](https://github.com/odoo/odoo/blob/ca9df34f3a29796596f92e55647f61f95a95af52/addons/uom/data/uom_data.xml#L29-L37)has also been changed.

**NOTE:** 
Before this change, when the user opened the timesheet sublist view in debug mode 
and clicked the View button, it opened the default form view of the `account.analytic.line` 
model instead of the intended timesheet form view. 
This allowed editing of the Unit of Measure (product_uom_id) field also.

To prevent this, the form view reference has been explicitly specified, similar to the one used in the [Project module](https://github.com/odoo/odoo/blob/3f23bd9723d9065f17c1960d185d67a0a809a889/addons/hr_timesheet/views/project_task_views.xml#L41).

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

opw-5184077

Related community PR: https://github.com/odoo/odoo/pull/233803

Opening shop floor from MO smartbutton activates the WC "Overview". Subsequent opening of shopfloor app will also land on WC "Overview". Also removes an 'undefined' part of local storage key.

BEFORE:
Due to an oversight during this fix odoo/enterprise#93553, opening shop floor from MO smartbutton selects the WC from local storage (ie last clicked by user), with a filter for the current MO. (ie. when clicking Shopfloor smartbutton on an MO we can land on the wrong WC)

NOW:
Opening shop floor from MO smartbutton selects the WC "All MO" with a filter for the current MO. If we close shopfloor and come back to the shop floor app we land back on the "All MO" WC, which is the intended behaviour.  

Note:
I did not rewrite tests I did here: https://github.com/odoo/enterprise/pull/93553/files#diff-2aa7dbd54334d280c72d91b7d472077aaae9af017408f1b0d71150bb16a022f4
as the setup is quite different in 18.0 (no access to the required stepUtils and the tour flow is quite different)

task#4629641

Forward-Port-Of: odoo/enterprise#93841