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