Issue is really similar to commit 21877c09863222a237fe99334787ac46935dcca4 except here the compensations 
amls are created in _stock_account_prepare_anglo_saxon_in_lines_vals
because of a difference between bill price and product cost

**Steps to reproduce:**
- create storable product with category standard auto
- on the category, set an account in the field 'price difference account'
- set a cost of 10
- set a purchase tax
- confirm a PO for 1 @ 15 and validate receipt
- create bill, set a date, save
- on the Bill set the total tax at 100 (it's bellow 'untaxed amount'
on the bottom right of the bill and should be 2.25 before you
change it, if the tax is 15%)
- confirm the bill 

**Current behavior:**
tax was reset to 2.25

**Expected behavior:**
It should stay 100 as it was manually set

**Cause of the issue:**
The total tax amount is computed based on the tax lines 
in Journal Items
https://github.com/odoo/odoo/blob/2744396733bb3ad60813e9e093d67192c0d38b36/addons/account/models/account_move.py#L1171
So the problem is actually that a recomputation of the balance
of the tax account.move.line (the one with the account "tax paid" in 
journal items) is triggered when we confirm the Bill.

That's because:
 When we confirm the bill, 
_stock_account_prepare_anglo_saxon_in_lines_vals() creates 
two amls : 
- one debiting 5 on the account set in the field 'price difference 
account'
- one crediting 5 in the stock interim received account
(This makes sense and is there to realign with the fact that, on the 
account move linked to the svl, the amount credited from stock 
interim received is rightfully 10 because that's cost of the product 
and it's a standard price product)

When we create those amls from,  the create method 
from account.move.lines calls super() inside a context manager 
calling _sync_dynamic_lines().
https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move_line.py#L1628-L1635
the yield of sync_dynamic_lines() is inside a context manager
calling _sync_tax_lines.
https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move.py#L3250
Therefore, the first half of sync_tax_lines() (untill the yield) is ran 
before the call to super and the rest (from the yield) is ran 
after the call to super. 
Because we added two lines in the account.move, get_changed_lines
will return those 2 new line and because there is a tax_ids on the new lines
round_from_tax will be False.
https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move.py#L3034-L3041
Therefore we won't reach continue.
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move.py#L3055-L3059
And the tax line will be recomputed using 
_prepare_tax_line()
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move.py#L3065

Here is why there is a tax_ids on the new lines : 
The field is precompute so if we don't set a value for 
it, _compute_tax_ids will be ran to compute it.
As the account move on which the lines are added 
is a bill, the tax_ids will the supplier_tax_id of the product.
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move_line.py#L898-L901

**fix**
There is no need for a tax_ids on these lines as they 
are not meant to (and should'nt) impact the taxes.

opw-6014710

Forward-Port-Of: odoo/odoo#263306

Steps to reproduce
1. Install hr_holidays and hr_contract.
2. Take a demo employee currently on a validated time off covering now.
3. Set the employee's running contract Working Schedule to empty (fully flexible).
4. Run the "HR Contract: update state" cron (or otherwise leave the contract in state open / close, or draft + kanban Ready).
5. Open the Employees app or any view rendering that employee's chatter / follower panel.

Issue
A traceback "Expected singleton: resource.calendar()" is raised. If the employee's chatter is open, the failing compute is re-fired on every store refresh and the UI becomes unusable.

For fully flexible contracts, hr.contract has no resource_calendar_id, so _get_calendar_periods appends period tuples with an empty calendar recordset (https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/hr_contract/models/hr_employee.py#L184). _get_first_working_interval then forwarded that empty recordset to _work_intervals_batch, which calls ensure_one() and crashes.

This regressed when _compute_leave_status was switched from a single calendar lookup to per-period iteration in
https://github.com/odoo/odoo/commit/bf73b63eec56a822edec2d9ecfeb231a0fbfbbe8 which did not consider that a period in the chain can come from a contract with no calendar.

Solution
Fall back to the company's calendar when the period's calendar is empty, matching the guard already present from saas-18.4 onwards in https://github.com/odoo/odoo/commit/21f18b1a6fdbf1a01c3dda83acfa66addd01a759.

opw-6168264

Forward-Port-Of: odoo/odoo#261995

Currently when user adds adds quantity in barcode using lots it leads to incorrect sale order quantities.

## Steps to replicate:
- Install Sales and Barcode (no demo data).
- Enable Lots & Serial Numbers in settings.
- Create Test Product with Tracking by Lots.
- Go to Inventory > Products>Lots & Serial Numbers and create 3 lots for the product.
- Update each lot’s on-hand quantity to 10 from the product page.
- Create and confirm a Sales Order for the product (lines: qty 3 and 2 units).
- Open the delivery in the Barcode app:
   - Scan lot 2 > increase qty to 3 using +1 button
   - Scan lot 3 > increase qty to 2 using +1 button
- Validate and go to the sale order.

## Observed Behavior:
The sale order delivered quantities are flipped and a backorder is created even though the quantity for the product is satisfied.

## Root cause:
The issue occurs because when a sales order is confirmed, the system defaults to
 using lot 1 on the delivery receipt. When a user scans lot 2, the `_processBarcode` function is triggered, which calls `_findLine` at [1] to select the appropriate line on the receipt.

As the loop in `_findLine` iterates through `pageLines` with values like: 
```
[{display_name: "Test product", quantity: 3, lot_id: { name: 'lot1' }}, 
{display_name: "Test product", quantity: 2, lot_id: { name: 'lot1' }}]
```

During the first iteration, `foundLine` is set at [2] for the line with quantity 3 . Since the subsequent if condition is not satisfied, the loop hits the continue block at [3].
On the next iteration, the line with quantity 2 causes `foundLine` to be overwritten at [2], and the continue block is executed again at [3].

This results in the line with quantity 2 being selected as the line to update at the end of the function.

When the user manually increases the quantity to 3, the line that originally required quantity 2 is updated and fulfilled.
Later, when lot 3 is scanned, the line that required quantity 3 is selected for update, and manually increasing the quantity to 2 before validating the order leads to a backorder and causes the delivered quantities to be flipped.

[1]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1335-L1337 [2]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1690-L1699 [3]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1727-L1729

## Solution:
Avoid grouping lines from different moves unless using batch transfers. This ensures that backorders are not created when the barcode lines are fulfilled.

opw-5423943

Forward-Port-Of: odoo/enterprise#109032