List of changes:
- Review checks button -> Review
- When we click on the Review Button and all checks are already green, we show a toaster telling that auu checks were successful and forward the state.
- The Bank matching check open the kanban by default now
- Removed Reminder and Journal from the opening wizard
- Renamed Advance Tax Payment to Advance Payment, same for french
- If the deadline is due, we show it in red
- The todo filter, filter returns with a date_to that is less than today.
- Rename the wizard title ISOC Prepaymentr -> Advance Payment
- Add a mark as completed button for advance payment returns
- If the amount to pay is zero, directly forward the state to paid after submission
- Same as above, if the amount is negative (to recover), we directly finalize the payment
- Removed the auto redirect on the checks view when al checks are green
- Added a Reset button for VAT return in paid state
- Limit count on checks: search for maximum 21 records, show 20+ if there is more
- Changed default journal sequence prefix TRTRN -> TAX
- Renamed BE EC Sales list report name in french 'Relevé à la TVA des opérations intracommunautaires' -> 'Relevé Intracommunautaire'
- Fixed tax return view action. Before it was a client action resulting in a lost of the path. The fix is using a server action and manually setting the path.
- Auto Generation of the EC sales list return and Intrastat return by the cron. Before they were created upon submission of the vat export modal.
- Fix Lock Date reset for return type with reports without a country
- Do not auto forward when resolving checks, we wait until the refresh
  of the tax return view.
- Fix a bug showing double Submit button for the Annual closing

Note:
We added back buttons on the report for exportation of the Intrastat report and EC sales list report as they are generated automatically.
We cannot ensure all periods are covered as it does only generate a return for the previous period.
Since then EC sales (or Intrastat) return for older periods might have not been generated and there is currently no way to create them manually.
This will be fixed un 18.4

task-4781427

Forward-Port-Of: odoo/enterprise#85509

…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

Currently, if there is an error while generation print reports the use of the IoT will return the generic error `Failed to send to printer' which does not lead to understand there is a hidden issue to begin with.

Steps to reproduce:
-------------------
1. Set up the iot and like the product labels report to a zebra printer
2. Modify the view of the product labels (`label_product_product_view`) to ensure there is an error during rendering (mistype a field name)
3. Go to a product and print labels
> Observation: Notification: Failed to send to printer

Why the fix:
------------
In the example given an error occurs when trying to render the label here:
https://github.com/odoo/enterprise/blob/968bf16c65a67791efd5fb94f5c95eaf09a47107/iot/static/src/iot_report_action.js#L50-L57

Technically the error makes it so that we fall into this catch block https://github.com/odoo/enterprise/blob/968bf16c65a67791efd5fb94f5c95eaf09a47107/iot/static/src/iot_report_action.js#L81-L88

We will now make a distinction between the RPC error and generic iot related error. If any error occur while making the RPC call we will now show the traceback. This should help anyone debugging.

opw-4571350

Forward-Port-Of: odoo/enterprise#84589

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

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