If you have 2 invoices and 2 dropship picking linked to 1 Dropship Sale Order, and the two dropship have different SVL cost: The 2nd invoice will have incorrect COGS

https://github.com/user-attachments/assets/79f15933-0449-4081-aff0-daa5709889bf

## To reproduce
- Create Product P-DROP:
    * category: AVCO automated
    * Routes: Buy & Dropship
    * Purchase Vendors: Azure Interior @ $10
- Create Sale Order for 1 unit of P-Drop ⇾ Confirm
- Go to Purchase Order ⇾ ensure unit price is $10 ⇾ Confirm
- Receive products ⇾ ensure **valuation is $10**
- Create Vendor Bill (optional) ⇾ Confirm
- Create Invoice ⇾ Confirm
    * **COGS value is $10**  (ok)
- In Sale Order, set ordered quantity to 2 units
    * New draft PO should have been created
- Go to New Purchase Order ⇾ set price to $20 ⇾ Confirm
- Receive products ⇾ ensure **valuation is $20**
- Create Vendor Bill (optional) ⇾ Confirm
- Create Invoice ⇾ Confirm
    * COGS should be $20, but they are actually **$16.67** (KO)

---

## Test result without fix
```
2025-06-11 11:25:32,230 29041 ERROR oes_test_17 odoo.addons.stock_dropshipping.tests.test_stockvaluation: FAIL: TestStockValuation.test_dropship_cogs_multiple_invoices
Traceback (most recent call last):
  File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/stock_dropshipping/tests/test_stockvaluation.py", line 382, in test_dropship_cogs_multiple_invoices
    self.assertEqual(dropship2_cogs_line.balance, -16)
AssertionError: -13.33 != -16
 ```

OPW-4665635

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

Forward-Port-Of: odoo/odoo#213763

## Issue description:
- When 'qty_producing' is updated, the new move takes the MO date_deadline.
- The MO date_deadline is the minimum date of all the finished moves date_deadline.
- When the SO commitment_date is incremented (+1day), the FNS move date_deadline is updated, but not the BP move one.
- The MO date_deadline stay the same (because BP move is a finished move, and BP.date_deadline < FNS.date_deadline)
- The new FNS move deadline will not be equal to the existing FNS move deadline
- The merge is blocked

## How to reproduce:
- Enable By-Products in setting
- Unarchive MTO route
- Create storable products FNS, CMP and BP
- Set FNS route: Manufacture and MTO
- Create BoM:
  - Producing: 1 of FNS
  - Component: 1 of CMP
  - By-Product: 1 of BP
- Create Sale Order for 1 unit of FNS ⇾ Confirm
- Set Delivery Date to 1 day in the future (date must be incremented)
- Go to MO, set quantity producing to 2
  - => 2 Finished move for FNS exists; the merge was not done due to a discrepancy in 'date_deadline'
- Click "Produce All"
  - !! Singleton Error

## Fix:
On date_deadline change: propagate deadline to sibling FNS moves

OPW-4671555

---

## Test result without fix:
```
2025-06-03 11:54:54,076 37053 ERROR oes_test_17 odoo.addons.sale_mrp.tests.test_sale_mrp_flow: FAIL: TestSaleMrpFlow.test_date_deadline_propagation
Traceback (most recent call last):
  File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/sale_mrp/tests/test_sale_mrp_flow.py", line 2624, in test_date_deadline_propagation
    self.assertEqual(len(fns_move), 1)
AssertionError: 2 != 1
``` 

## Test result without fix and the asserts on finished moves removed (to reach 'button_mark_done'):
```
Traceback (most recent call last):
  File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/sale_mrp/tests/test_sale_mrp_flow.py", line 2622, in test_date_deadline_propagation
    mo.button_mark_done()
  File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/mrp/models/mrp_production.py", line 2014, in button_mark_done
    productions_not_to_backorder._post_inventory(cancel_backorder=True)
  File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/mrp/models/mrp_production.py", line 1723, in _post_inventory
    order._cal_price(moves_to_do_by_order[order.id])
  File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/mrp_account/models/mrp_production.py", line 89, in _cal_price
    finished_move.ensure_one()
  File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/odoo/models.py", line 5899, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: stock.move(8252, 8255)
 ```

---

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

Forward-Port-Of: odoo/odoo#212718

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

Currently a traceback is occurring when the user tries to post a journal entry from journal dashborad.

**Steps to reproduce:**
1) Install `l10n_it_xml_export` and switch to IT company 
2) Create a closing entry for the tax report
3) Open the miscellaneous Operations from Accounting Dashboard 
4) Open the above-created entry by removing the default filter 
5) Post the closing entry, a wizard opens.
6) Validate the values.
7) A traceback appears

**Error:**
```
account.journal' object has no attribute '_get_report_options_from_tax_closing_entry'
```

**Cause:**
When the user tries to post the closing entry from the accounting dashboard, 
its active_model is `account.journal`, and the active_id should be the current id 
of the miscellaneous journal.

This leads to the above traceback, as the method `_get_report_options_from_tax_closing_entry` 
is not available in account.journal.

**Solution:**
To resolve this issue, we can browse the current move from the `ctx['l10n_it_moves_to_post']`, 
since the value of the `l10n_it_moves_to_post` is also self.ids.
Which is the current active id for that closing entry.
https://github.com/odoo/enterprise/blob/3d89d9fe6be8e789278dee9bc706e091ee5a0ec5/l10n_it_xml_export/models/account_move.py#L19

opw-4783958

Forward-Port-Of: odoo/enterprise#86791

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#85006