This PR addresses multiple issues related to flexible working hours across several Odoo modules, including attendance, overtime calculation, time off (leave) management, and work entry generation. The primary change modifies the _attendance_intervals_batch method in the `resource` module to create daily attendance blocks for flexible calendars, using the average daily hours and the required weekly hours.

Attendance Intervals for Flexible Hours:

Old Behavior: For flexible employees, a single interval spanned the entire requested period, leading to inaccurate calculations.
New Behavior: For flexible calendars (not fully flexible), daily attendance blocks are created, centered around 12:00 PM, with each block’s duration equal to the average daily hours (hours_per_day). Fully flexible employees (no calendar) retain a single interval covering the full period.

A flexible employee’s attendance was one continuous block over the entire period.

+---------------------------+
|        Attendance         |
|   (e.g., Mon to Fri)     |
+---------------------------+

New Behavior (Daily Blocks):

For a flexible calendar with 8 hours/day, attendance is split into daily blocks centered at 12:00 PM (e.g., 8:00 AM - 4:00 PM).

+-----+ +-----+ +-----+
|  8h | |  8h | |  8h |
| Mon | | Tue | | Wed |
+-----+ +-----+ +-----+

Overtime Calculation:

Updated hr_attendance.py to skip overtime computation for fully flexible employees (is_fully_flexible). For flexible calendars, overtime is now based on the new daily attendance blocks.

Time Off:

In hr_leave.py, flexible calendars now center leave intervals around 12:00 PM for each day, matching the attendance blocks. For half-day leaves, the duration is halved.
Single-day leaves use specified hours, while multi-day leaves align with the virtual schedule.

Work Entry Generation:

In hr_contract.py, work entries for flexible calendars distinguish between one-day and multi-day leaves. Multi-day leaves align with the daily attendance blocks, while one-day leaves use exact hours.
Updated hr_work_entry.py to skip marking leaves outside the schedule for flexible hours, as their virtual schedule is dynamically generated.

Timesheet:

In hr_holidays.py, timesheet generation for flexible employees uses the new attendance intervals or exact hours for hourly/half-day leaves.


task-4771288

Forward-Port-Of: odoo/odoo#212803
Forward-Port-Of: odoo/odoo#209570

### Steps to reproduce:

- Create a storable product P with 10 units in stock.
- Inventory > Configuration > Warehouse Management > Operation Types
- Change the reservation Method of Delivery orders to Manual
- Create confirm and manually assign a delivery order for 3 units of P
- Process the DO in the barcode app, scan 1 unit of P
> The line should be 1/3
- Leave and come back
#### > The line is now at 1/1

Cause of the issue:

Leaving the barcode app launch a call of the `split_uncompleted_moves` in order to keep track of the initial reservation in the barcode app: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L9-L11 
However, one of the issue of the current system is that these new moves are expected to be assigned by the `_action_confirm`: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L37
But they are not in certain cases and we should therefore force re-assignation in that case:
https://github.com/odoo/odoo/blob/bf0461552effe806fdaa8f85f088be3c3f3be09d/addons/stock/models/stock_move.py#L1427-L1432

Enterprise: https://github.com/odoo/enterprise/pull/86394

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

Forward-Port-Of: odoo/odoo#213041
Forward-Port-Of: odoo/odoo#211616

Steps to reproduce:
1. install website, add a link into an editing area in Todo app
2. at the url input, we don't have the internal link suggestion (fuzzy search)
when typing

The PR target to 18.0 because fuzzy page search is considered as a basic
function when website is installed. It's a functional fix for the html_editor

In this PR, we've updated the linkpopover component of the html_editor
to add a fuzzy page search feature to the URL input. Before 18.0, we
created another OWL app to load the page anchors. Here we do it by using
autocomplete component, users can now see and select from a dropdown of
relevant Odoo page anchors as they type in the URL input field.

To achieve this, we modified the popover template to include an
autocomplete field specifically designed for the link popover. In the
AutoCompleteInLinkpopover component, two new props were introduced:

1. inputClass: Allows customization of the input field's styling.
2. updateValue: Enables updating of the link popover's URL state when an
option is selected from the autocomplete dropdown.

We also remove the redundant linkpreview reload when clicking on apply,
cause the loadAsyncLinkPreview is already called at onMounted.

A unit test using hoot is added for testing the fuzzy page search in the
linkpopover.

task-4222657


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

Forward-Port-Of: odoo/odoo#213057
Forward-Port-Of: odoo/odoo#187091

**Issue**
The "Terms and Conditions" section in the invoice report only takes up half of the page, leaving unnecessary blank space on the other half.

**Steps to Reproduce:**
1. Install the Accounting app.
2. Navigate to Accounting > Customers > Invoices.
3. Create or open an invoice.
4. Add a multiline text in the "Terms and Conditions" field.
5. Confirm and print the invoice report.
6. Observe that the content only fills half the available width.

**Expected Behavior:**
The "Terms and Conditions" text should utilize the full width of the report layout if needed, especially for multiline entries.

**Actual Behavior:**
The text is constrained to half the page, reducing readability and leaving unused space.

**Root Cause**

The issue was introduced by PR #193399, which added the `overflow-auto` class to address a display bug from ticket 4416845. However, this class was applied too broadly, affecting the layout of the "Terms and Conditions" block.

**Fix**
To address this issue, a class is added specifically to the terms and conditions div to control its display.

opw-4698250

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

Forward-Port-Of: odoo/odoo#204801

Steps to Reproduce :
1. Activate the developer mode
2. Create a menu from the Site ---> Menu Editor option
3. Go to Configurations ---> Redirects ​
   3.1. Select Action as : '301 Moved Permanently' ​
   3.2. URL From : '/<url_added_at_time_Menu_creation' ​
   3.3. URL To : '#'
4. Go to the Home page
5. Click on the Menu created
6. Traceback Occurs

Expected Behavior:
The page should not crash even when the paths of  'url_from' and 'url_to' are the same.

Reason:
When the paths of 'url_to' and 'url_from' are the same  and the value of 'url_to' starts with '?' or '#' , the redirection loop is created and the page is crashed.

This commit is resolving page crash issue by checking the path of
'url_to' and 'url_from' in '_serve_fallback' method, where redirection
is happening. If path is same, then we will not redirect; instead, we
will return from this method. If 'url_to' starts with '#' or '?',
In this case, we are showing validation error to the user.

task-3984211

Forward-Port-Of: odoo/odoo#175992

Problem: Given that the fields for the salary rules has already been generated for the current country set on the salary structure, an error occurs when accessing the payroll reporting records after the user changes the country because the payroll reporting records will reference a different field name. The outdated fields will not properly unlink, new fields won't be generated based on the new country set, but the payroll report will reference the new field name.

Purpose: When changing the country on a salary structure, the rules that appears on the payroll reporting needs to unlink outdated fields and regenerate the fields based on the new country value. The salary rule fields are dependent on the country due to its naming convention.

Steps to Reproduce on Runbot:
1. Install Payroll
2. Create a new salary structure with no country
3. Create a new salary rule and enable "View in Payroll reporting"
4. Check fields and observe that a field prefixed by 'x_l10n_xx' was created
5. Change the country set on the salary structure
6. Try to access a payroll report record and a traceback is thrown

opw-4649030

Forward-Port-Of: odoo/enterprise#87464
Forward-Port-Of: odoo/enterprise#83749

Currently, the VAT is split into two columns only if the VAT code
consists solely of numeric values. However, in practice, VAT code
may contain a combination of letters and numbers.

**Steps to reproduce :**

1) Install `l10n_de_reports` and switch to the `DE` company 
2) Create a partner with VAT as `NL000099998B57` from contacts
3) Now create a confirmed invoice for the above created partner
4) Go to "Accounting / Reporting / Audit Reports / General Ledger"
5) Download "DATEV DATA (ZIP)" and check "EXTF_customer_account.csv"

**Issue:**

Notice that the VAT was not split into country and VAT code for the above created partner.

**Cause:**

Previously, the code only split the VAT into country code and VAT code
if the first two characters were alphabetic and the remainder was numeric.

https://github.com/odoo/enterprise/blob/35944a38d306ea881e08e1d51ca77a3eab3a6e36/l10n_de_reports/models/datev_export_csv.py#L220-L227

This approach is insufficient because many countries have VAT codes that
include both letters and numbers.
For example vat formats for `NL` and `AT`
https://business.gov.nl/finance-and-taxes/vat/numbers-for-vat/
https://ec.europa.eu/taxation_customs/vies/#/faq

So by only checking whether the VAT code is numberic is not a valid thing.

**Solution:**

The code now uses the partner’s `_split_vat` method to separate the country code
and VAT code whenever a VAT is provided and has more than two characters.
It then validates the split VAT using the `simple_vat_check` helper method.

If the VAT is valid, the country code (in uppercase) and the VAT code are output
in separate columns; otherwise, the original VAT value is kept.

This change ensures that VAT numbers with alphanumeric codes are correctly
handled and split into their respective columns.


opw-4820929

Forward-Port-Of: odoo/enterprise#87167
Forward-Port-Of: odoo/enterprise#86992

### Steps to reproduce:

- Create a storable product P with 10 units in stock.
- Inventory > Configuration > Warehouse Management > Operation Types
- Change the reservation Method of Delivery orders to Manual
- Create confirm and manually assign a delivery order for 3 units of P
- Process the DO in the barcode app, scan 1 unit of P
> The line should be 1/3
- Leave and come back
#### > The line is now at 1/1

### Cause of the issue:

Leaving the barcode app launch a call of the `split_uncompleted_moves` in order to keep track of the initial reservation in the barcode app: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L9-L11 However, one of the issue of the current system is that these new moves are expected to be assigned by the `_action_confirm`: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L37 But they are not in certain cases and we should therefore force re-assignation in that case:
https://github.com/odoo/odoo/blob/bf0461552effe806fdaa8f85f088be3c3f3be09d/addons/stock/models/stock_move.py#L1427-L1432

Community: https://github.com/odoo/odoo/pull/211616

opw-4798349

Forward-Port-Of: odoo/enterprise#87242
Forward-Port-Of: odoo/enterprise#86394

…Inter-Company sync

### Steps to reproduce:

- With Company B in the settings Enable Inter-Company Transactions
   > Synchronize Sales and Purchase Order
- Sales > Configurations > Sales Teams, Archive all sales team
- With COMP A create a sales team with a set company_id: COMP A
- With COMP A create and confirm a PO with COMP B as customer
#### > Invalid operation: while generating the SO, the sales team belongs to COMP A and the SO to COMP B.

### Cause of the issue:

The `team_id` field of the `sale.order` model is a stored pre-computed and company checked field. As such, when the SO is created and even if no sales team is provided to the create vals:
https://github.com/odoo/enterprise/blob/c61ce5a8e46e706bfb2025d4c9c79a39598e8827/sale_purchase_inter_company_rules/models/purchase_order.py#L70 a default sales team will be computed and set on the SO based on the "allowed_company_ids" (including both COMP A and COMP B): https://github.com/odoo/odoo/blob/1fa8678a33ab35195005d1b65b5eecb1d089fe56/addons/sale/models/sale_order.py#L453-L460 https://github.com/odoo/odoo/blob/1fa8678a33ab35195005d1b65b5eecb1d089fe56/addons/sales_team/models/crm_team.py#L81-L88
While the domain checks that the sales team is either not tight to a company or belong to comp B, since no such teams were found, we fallback the invalid sales team of COMP A. The invalid operation is then raised during the `_check_company` of the created record.

opw-4627851

Forward-Port-Of: odoo/enterprise#86528
Forward-Port-Of: odoo/enterprise#83487

**Issue**
In version 18.0, the Customer Statement smart button only appears if the customer has an invoice, unlike in 17.0 where it also appeared if the customer simply had a balance in their ledger

**Steps to Reproduce**
1. Install the Accounting module
2. Go to Accounting > Accounting > Journal Entries
3. Create a new Journal Entry
4. Set one line to account 121000 (Accounts Receivable), assign partner "Administrator", and debit $100
5. Set the other line to account 101401 (Bank), and credit $100
6. Post the journal entry
7. Navigate to Accounting > Customers > Customers
8. Open the "Administrator" customer record
9. Notice that the Customer Statement smart button is not displayed

**Root Cause**
The visibility of the smart button is incorrectly tied to the presence of posted invoices (account.move), instead of the existence of any outstanding balance on the customer account

**Fix**
Adjust the visibility logic to show the Customer Statement button if the customer has any ledger balance, even without invoices. This restores the behavior present in 17.0

Opw-4787174

Forward-Port-Of: odoo/enterprise#87134
Forward-Port-Of: odoo/enterprise#86446

**Before this commit:**

- Submitting a GSTR-1 return to the GST portal with an empty `hsn` dictionary
caused a schema validation error from the portal:

{"error_msg": "Error in Json structure validation.", "error_cd": "RET191106"}

- This occurred because the generated JSON included the `hsn` key with an
empty dictionary, which is invalid as per government schema requirements.
- The portal expects the `hsn` field to be absent if no data is available, or to
contain valid nested keys and values.

**After this commit:**

- A `ValidationError` is raised when attempting to send a GSTR-1 return with no
HSN data, preventing the generation and submission of an invalid JSON payload.
- This ensures that the `hsn` field is only added to the payload when it contains
at least one section with data.
- Helps avoid unnecessary submission failures and improves user feedback at the
point of action.

task - 4807628

Forward-Port-Of: odoo/enterprise#87326
Forward-Port-Of: odoo/enterprise#86655