**Description of the issue/feature this PR addresses:**

[FIX] account: prevent access error for branch users

When a user restricted to a branch company opens the accounting dashboard,
they may encounter an AccessError preventing the app from loading.

This occurs because the dashboard logic attempts to read the 
`fiscalyear_lock_date` from the journal's company. In a branch setup, 
this configuration often belongs to the parent company, which the user
typically does not have read access to. The system then blocks the action
and gives an AccessError.

This commit resolves the issue by adding `.sudo()` when reading the 
`fiscalyear_lock_date`. This safely bypasses the record rule restriction, 
allowing the dashboard to fetch the necessary accounting configuration 
without requiring the user to have broad access to the parent company.

**Steps to reproduce:**

- As Mitchell Admin:
  - Settings > Users & Companies > Companies > My Company (San Francisco) > Branches > create a branch
  - Settings > Users & Companies > Users > Marc Demo > Access Rights > change “Companies” and “Default Company” to only the newly created branch
- As Marc Demo:
  - Attempt to access Accounting app > observe Access Error


**Current behavior before PR:**

- Users belonging to only a branch company are unable to access the Accounting dashboard

**Desired behavior after PR is merged:**

- Users belonging to only a branch company are able to access the Accounting dashboard

opw-6369616

Forward-Port-Of: odoo/odoo#277877

**Description of the issue/feature this PR addresses:**

[FIX] account: prevent access error for branch users

When a user restricted to a branch company opens the accounting dashboard,
they may encounter an AccessError preventing the app from loading.

This occurs because the dashboard logic attempts to read the 
`fiscalyear_lock_date` from the journal's company. In a branch setup, 
this configuration often belongs to the parent company, which the user
typically does not have read access to. The system then blocks the action
and gives an AccessError.

This commit resolves the issue by adding `.sudo()` when reading the 
`fiscalyear_lock_date`. This safely bypasses the record rule restriction, 
allowing the dashboard to fetch the necessary accounting configuration 
without requiring the user to have broad access to the parent company.

**Steps to reproduce:**

- As Mitchell Admin:
  - Settings > Users & Companies > Companies > My Company (San Francisco) > Branches > create a branch
  - Settings > Users & Companies > Users > Marc Demo > Access Rights > change “Companies” and “Default Company” to only the newly created branch
- As Marc Demo:
  - Attempt to access Accounting app > observe Access Error


**Current behavior before PR:**

- Users belonging to only a branch company are unable to access the Accounting dashboard

**Desired behavior after PR is merged:**

- Users belonging to only a branch company are able to access the Accounting dashboard

opw-6369616

Forward-Port-Of: odoo/odoo#277877

## Current behavior:
Clicking on the Late activity for Lot/Serial in the notification systray doesn't apply the Late activities filter.

## Expected behavior:
Clicking on the Late activity for Lot/Serial in the notification systray should apply the Late activities filter.

## Steps to reproduce:
1. Install Inventory (stock) module, make sure to enable Lots & Serial Numbers in Inventory > Traceability
2. Create some new Lots / Serial numbers
3. Add some Activities with Due Date before today
4. Observe that the Clock icon on systray will count up, showing the number of activities that are late, for today and for future
5. Click on the Late activities (e.g. 2 Late) should only show the 2 late activities. Instead, no filter is applied, thus showing all the Lots / Serial numbers in the inventory

## Cause of the issue:
Missing filters for Late, Today and Future activities in the stock_lot_views.xml

## Fix:
Added 3 filters for Late, Today and Future activities

opw-6332560

Forward-Port-Of: odoo/odoo#272735

Problem:
When computing inventory valuation or available quantities for a date in the past (using the  context), the system calculates the past quantity by taking the current stock quants and rolling back the stock moves that occurred after the requested date.

However, when the environment context specified an ownership filter (e.g.,  to calculate company-owned valuation), this filter was only being applied to the  domain. The rollback domains for incoming and outgoing  records remained completely open.

As a result, the system would correctly see 0 company-owned current stock, but it would erroneously subtract incoming consigned stock moves from that balance. This resulted in an artificially negative past quantity and a negative inventory valuation for company-owned stock.

Solution:
This commit ensures the  context is applied symmetrically by filtering the rollback moves via the  field. The
time-travel calculation will now only evaluate stock moves that match the queried ownership context.

Steps to reproduce (runbot v19):
- Consignment enabled
- FIFO perpetual product w/ nonzero value
1. Create an inventory adjustment for an internal location, set the owner on the quant
2. Create a delivery for this product, but don't zero out all of the available stock
3. Go to Accounting > Review > Inventory Valuation, and set the At Date to something far in the past, before any move history in the db. The product's current on hand value will appear in ending stock, but negative.

opw-6300582

Forward-Port-Of: odoo/odoo#270409

**Issue:**
When an employee uses a fully fixed duration based working schedule and each half-day attendance has a decimal duration such as 3.36h, a multi-day half-day time off request can compute a decimal duration such as 5.01 days. This is inconsistent with half-day time off types, which should consume time in half-day increments.

**Steps to reproduce:**
- Create an employee with a fully fixed duration-based schedule
- Set morning and afternoon attendances to 3.36 hours for each weekday
- Create a time off type with duration type set to half-day
- Create a time off request for the employee (e.g. Monday to Friday)
- The computed duration is 5.01 days instead of 5 days

**Cause:**
For half-day time off types, `number_of_days` was taken from generic calendar interval computation. https://github.com/odoo/odoo/blob/19c0e59cc37c7671f13cbda1b2d4850a7731eade/addons/hr_holidays/models/hr_leave.py#L585-L593 On duration-based schedules, this computation returns day values rounded at 0.001 precision, so decimal drift (e.g. 5.01) can appear, Since no final rounding to half-day steps was applied, half-day requests could end with non-half-day values.

**Solution:**
Round computed durations for half-day time off types to the nearest half-day increment.

opw-6215768

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

Forward-Port-Of: odoo/odoo#267726

Steps to reproduce the bug:
- Install l10n_ke_edi_oscu_stock
- Run Test_sale_mrp_kit_bom_cogs

Problem:
```self.assertAlmostEqual(stock_out_aml.credit, 1.53, msg="Should not include the value of consumable component")
AssertionError: 3.07 != 1.53 within 7 places (1.5399999999999998 difference) : Should not include the value of consumable component
```
The test delivered 1 whole unit of every component of Kit A regardless of the fractional quantity actually needed to produce a single kit (0.34/0.14/0.2 units for Component A/B/BB respectively). This went unnoticed under the default invoice_policy 'order', since qty_delivered never drives the invoiced quantity in that case.

l10n_ke_edi_oscu_stock forces invoice_policy to 'delivery' for storable products that have no explicit company_id, which is the case for the products created in this test. With invoice_policy 'delivery', _compute_kit_quantities() correctly reads the over-delivered components as enough stock to form 2 complete kits (min ratio 2.94, floored to 2) instead of 1, doubling the invoiced quantity and the resulting COGS (3.07 instead of 1.53).

runbot-243633

Forward-Port-Of: odoo/odoo#277519

Description of the issue/feature this PR addresses:
A cash rounding line resolves its company-dependent profit/loss account against the active company instead of the invoice's own company, which breaks multi-company invoicing whenever the invoice's company differs from the active one.

Current behavior before PR:
- Enable Multi-Companies in the settings.
- Create a second company (Company B).
- Open Accounting > Configuration > Cash Roundings.
- Create a cash rounding with strategy "Add a rounding line" and precision 1.00.
- Make Company A the active company in the company switcher.
- Set the cash rounding's profit and loss accounts to Company A accounts.
- Switch the active company to Company B.
- Set the cash rounding's profit and loss accounts to Company B accounts.
- Make Company A the active company again, keeping both companies active.
- Create a customer invoice for Company B.
- Add one invoice line whose total is not a multiple of the rounding precision.
- Set the invoice's cash rounding to the one above.
> Adding the rounding line raises a cross-company UserError: the company-dependent account is resolved against Company A while the invoice belongs to Company B.

Desired behavior after PR is merged:
The rounding line resolves the company-dependent profit/loss account against the invoice's own company, so the rounding line always uses that company's account and no cross-company error is raised. Covered by the added test TestAccountMoveCashRoundingMultiCompany.




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

Forward-Port-Of: odoo/odoo#273410

_stock_account_anglo_saxon_reconcile_valuation() scans a whole invoice on every call and only reconciles at the end, but
_validate_accounting_entries() calls it once per product. The invoice is therefore re-scanned as many times as there are products.

This can lead to performance issues when the invoices contain thousands of lines.

Steps to reproduce:
  - use anglo-saxon accounting with automated inventory valuation
  - confirm a sale order holding a few thousand distinct products
  - invoice it, then validate its delivery => performance issue

Group the products by their related invoices and reconcile each group in one call.

Delivering 20 products against a 5000 line invoice goes from 63s to 9.7s. On the reported customer database a delivery of 197 products, against an invoice grouping 27 orders and carrying 17822 journal items, goes from 369s to 16s.

Benchmark:
| Invoice Lines | Before | After |
|--------------:|-------:|------:|
| 100 | 1.9s | 0.7s |
| 1 000 | 13.0s | 2.0s |
| 5 000 | 63.3s | 9.7s |

opw-6388781

Forward-Port-Of: odoo/odoo#278046
Forward-Port-Of: odoo/odoo#277114

### Issue before this commit:
When importing an electronic invoice from SDI that is failing with an exception, the resulting account.move record was saved in the "Miscellaneous Operations" journal instead of the correct one (Vendor Bills), even though the move_type itself was correct.

### Steps to reproduce the issue:
Pre steps: you need to have access to https://iap-services-test.odoo.com/odoo
1. Download Accounting and l10n_it
2. Go to Settings > Companies and set the VAT of IT company the same as the one in the xml
3. Go to Settings > Italian Electronic Invoicing and select Test
4. Go into the code and insert an Exception inside the function _l10n_it_edi_import_invoice after self.move_type = move_type (or create any type of exception from the user interface)
5. Go to IAP service into IT EDI app and see that your company is there as user
6. Click into the record > receive move button > upload your xml > create
7. Go to your DB > Scheduled Actions > filter with IT > IT EDI: Receive invoices from the SdI > Run Manually
8. Go to Journal entries, remove the filter and find your imported bill
9. You can see it was inserted into the Miscellaneous Operations Journal instead of a Vendor Bill Journal

### Cause of the issue:
The move is created inside a savepoint context manager, designed so that even if parsing fails, an empty move with the attachment still remains. The problem is that if the exception is raised, the savepoint rollback undoes everything that follows, but the journal was already determined before the correct move_type was known, leaving the move in the wrong default journal.

### Reason to introduce the fix:
The fix is needed to ensure that, regardless of where parsing fails, the move's journal is correctly set even if an exception occurs so that it is possible to find the move in the correct section even if not imported correctly.

opw-6397712

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