### Steps to reproduce:

- In the settings enable: Batch, Wave & Cluster transfers
- Inventory > Configuration > > Warehouse Management > Operation types
- Enable Auto-batches, Batch grouping by partner on Delivery orders
- Create and confirm a delivery for 2 units of a storable product that you do not have in stock.
- Change the quantity of the move to 1 unit
#### > The delivery is not auto-batched

### Expected behavior:

As the delivery becomes ready a batch transfer containing your delivery should be created. This is by the way what happens if you had at least 1 unit in stock when you confirm the deliver.

### Cause of the issue:

The auto-batching is suppose to be applied on assigned pickings via the `_find_auto_batch` method:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock_picking_batch/models/stock_picking.py#L194-L198 That being said a picking is only batchable if it is Ready hence his state is 'assigned'. Now, the issue is that the `_find_auto_batch` is only callable in two places in our workflow:
First at confirmation:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock_picking_batch/models/stock_picking.py#L138-L142 Which will fail in our case but wokrs in the use case where you have at least one unit in stock since the delivery is respectively not "assigned" or "assigned" at this point. And, else, wehn the sate of a move of the delivery is assigned:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock_picking_batch/models/stock_move.py#L30-L38 Now, the only issue with this call is that the picking becomes assigned if a move is partially assigned:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock/models/stock_picking.py#L841-L845 But since the move is not "assigned" but only "partially_vailable" this will not trigger a call of the `_find_auto_batch`.

opw-5441718

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

Forward-Port-Of: odoo/odoo#245542

When pos_event was added, a difference in behavior with the existing registration flow in website_event was missed. When answering an 'identification question' (name, email, phone, company_type) with the 'once per order' enabled, the values should be used and propagated directly on the created event.registration records, with precedence over other answers given to individual questions (not once per order)

STEPS
=====

1. Create a new event with name, email questions, once per order ticked.
2. Go to POS (reload data if needed)
3. Register and answer both questions
4. Continue the pos flow until both registrations are created
5. Go to backend > your event > registrations
6. You can see that even if the answers are propagated in the o2m field registration_answer_ids, which is expected, the attendee's name and attendee's email fields are empty. They should contain the values of step 3.

FIX
===

Align the website_event flow and precedence of OPO questions over
individual answers in pos_event. Now, the first non-null answer of an OPO
question will be used for each of the question_type values listed above,
if any, over answers to individual questions.

Also align the fact that after OPO answers, precedence should be given
to the first non-null answer to a given question type for identification
questions, and not the last as it is currently.

Task-4919080

Forward-Port-Of: odoo/odoo#231502

When a product is part of a group with Reserve Only Full Packagings
enabled, another check occurs in _check_qty. This rounds with a precision
of 1.0 the down rounding method. In the case that the quantity was a
decimal, such as 22.4, this would be rounded to 22. In the next transfer
the quantity would then only be 22 instead of the expected 22.4. This
would also cause any packages to not be added as the quantity and demand
are not equal.

If the uom of the product and package are the same we dont need this
package check. Which also prevents the rounding issue.

This fix insures the _check_qty method does not round in cases it does
not need to. (self == uom_id)

How to reproduce:

    In Settings:
        Enable Units of Measure & Packagings
        Enable Multi-Step Routes
    In Warehouses
        Set Outgoing Shipments to Pick then Deliver (2 steps)
    In Inventory
        Create a new product
        Give the product a category
        Set category Reserve Packagings to Reserve Only Full Packagings
        Set on-hand amount

    Workflow:
    Create a sales order
        Create a new Company
        Add product with decimal quantity (1.3)
        Confirm SO
    Go to the sale order delivery
        Validate
    Go to the next transfer
        Quantity will now be rounded (1.0)

opw-5486932

Steps to reproduce:
- Choose France as the company location, and download "France - Work Entries Time Off" module.
- From Employees > Configuration > Settings > French Time Off Localization, select Paid time Off.
- Create a new employee and a new contract (in running state) for that employee that starts on 01/01/2025.
- While in the contract screen, create a new schedule that has 2 weeks calendar and Europe/Paris timezone.
- From Time Off > Management > Allocations, allocate 1+ paid time off days for the newly created employee that's valid from 01/01/2025.
- From the employee's profile > Time Off, try to take a Monday off.

Issue:
- The user gets a Validation error stating that the "start date" is later than the "end date".

Fix:
- In a 2 weeks calendar, there are 2 lines that are there to separate the first week from the second week (for aesthetic purposes). These lines have "hour_from" and "hour_to" = 0, which are taken into account when calulating the minimum hour to start the day off.
- Add a check to remove lines from calendar that are just there for display purposes.

opw-5387347

Forward-Port-Of: odoo/odoo#246094

Current behaviour:
Users are unable to select certain Starshipit delivery services. Delivery methods are configured in Odoo before address or package data is available. Since Starshipit requires this data to determine availability, it returns an incomplete list during setup.

Expected behaviour:
Users should be able to view and select from the complete list of valid delivery services based on the actual Sales Order details (address, weight, and volume).

Steps to reproduce:
1. Create new delivery method
2. Configure Starshipit API credentials.
3. Attempt to select a service.
4. Observe that not all service is shown from the available options.

Cause of the issue:
Starshipit filters services based on sender, receiver, and package info. Odoo requests the service list during initial configuration without this context, resulting in an incomplete list of methods.

Fix:
Introduce a mechanism in the Sales Order flow to add delivery methods. Send the complete shipment details (addresses, weight) to Starshipit to retrieve the accurate list of services and allow the user to select them.

Forward-Port-Of: odoo/enterprise#103316