**Problem:**
when the components of a kit are tracked by lot, and that a picking is made of the components of a kit (exploded from the kit) and separatly one of the components on its own: if we open the picking in barcode, the line of the component separated and line of the components of the kit are grouped, which leads to an unwanted backorder creation when validating

**Steps to reproduce:**
- create two products tracked by lot (comp A and comp B)
- set an on hand quantity for both
- create a storable product (final product) and create a BOM
- in the BOM add comp A and comp B
- create an internal transfer for 1 final product and 1 comp B
- click on "mark as todo"
- open this transfer in barcode, we see that the two lines from the comp B are grouped
- scan the source location, click on +1 and +2 button to fulfill the quantities and validate

**Current behavior:**
a backorder is created

**Expected behavior:**
no backorder should be created as we entered the right quantities of the picking

**Cause of the issue:**
the lines from comp B should not have been grouped in the barcode picking.
When doing the same scenario but with product not tracked those lines are not grouped

opw-4998766

Forward-Port-Of: odoo/enterprise#94085
Forward-Port-Of: odoo/enterprise#93262

Issue before this commit:
=========================
When confirming a sale quotation in a 1-step delivery route, the product's monthly demand in the vendor’s product catalog  in purchase RFQs was updated correctly for the scheduled sale order. However, in 2-step or 3-step delivery routes, confirming a sale quotation did not correctly update monthly demand for the scheduled sale order. Users may see lower than actual monthly demand in the product catalog, potentially causing confusion when planning purchases in multi-step delivery flows.

Steps to Reproduce:
=========================
-Install `Sales`, `Inventory`, and `Purchase` modules, and enable `multi-step routes` in configuration.
-Set the Outgoing Shipments in the warehouse to 2-step/3-step. 
-Create a product and assign a vendor in the Purchase tab.
-Create a sale quotation for the product and Confirm it. 
-Go to Purchase → Create RFQ for the vendor and open the Catalog
 `Observation`: Monthly demand of product is not updated for the confirmed sale
-Go to the Sale Order, open the delivery, and validate the intermediate transfer
 `Observation`: The monthly demand is now correctly calculated for the confirmed sale order.

Cause of the issue:
=========================
-In this [PR](https://github.com/odoo/odoo/pull/215363), the `move domain` was updated to include reserved moves (not only done moves) in monthly demand calculations. However, the method `_get_monthly_demand_moves_location_domain` only returns moves where `location_dest_usage` is `customer` or `production`.
-In 2-step or 3-step delivery routes, the final transfer move is only created after the intermediate transfer moves are validated. These intermediate transfer moves have `location_dest_usage` = `internal` and are therefore excluded from the domain.
-As a result, the product’s monthly demand is not fully reflected for confirmed sale quotations in multi-step delivery flows.

With This Commit:
=========================
-The method `_get_monthly_demand_moves_location_domain` is extended to also return moves whose `location_final_id.usage = customer` and `move_dest_ids = False`
-`location_final_id.usage = customer` ensures that only moves that eventually reach the customer location are counted as monthly demand,
-`move_dest_ids = False` ensures moves without subsequent transfers are counted. Without this, intermediate internal transfer moves would also be counted once the final move is created, which would incorrectly inflate the demand.
-These conditions ensure that intermediate moves in multi-step deliveries are correctly included in monthly demand calculations, while avoiding duplication once subsequent transfers exist.

Description of the issue/feature this PR addresses:

This commit fixes the issue where the pickup location does not get set even though it is present on the checkout page. This happens when the user directly adds an item to cart without specifying the pick up location before adding to cart. This results in the location not being set but at the checkout page, the default pick up location appears as one of the warehouses given the way the default pickup location is set when loading the checkout page values.

This makes the user think that the pickup location is set, but when they try to go to the pay page, an error is thrown saying the pick up location was not specified. This commit sets the pickup location data in such a case.

[This commit] refactored the way in which the default location would be set on the checkout page but did not take into account the possbility that the customer might not select the pickup location when they are adding to cart, thus only rendering the value at the checkout page but not actually setting it.

Refactored the test cases to avoid the redundancy in the setup process.

Steps to reproduce on runbot:
1. Set the pick up in store as the default delivery method by updating the sequence
2. Go the shop on the website and add any item to cart which has stock in the specified pickup location, but don't select the pickup location here
3. Go to the cart and click checkout
4. The default pickup location will be set here
5. Click on Confirm
6. An error will appear saying the location was not set

opw-4954187

[This commit]: https://github.com/odoo/odoo/commit/1d3942c75e59ac9538d112df43b4e39f2462fee4

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

Forward-Port-Of: odoo/odoo#228345
Forward-Port-Of: odoo/odoo#227826

## Issue:
For employees with flexible working hours, when a Public Holiday is added, the timesheet was filled with 8h based on the company’s default calendar instead of the employee’s flexible schedule

## Cause:
When creating `resource.calendar.leaves`, timesheets call `_work_time_per_day()`
This method uses `work_hours_data` containing half-day intervals (tmp_start/tmp_end)
These data come from `_attendance_intervals_batch()`, but we were passing an empty resource, so the check for `flexible_hours` failed:
https://github.com/odoo/odoo/blob/bd7d5fdf8df3a4d544de3e2493cd4b3966fa7d0b/addons/resource/models/resource_calendar.py#L382-L393
We want to use the calendar itself as the calendar resource to get the `work_hours_data`

## Steps to reproduce:
- On an employee, in Work Information, set the Working Hours to Flexible 40 hours/week
- Modify Flexible 40 hours/week (Hours per Week: 30, Average Hour per Day: 6)
- In Time Off > Configuration > Public Holidays, add a New holiday (You can leave default values)
- Go in Timesheets > All Timesheets, before the fix, the flexible employee have 8h in internal for Time Off

opw-4881758

Forward-Port-Of: odoo/odoo#228315
Forward-Port-Of: odoo/odoo#225876

The system will crash with error when try to create a analytic item.

**Steps to Produce:-**
1. Install the `Accounting` module with demo data.
2. Go to `Settings > enable Analytic Accounting`.
3. Navigate to `Accounting > Customers > Invoices`.
4. Create a new invoice with total amount = 0 and confirm it.
5. Go to Accounting > Accounting > Transactions > Analytic Items.
6. Create a new Analytic Item and:
   - Set a value in the `Project` field.
   - Under the `Accounting` section, select the `Journal Item` linked to the last created 0-amount invoice and save.

**Error:-**
`ZeroDivisionError: float division by zero`

**Cause:-**
- At [1], when `line.balance` is 0.0 (for example, when a journal item is defined with a total of 0.0), the system raises an error.

**Solution:-**
- Added a condition to compute only when line.balance exists; otherwise,set the value to 100.

[1]: https://github.com/odoo/odoo/blob/dff2423ac320fdb97d6bf1f106dc84be1d71cac2/addons/account/models/account_move_line.py#L3248-L3251

**sentry-6844926153**

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

Forward-Port-Of: odoo/odoo#226148
Forward-Port-Of: odoo/odoo#225068

After upgrading Odoo from earlier versions to versions >= Odoo 15.5, you
will notice that some fields that were translated before, are now in
English. This is likely because those translations were not marked as
`state='translated'` in the DB. However, the missing translations were
removed from the `_ir_translation` table during the upgrade.

With this patch, we still keep the conservative behavior of only
auto-translating fields marked as `state='translated'` in the DB (which
is still probably wrong, because user translations should remain the
same; if Odoo was displaying translated text before the upgrade and it
is not after it, that's probably a bug; but that's another story...),
but we no longer delete the other fields. This way, you can still mark
them as translated after the upgrade and use the new tooling provided in
https://github.com/odoo/upgrade-util/commit/fd578e31973596bf7f283ea5c6ebbdfd3314f8bc
to recover those translations after the upgrade.

@moduon MT-11570

cc @aj-fuentes

Forward-Port-Of: odoo/odoo#228404