**Steps to reproduce:**
- Install the `l10n_de` module and switch to a `DE Company`.
- Enable `Peppol` in the Invoicing app settings.
- Open the `DE Company` customer record.
- In the `Invoicing` tab, change the Peppol ID code from `Germany VAT` 
  to `Germany Leitweg-ID` and set a code (e.g., `13075957-K000-52`).
- In the `Contacts & Addresses` tab, create an invoice-type contact named `test`.
- Create a new invoice using the `test` contact.
- Send the invoice via Peppol.
- Download the generated `XML` and inspect the `BuyerReference` field.

**Observation:**
The `<cbc:BuyerReference>` field is set to `N/A` instead of the configured `Leitweg-ID`.

**Root Cause:**
At [1], the `BuyerReference` node is populated using `vals['customer']`. 
For invoices addressed to an invoice-type contact, the contact itself 
does not contain the Peppol configuration, which is stored on the 
commercial partner. As a result, the code fails to retrieve the 
customer's `Leitweg-ID` and leaves the `BuyerReference` field empty.

**Fix:**
This commit ensures that the configured Leitweg-ID is correctly added to the 
`BuyerReference` field for child contact.

[1]:
https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_xrechnung.py#L87-L97

opw-6269478

Forward-Port-Of: odoo/odoo#270459
Forward-Port-Of: odoo/odoo#269818

**Steps to reproduce:**
- Install the `l10n_us_account` module and switch to a My US company
- Navigate to Invoicing > Configuration > Journals > Bank
- Click the internal link of the `Bank Account Number`
- Go to the `Bank Information` tab
- Observe that the `Intermediary SWIFT` field is visible
- Remove `United States` from the bank address

**Observation:**
The `Intermediary SWIFT` field becomes `invisible` when the country 
is not set to `United States`.

**Root Cause:**
At [1], the field Intermediary SWIFT( `intermediary_bank_bic`) is defined with 
a condition that makes it invisible when the country is not 'US'.

**Fix:**
This commit ensures that the `Intermediary SWIFT` field remains visible when
the company uses the US fiscal localization package, even if the bank country
is not set to United States.

[1]:
https://github.com/odoo/odoo/blob/1d4715e58613912bfd0ded4fd370c50c131ff164/addons/l10n_us_account/views/res_partner_bank_views.xml#L9

opw-6145872

Forward-Port-Of: odoo/odoo#260989

Steps to reproduce
---
1. Set an employee to work 8 hours per day.
2. Open the timesheet timer in the systray, type a duration like 8:00 and save.
3. Open the My Timesheets grid for that day.

The day is marked as overtime (yellow) even though only 8 hours were logged.

Issue
---
While the entry is open the timer keeps running and, every second, writes the elapsed time into unit_amount down to the second. https://github.com/odoo/enterprise/blob/a3c9295cf28b47f43233ac6a9f4106810842e37a/timesheet_grid/static/src/components/timesheet_timer_inline_form/timesheet_timer_inline_form.js#L89-L102

When the duration is set by hand, the save skips the usual rounding and keeps the value as it is. https://github.com/odoo/enterprise/blob/a3c9295cf28b47f43233ac6a9f4106810842e37a/timesheet_grid/static/src/components/timesheet_timer_inline_form/timesheet_timer_inline_form.js#L120-L132

So the clean 8:00 the user typed gets a few extra seconds from the next timer tick (8h 1s, stored as 8.000277) and is saved with them. The seconds are hidden in the HH:MM display but are enough to push the day above its working hours, so the grid paints it as overtime. This timer form is new in saas-19.2 (c3dac6ccdb5), which is why earlier versions are not affected.

The fix ignores timer ticks once the duration has been set by hand, so the typed value is kept.

opw-6180676
---

Currently, an error occurs when opening the gantt view of work orders.

**Steps to Reproduce:**
 - Install `mrp_workorder` with demo data.
 - Go to `Settings` > `Technical` > `Resource` > `Resources`.
 - Open the `Assembly 1` resource and remove its `working time`.
 - Go to `Manufacturing` > `Operations` > `Work Orders`.
 - Switch to the `Gantt view`.

`KeyError: 22`

when the user opens the Gantt view, the system checks the unavailability of work centers and employees 
based on their resource calendars. While computing unavailable intervals for resources [1], resources 
without a calendar are flexible resources. If no leave interval exists within the specified start and end 
range that matches the domain, the resource is not included in the result [2]. when updating the 
unavailable intervals dictionary [3], the resource is missing. As a result, when it later tries to access 
the unavailable intervals for that resource, it raises an error [4].

This commit prevents the error by safely handling resources that are not present in the unavailable 
intervals dictionary by using an empty list instead.

[1]: https://github.com/odoo/odoo/blob/1f666de440479dd3d30b7b6cf7c42862c5fcb37a/addons/resource/models/resource_resource.py#L186

[2]: https://github.com/odoo/odoo/blob/1f666de440479dd3d30b7b6cf7c42862c5fcb37a/addons/resource/models/resource_calendar.py#L532-L536

[3]:https://github.com/odoo/odoo/blob/1f666de440479dd3d30b7b6cf7c42862c5fcb37a/addons/resource/models/resource_resource.py#L187

[4] https://github.com/odoo/enterprise/blob/47f2e9e88fa0bbb8852fe7734c6bece4dca8b9d0/mrp_workorder/models/mrp_workorder.py#L692-L694

sentry-7525704808

This PR is one of many triggered by responses from Luxembourg auditors. See PR #113316 for a full list of these PRs.

As described in PR #117799, the \CustomerID and \SupplierID elements on \Transaction\Line elements is determined by a partner's `customer_rank` and `supplier_rank`.  This is a binary designation, one or the other.

The Luxembourg FAIA report requires that less than 30% of \Transaction\Line elements with payable accounts (class 6) can not have \SupplierID. The same applies for \Transaction\Line elements with receivable accounts (class 7) and the \CustomerID element.

TSB clarified that any partner on an receivable or payable line should be added to the Customer list or Supplier list respectively https://github.com/odoo/enterprise/pull/100749#issuecomment-3655127511. In addition, I verified that Luxembourg's analysis of four separate FAIA files (from ticket 5427296) aligns with this expectation. 

<img width="1322" height="690" alt="image" src="https://github.com/user-attachments/assets/1a82f99e-5b32-4dbb-96e1-1b25bab2629b" />

This commit adds partners to the \Supplier and \Customer lists if they have any payable or receivable lines, respectively. It also picks between the \CustomerID and \SupplierID based on a line's `account_type`. This logic is applied to `account_saft` and updates the other, country-specific SAFT reports where appropriate. 

It also retains the previous `customer_rank` and `supplier_rank` logic as a fallback for older XML reports and for accounts other than `asset_receivable` or `liability_payable`.

opw-6118024

Forward-Port-Of: odoo/enterprise#120365
Forward-Port-Of: odoo/enterprise#118714

The quantity on hand for a main company with branches is calculated to be the the sum of all its child companies + its own quantities.  `_run_fifo_get_stack()` doesn't include the child companies in the `moves_domain`, so it is unable to create a FIFO stack for moves from a child. This leaves extra quantity unaccounted for, which defaults to the standard_price.

**Video of the bug:**
https://drive.google.com/file/d/11PIfNAIb_Yyo4A-3R0CRF0NV6_HE6EwF/view

**Issue:**
When multiple companies are selected, the displayed quantity on hand for a product is calculated as the sum of all selected companies. However, the moves domain only looks at the main selected company instead of all selected companies, leading to an incorrectly calculated standard price when using FIFO. This is more apparent on lot-valuated products because the lot standard price is recalculated every time the field is accessed.

**Reproduction steps:**
- Have a main company
- Create a branch company
- Create a product, configure it as FIFO on both the main company and branch company 
- Let the product be tracked by lots and set to `Valuation by Lot` (for demonstrative purposes)
- On the main company, set the product cost to $15 (for demonstrative purposes)
- Go to only the branch company, make a purchase for one unit of the FIFO product at $100 (make a warehouse for delivery) , validate the receipt
- Go to the lot -> When logged in to only the branch company, quantity is 1 and cost is $100 (correct). When logged in to both the main and branch company and viewing from the main company, quantity is 1 and cost is $15 (incorrect)

**Fix:** 
Allow `_run_fifo_get_stack()` to see the moves from all companies in the environment instead of just the main company

Related ticket: opw-6064126

Forward-Port-Of: odoo/odoo#269942
Forward-Port-Of: odoo/odoo#258199

Steps to reproduce
------------------
1. Open a PoS session, e.g. at 1h45
2. Wait a bit and make an order, e.g. at 1h55
3. Keep the session open and go to PoS > Reporting > Sale Details.
4. Select a starting date before the ordre and after the session open, e.g. at 1h50
5. Generate the report.

The header shows the starting date of the session, i.e. at 1h45, instead of that of the selected date, i.e. 1h50

Why it's happening
------------------
Commit 5003774bf2a7 changed the way the report decides if the data comes from a single session: now if all the orders in the user selected start and end date belong to one particular session, the start and end date on the report are overriden to be those of that particular session, ignoring the user selected ranges.

The fix
-------
Only overwrite the start and end dates when `session_ids` was passed (i.e. the report is about a specific session).

When called via date range + `config_ids` (from the backend wizard like in our reproduction steps), keep the user-selected range.

opw-6185106

Forward-Port-Of: odoo/odoo#267200

Module: l10n_it_pos

Steps to reproduce:
- In the POS settings, enable "Automatic Receipt Printing";
- Enable "ePos Printer" to make the "Skip Preview Screen" option appear;
- Disable "Skip Preview Screen";
- Disable "ePos Printer";
- Set up an Italian Fiscal Printer;
- Open a POS session and process a first order. Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required.

Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required.

Cause:
When "Automatic Receipt Printing" is true but "Skip Preview Screen" is false, a race condition occurs. `afterOrderValidation` triggers a print job while simultaneously transitioning to the `ReceiptScreen`. When the `ReceiptScreen` mounts, it triggers a second fiscal print job before the first has resolved. This creates a deadlock in `toHtml` of  `renderService`, permanently blocking the printer queue.

Solution:
Since the italian localisation sending the receipt to the fiscal printer is mandatory, the printing route is now tied to the "Skip Preview Screen" option.

Enterprise PR: https://github.com/odoo/enterprise/pull/112654

[opw-5979212](https://www.odoo.com/odoo/project/49/tasks/5979212)

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

Forward-Port-Of: odoo/odoo#270343
Forward-Port-Of: odoo/odoo#256932

Module: l10n_it_pos

Steps to reproduce:
- In the POS settings, enable "Automatic Receipt Printing";
- Enable "ePos Printer" to make the "Skip Preview Screen" option appear;
- Disable "Skip Preview Screen";
- Disable "ePos Printer";
- Set up an Italian Fiscal Printer;
- Open a POS session and process a first order.

Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required.

Cause:
When "Automatic Receipt Printing" is true but "Skip Preview Screen" is false, a race condition occurs. `afterOrderValidation` triggers a print job while simultaneously transitioning to the `ReceiptScreen`. When the `ReceiptScreen` mounts, it triggers a second fiscal print job before the first has resolved. This creates a deadlock in `toHtml` of  `renderService`, permanently blocking the printer queue.

Solution:
Since the italian localisation sending the receipt to the fiscal printer is mandatory, the printing route is now tied to the "Skip Preview Screen" option.
UI settings are adjusted to hide the redundant auto-print checkbox when an IT fiscal printer is configured.

Community PR: https://github.com/odoo/odoo/pull/256932

[opw-5979212](https://www.odoo.com/odoo/project/49/tasks/5979212)

Forward-Port-Of: odoo/enterprise#120747
Forward-Port-Of: odoo/enterprise#112654

The website appointment calendar fills availabilities one month at a time and the update_available_slots route maps the calendar month index to an absolute month from datetime.now(). This only matches the displayed months when the first one is the current month. When the first bookable slot is later, a punctual appointment starting in a future month or any appointment whose "at least X hours before start time" lead time pushes the first slot past the current month, navigating forward requests the wrong month and the reached month renders empty.

In update_available_slots, take the lead time into account when computing the reference month so it lands on the first displayed month: the start datetime for a punctual appointment starting in the future, otherwise now plus the minimum schedule hours. The navigated month index is then added to that reference. This extends https://github.com/odoo/enterprise/commit/f0e5b14a823cf97218f4094d287a328e2744fd73 which only handled the future start datetime.

Steps to reproduce:
1. Open the Appointments app
2. Open an appointment type, set Schedule to Weekly and Allow Bookings to On specific dates with a range ending a few months out
3. Set the "at least N hours before start time" field to 360
4. Save and click the Preview button in the header
5. Pick a resource or staff member to reach the calendar
6. Click the right arrow to navigate to the next month

=> the next month shows "Sorry, we have no more slots available for this month"

opw-6206293

Steps to reproduce:
----------------------------------------
- Have the company calendar work from 9 to 17 on weekdays
- In project gantt view, create tasks with dependencies like this:
```
- [Task 1] (June 08, 09:00 AM - 10:00 AM) ──┐
                                            ├─> [Task 3] (June 11, 09:00 AM - 10:00 AM)
- [Task 2] (June 10, 09:00 AM - 10:00 AM) ──┘
```
- Make sure the "Auto-Reschedule (Keep Buffer)" is selected
- Then reschedule task 1 to `(June 09, 09:00 AM - 10:00 AM)`
- Task 3 is rescheduled to `(June 15, 09:00 AM - 10:00 AM)`

**Expected behavior:**
To respect the buffers, task 3 should have been rescheduled to `(June 12, 09:00 AM - 10:00 AM)`:
- The buffer from task 1 is  23 working hours after `June 09, 10:00 AM` is `June 12, 09:00 AM`
- The buffer from task 2 doesn't affect the rescheduling.

Cause:
----------------------------------------
From `_web_gantt_update_next_candidates_dates()` we call `_get_new_dates()` with `seconds_between_tasks` being the duration of working hours between the end of task 1 and the start of task 3. We also call it with `first_possible_start_date_per_candidate` being the end of task 3 also depends on task 2.

Then `_get_new_dates()` counts the working hours from `first_possible_start_date_per_candidate` until it reaches `seconds_between_tasks`. Which means the buffer between task 1 and task 3 is actually applied between task 2 and task 3.

Solution:
----------------------------------------
The value contained in `first_possible_start_date_per_candidate` is irrelevant, the correct value to give to `_get_new_dates()` would be `compute_end_date` as we want to keep the buffer to be calculated from this datetime.
So we create a fake dictionary with only the task and `compute_end_date` and give it to `_get_new_dates()`.

The same logic applies when moving tasks backwards.

opw-5973597

**Issue**
Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request.

**Steps to reproduce**
- Have two companies A and B and two users u1 and u2
- user u2 only have access to company A
- With user u1:
	- Create two vendors v1 and v2 without any company assigned
	- Create vendor pricelists for a product for each vendor and assign the company A to the pricelist
- Add the company B for the vendor v2
- With user u2:
	- Open approval application
	- Try to create an approval for an RFQ for that product (the vendor v1 will be automatically selected)
	- Save it -> An access error is thrown

**Cause**
Saving the approval request computes `has_no_seller`, which calls `_select_seller`: https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/views/approval_product_line_views.xml#L9 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L32 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L62-L70 Which filtered the right seller
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L759 By preparing the sellers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L721 https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L712 Please note that `self.seller_ids` contains both sellers (even v2) By filtering the suppliers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_supplierinfo.py#L104-L105 But at that point, one of the supplier in `self`, can be accessed, thus an access error is thrown while trying to access its associated `partner_id`.

opw-6203910

**Issue**
Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request.

**Steps to reproduce**
- Have two companies A and B and two users u1 and u2
- user u2 only have access to company A
- With user u1:
	- Create two vendors v1 and v2 without any company assigned
	- Create vendor pricelists for a product for each vendor and assign the company A to the pricelist
- Add the company B for the vendor v2
- With user u2:
	- Open approval application
	- Try to create an approval for an RFQ for that product (the vendor v1 will be automatically selected)
	- Save it -> An access error is thrown

**Cause**
Saving the approval request computes `has_no_seller`, which calls `_select_seller`: https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/views/approval_product_line_views.xml#L9 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L32 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L62-L70 
Which filtered the right seller
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L759 
By preparing the sellers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L721 https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L712 
Please note that `self.seller_ids` contains both sellers (even v2) By filtering the suppliers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_supplierinfo.py#L104-L105 
But at that point, one of the supplier in `self`, can be accessed, thus an access error is thrown while trying to access its associated `partner_id`.

opw-6203910