The grain secondary settlement ("Liquidación Secundaria de Granos" - LSG) is an electronic document that supports grain purchase and sale and consignment transactions between intermediaries, cooperatives, consignees, exporters, brokers and future market operators. This document is emitted by the intermediary of the operation so, in Odoo, if the user is the seller or purchaser of the operation, it will need to register that document in a sale or purchase journal accordingly.
This PR aims to include this document in the list of the available ones to allow the user to select it when registering either a sale or a purchase. 
![image](https://github.com/user-attachments/assets/cd257bb9-8337-46c0-a699-7ed973338ac7)

**Behaviour before this PR:**
When the user creates an invoice in a sale or purchase journal, the document type "331 - SECONDARY GRAIN LIQUIDATION" is not available to select, although it is activated.

**Behaviour after this PR:**
When the user creates an invoice in a sale or purchase journal, the document type "331 -SECONDARY GRAIN LIQUIDATION" is appears in the list of documents (the document type should be activated before)

**Steps to reproduce:**

1. Install l10n_ar
2. Go to "Document Types" menu and activate "331 - SECONDARY GRAIN LIQUIDATION" 
3. Create or use a sale or purchase journal that has "Is AFIP POS?" as False.
4. Create an invoice in that journal and check that the document type with code 331 is not available to select.
 
![image](https://github.com/user-attachments/assets/710ac57c-8f2c-4398-88c7-ef8c3c8581f3)


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

Steps to reproduce:
- Install payroll, l10n_mx_hr_payroll (mexican localisation)
- Install l10n_mx_hr_payroll_account
- Switch to a Mexican Company
- Create a payslip for a mexican employee with amount < 4000
- Compute the sheet for the payslip

Error message appears, this error message is not a descriptive to the
user or not telling what could have gone wrong. This happens because
the mexican pay structure has some salary rules that has to be
computed, one of these rules is `Retirement, assault in elderly and
old age (CEAV) IMSS (Employer)` that has mode of code. This mode means
calling safe_eval on the code raw text of it written in the xml file
on the data folder. This rule aims to find the suitable taxation level
to be applied on the salary. It reads the limits of each level and
check if the `integrated_daily_wage` of the employee falls in this
level and applies that taxation level. There is no upper limit on the
salary, But there is a min level, hence if the integrated_daily_wage
< mdw (minimum daily wage) the function returns None that used as
index in the taxation table leading to an unreadable Exception from
the safe_eval call.

https://github.com/odoo/enterprise/blob/747482f34ca8210d89d81b3363ec5a8fc3a4ff6f/l10n_mx_hr_payroll/data/salary_rules/hr_salary_rule_regular_pay_data.xml#L1111-L1120

opw-4576482

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/c1d64fba1 [REL] 18.0.33 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/c8a291e80 [PERF] table: faster table extend check [Task: 4864420](https://www.odoo.com/odoo/2328/tasks/4864420)
https://github.com/odoo/o-spreadsheet/commit/e7b4ff760 [FIX] Table: avoid triggering an unecessary evaluation [Task: 4862862](https://www.odoo.com/odoo/2328/tasks/4862862)
https://github.com/odoo/o-spreadsheet/commit/3de4362fd [FIX] filter: fix horrible performances with huge data filters [Task: 4658998](https://www.odoo.com/odoo/2328/tasks/4658998)
https://github.com/odoo/o-spreadsheet/commit/d1cc0590d [FIX] Formats: text format should not mark the cell as non-empty [Task: 4856923](https://www.odoo.com/odoo/2328/tasks/4856923)
https://github.com/odoo/o-spreadsheet/commit/c98a9beeb [FIX] pie chart: prevent overlapping shown values [Task: 4639810](https://www.odoo.com/odoo/2328/tasks/4639810)
https://github.com/odoo/o-spreadsheet/commit/0f8b34976 [FIX] base_extractor: properly handle 0 as default value [Task: 4730308](https://www.odoo.com/odoo/2328/tasks/4730308)

Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com>
Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

_____________________________________________________
## Short functional explanation of the error
Using the layout of a template document, containing radio buttons, on a new document
 will unlink radio buttons, making them useless. 

## Reproduction Steps
1. Go to the Sign module, and click on the Templates tab.
2. Click on the "Upload PDF" purple button, and upload a PDF of your choice.
3. On the left side of the screen, there's a panel where we can drag and drop sign 
items. Drag and drop a Radio button. 2 buttons will automatically show, and a 
yellow link will appear between the buttons. This link indicates that, when a user 
opens the document to sign, when clicking on a radio button, the other one will 
automatically be unselected if previously selected.
4. Save and return to the Templates window. 
5. A new row has appeared with the name of the document. On the right side of this 
row, hover the house next to the share button and click on the 3 dots. Then, click 
on Use Layout.
6. Upload a PDF of your choice.
7. When the PDF shows, there's no yellow link between the radio buttons, unlike on 
the template from which the layout was used.


## Causes of the problem
In the file sign/models/sign_document.py, in the method _copy_sign_items_to(self, 
new_document), we copy every sign item from the template to the new document. 
However, the copy method we call doesn't take into consideration the special link 
between radio buttons, replicating the buttons correctly but not the link. This 
link is expressed by the radio set to which the radio buttons belong: indeed, after
 the copy of sign items, each radio button belongs to a different radio set, 
separating them.

 ## Explanation of the fix
The fix consists of a rework of the _copy_sign_items_to method and a brand-new 
method specifically used to copy radio buttons. To keep the link between them, we 
assign all the buttons of the same set on the original documents to the same brand 
new radio set. 
The first button is copied normally: this creates a new radio set. Then, for the 
remaining buttons, we call copy_radio_item, to which we pass the button created 
first to use the information the next buttons will share with it.



______________________________________________________________
opw-4842590


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

### Steps to reproduce:

- Create 2 storable products: Product A, Product B
- Create a control point pass/fail control by quantity on receipt and set both products on it.
- Create and confirm a receipt with 2 moves:
    - 2 x Product A
    - 2 x Product B
- Click on the "Quality Check" button and mark one unit of Product A as failed.
> This should open the QC for product B.
- Close the QC for prodcut B wihtout setting it as failed or passed.
- Click on the "Quality Check" button
#### > Nothing happends

### Expected behavior:

The QC for product B should open.

### Cause of the issue:

When the quality check is marked as failed, the related move is picked: https://github.com/odoo/enterprise/blob/679c81924e05e7544eecfdb960c9ed9611e9cdd5/quality_control/models/quality.py#L438-L451 However, the move for your second porduct is not and hence, its product is not considered to be checkable by the `check_quality` action: https://github.com/odoo/enterprise/blob/679c81924e05e7544eecfdb960c9ed9611e9cdd5/quality_control/models/stock_picking.py#L61-L69
Since these lines were added in c83728f3a7f1504b272f4ef97e4187868338adb3 to not bypass the QC of the unpicked move at validation we should probably only add that filtering condition in that case and continue to consider the unchecked moves as checkable prior to validation.

opw-4765075

Currently, an error occurs when a user tries to access `paid consultation` or `paid seats` if the booking fees are deleted by the user.

**Steps to Reproduce:**
- Install **appointment_account_payment** module without demo data.
- Delete **Booking Fees** product`from `invoicing->customer->products`
- Click on `Paid Seats` or `Paid Consultation` in the Appointment App.

**Error:**
`ValueError: No record found for unique ID appointment_account_payment.default_booking_product. It may have been deleted.`

**Root Cause:**
After deleting the **Booking Fees**, if user tries to open `Paid Seats` or `Paid Consultation`  the system will try to access id of `appointment_account_payment.default_booking_product` at [1] or [2] causing an error.

[1]-
https://github.com/odoo/enterprise/blob/a4f68967a9826fac981c1141ece1791a0baf647a/appointment_account_payment/models/templates/appointment_type.py#L43

[2]-
https://github.com/odoo/enterprise/blob/a4f68967a9826fac981c1141ece1791a0baf647a/appointment_account_payment/models/templates/appointment_type.py#L56

**Solution:**
This commit prevents error by restricting user from deleting the `Booking Product`.

Sentry-6013528364

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