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

**Issue**
When viewing an invoice in Spanish, the "Outstanding credits" section may overflow or be cut off on the right side.

**Steps to Reproduce**
1. Install the Accounting module.
2. Switch the user language to Spanish.
3. Navigate to Contabilidad > Clientes > Facturas.
4. Open an invoice that has outstanding credits.
5. Set the browser zoom to 125%.
6. Observe that the outstanding credits widget content is truncated or overflows its container.

**Root Cause**
The field `invoice_outstanding_credits_debits_widget` was placed directly in the form without a layout container, causing it to misalign and overflow in cases where translated text or zoom scaling increased its width. The lack of a proper responsive layout prevented it from adapting gracefully.

**Fix**
Wrapped the field inside a `<group>` element with class `oe_subtotal_footer px-4` to ensure it inherits consistent padding and alignment with other form elements. This provides a flexible layout that handles longer text and browser zoom correctly, maintaining readability and visual consistency.

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

Forward-Port-Of: odoo/odoo#211100

**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

When importing a coda statement, in case of globalisation,
Odoo doesn't take into account the different levels of details.
Instead of that, we keep every lines even if one is already
the sum of each detailed lines.

According to https://febelfin.be/media/pages/publicaties/2023/archief-bankstandaarden/0c9e6e5026-1694763197/standard-coda-2.4-fr.pdf

Chapter 3.1

Transaction type are communicate like that:

- 0 -> simple amount without detailed data
- 1 -> amount as totalised by the customer
	- 5 -> detail of 1
- 2 -> amount as totalised by the bank
	- 6 -> detail of 2, simple amount without detailed data
	- 7 -> detail of 2, simple amount with detailed data
		- 9 -> detail of 7

Let's assume this case:

- 1 line with transaction type == 2, amount == 3000
- 1 line with transaction type == 7, amount == 2000
- 1 line with transaction type == 9, amount == 2000
- 1 line with transaction type == 7, amount == 1000
- 1 line with transaction type == 9, amount == 1000

Currently, Odoo will display lines 1, 2 and 4 in case of
split transactions instead of lines 3 and 5.
In case of not split transactions, Odoo sums up the same lines.

With this commit, we keep trace of last line's transaction type to:

- be able to delete it if it has detailed data, in case of split
  transaction
- to sum up only the relevant lines

opw-4619660
opw-4795349

Forward-Port-Of: odoo/enterprise#87392
Forward-Port-Of: odoo/enterprise#85006

### Steps to reproduce:

- Install both mrp and quality_control
- Create 2 products:
    - FP (Final Product)
    - COMP (Component) tracked by SN > put SN1 to SN4 in stock
- Create a BOM for FP using COMP as component, add an operation with an instruction of type "Register Consumed Materials" for SN control per product.
- Create and confirm an MO for 2 units of FP: SN1 and SN2 are reserved
- Click on the wheel icon > Split production > Split in 2
- On the MO-001, SN1 is reserved
- Open the operation in the shopfloor and proceed with the quality check
#### > It is currently refering to SN2 !!
- register SN3
#### > It did not alter the value of the lot referred to on MO-001. It did update the serial number present on MO-002 from SN2 to SN3.

### Cause of the issue:

Confirming the MO will in turn confirm the workorder and create a quality check for the consumed material registration of SN: https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/mrp_workorder.py#L625-L628 https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/mrp_workorder.py#L415-L421 At this point, the create quality check is linked to the MO but also to the first move line (sml1) of the raw move (m1) refering to SN in that MO:
https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/mrp_workorder.py#L495-L503 However, the `move_id`, `move_line_id` and `production_id` are all three stored non computed fields of the `quality.check` model. The issue will then be that when the production is split, MO will be renamed MO-001 the QC will still refer to MO-001, sm1, sml1 but sml1 will be reassigned to the raw move of the new production MO-002. In particular, while the QC is still accessed from MO-001 and still refer to the raw move sm1 of  MO-001, it actually updates the values MO-002 since performing these kind of quality checks actually updates the qty and lots on the move line it is related to:
https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/quality.py#L507-L508 Now, the reason why sml1 is reassigned to the mo to back order rather than staying on sm1 and hence on MO-001 is because the order of stock move line is altered to be reassigned by these lines during the `_split_production`:
https://github.com/odoo/odoo/blob/e4bd46930d1841fcd50bf426f5625e9495213ef7/addons/mrp/models/mrp_production.py#L1890-L1895 Currently, this order puts sml with an existing quality check after stock move lines without QC:
https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/quality_mrp/models/stock_move_line.py#L36-L41 As such, they will end up being assigned with the latest backorder to assign.

### Fix:

Since these kind of QC's are created at confirmation and since the first MO will not be reconfirmed, it is important that the QC created for MO-001 stays linked to that MO. In order to achieve this, move lines associated with a QC should definitely stay assigned to the first MO and the sml should therefore be ordered by these without QC last.

opw-4656240

Forward-Port-Of: odoo/enterprise#84796
Forward-Port-Of: odoo/enterprise#84606

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#87393
Forward-Port-Of: odoo/enterprise#83749

**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