Description of the issue/feature this PR addresses: 
Nilvera requires official codes on company contacts for submission to be compliant.

Current behavior before PR:
Invoices may be sent to Nilvera without the required codes, resulting in non-compliance. Currently, only the VKN and TCKN codes are sent, while other required codes are not supported.

Desired behavior after PR is merged: 
Official codes are added as non-deletable tags (non-mandatory ones archived). An error is raised when required tags are missing or empty. Invoices cannot be sent to Nilvera without valid codes. Codes are always reflected in both PDF and XML.

[IMP] l10n_tr_nilvera: support for official information codes

Added codes as tags from the official list and archived non-mandatory ones. These tags cannot be deleted, and an error is shown on attempt. Invoices are blocked from being sent to Nilvera if either MERSISNO or TICARETSICILNO is missing, or if assigned but without a value. Codes are reflected in both PDF and XML. 

task-4992049 

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

Forward-Port-Of: odoo/odoo#223182

…ay change

**Steps to reproduce**
- Create a public holiday without a calendar during a work day.
- Create a leave for an employee overlapping the public holiday
for a time off type generating Timesheets. Validate it.
- Expected: on the day of the public holiday, no timesheet is
generated for the `hr.leave` to avoid duplication.
- Either delete the public holiday, or set a calendar on it
different than the one defined on the employee.

- Issue: the public holiday timesheet has been deleted, but its
deletion should've lead to the creation of the `hr.leave` timesheet
that we didn't create at the time the public holiday existed.

- Second issue: after that, change the calendar of the public holiday
to the same as the employee's. Still a missing timesheet.

**Solution**
We can use `_reevaluate_leaves` to find the leaves affected by changes
in public holidays.
`_generate_timesheets` then re-generates the timesheets as if the leave
was just validated (the call to `list_work_time_per_day` ignores the
already present resource.calendar.leave).
We also check missing public holidays timesheets to fix the second issue.

opw-4819697

Forward-Port-Of: odoo/odoo#216901

The system failed to evaluate the embedded action, which refers to the Uninstalled module.

Steps to produce:
1. Install `Project` and `Timesheets`.
2. Go to Project and open any project.
3. Click on the embedded action icon and select `Timesheets`.
4. Save the view from the embedded action's icon.
5. Now, Uninstall `Timesheets`.
6. Now, go to that Project and try to open it.

Error:-
`KeyError: 'allow_timesheets'`
`ValueError: Invalid field in filter of project.project:
 [('allow_timesheets', '=', True)]`

Solution:-
- Here,
https://github.com/odoo/odoo/blob/e7efc2c3ad70aa9273412b089a71a9ade75ad525/odoo/addons/base/models/ir_embedded_actions.py#L19

- Also, use `ondelete="cascade"`. but `ondelete="cascade"` not works on `ir.actions.actions`.
https://github.com/odoo/odoo/blob/e7efc2c3ad70aa9273412b089a71a9ade75ad525/odoo/addons/base/models/ir_actions.py#L117-L127

We should remove `ondelete="cascade"` from the `action_id` field and add explicit unlink logic for `ir.embedded.actions`in the unlink method.

Sentry - 6495174314

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

The system gives an error if we set the filter in the relation of lead_properties.

Steps to Produce:
1. Install the `CRM` module.
2. CRM > Configuration > Settings.
3. Enable the `Rule-Based Assignment` and save the changes.
4. CRM > Reporting > Leads, then go to list view.
5. Click on NEW and add the required values.
6. From the gear icon, click on Add properties, set a random value, and then save.
7. CRM > Sales > Teams.
8. Click on the 3 dots of any team and click on Configuration.
9. Add the new salesperson and set the Lead Assignment Filter like Properties > Property 1(name of the property you added in lead form view) - is equal - demo (values of that property that you gave previously) and then save.
10. Click the gear icon and select the CRM: Lead Assignment.

Error:
`AttributeError: ' dict ' object has no attribute '_fields'`

Solution:
The code filters records based on complex domain conditions and combines matching IDs using logical operators. It also supports special fields like properties.

Sentry - 6544761414

*{quality_control,stock}_picking_batch

### Steps to reproduce:

- Got to Quality > Quality control > Control Point
- Create a quality control point:
  - Operation: receipt
  - Control per quantity or product
- Create a and confirm a receipt transfer with 2 products
- Go to the receipt list view > select your receipt > Wheel action > Add to wave > Add to a new wave > Add only one of the move line to the wave
#### > A new picking is created and the move line reassigned to it but the related quality check picking_id is not updated. 
> In particular, there is no "quality check" button on the new picking and the "quality check" button of the first picking allows you to process a QC related to the wave transfer.

### Cause of the issue:

While the move lines or move are can be moved to a new picking during the `_add_to_wave` call:
https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/stock_picking_batch/models/stock_move_line.py#L69-L90 Nothing is done with respect to the quality check which pciking_id field is not computed:
https://github.com/odoo/enterprise/blob/d73f7ef6fe61ccddbe1fe4e32c1670611ba3c5d2/quality/models/quality.py#L185

### Fix:

While the quality check measured on move_line are linked to a move line, the quality checks measured on products and operation are not. For the first kind, we rely on an override of the write method of stock move lines to reassign the check to the apporpiate picking. For the other kinds, we add a post batch hook to unlink the obsolete checks and recreate the appropiate one. Note that since operation and product types are created during the action confirm of moves and since certain moves will be created and auto confirm during the new picking creation here: https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock_picking_batch/models/stock_move_line.py#L90 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L857 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L1263-L1267 https://github.com/odoo/enterprise/blob/b99d7073a34b24d4d3b863278e68f292fdd3c0b0/quality_control/models/stock_move.py#L12-L15 we rely on the `extra_move_mode` to avoid quality check creation during this step (as they will be created in the hook).

Enterprise: https://github.com/odoo/enterprise/pull/92951

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

Forward-Port-Of: odoo/odoo#223852

Currently, an error occurs when a combo product is added to a sales order, and one of its combo items is replaced with another combo product, then the original parent combo product is deleted.

Steps to reproduce:
- Create a sales order and add a combo product to it.
- Modify one of the combo items by replacing it with another combo product.
- Delete the original parent combo product from the order lines and save.

Error:
`ValueError: Expected singleton: sale.order.line()`

The error occurs because the parent combo item is deleted, which causes `line.virtual_id` to become False. As a result, the filter [1] returns no matching records, and ensure_one() fails by raising a singleton error due to receiving zero records.

This happens because the function [2] called from onchange in `sales_order` [3] that performs all the changes only checks the first level of combo items and doesn’t handle cases where those items are also combo products with their own linked items.

This commit fixes the error by properly deleting all nested combo items in the sales order, ensuring no leftover items from nested combos remain that could cause errors.

[1] - https://github.com/odoo/odoo/blob/7bb84621b773cdd7e9984222d61d70d622f8ac43/addons/sale/models/sale_order_line.py#L1567-L1569
[2] - https://github.com/odoo/odoo/blob/57b4056798b9a380027fd3da1c4f3965249a4509/addons/sale/models/sale_order_line.py#L1572-L1591
[3] - https://github.com/odoo/odoo/blob/7bb84621b773cdd7e9984222d61d70d622f8ac43/addons/sale/models/sale_order.py#L922

sentry-6653847384

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

Currently, an error is encountered while editing a Reordering Rule which is already related to some confirmed MO.

**Setup:**
- Install mrp and sale_management.
- Create a storable product with the Manufacture route enabled and its on-hand quantity set to 0.
- Create a Bill of Materials (BoM) for the product and also add at least 1 component.
- Create a Reordering Rule for the product with Min Quantity 0 and Max Quantity 0.

**steps to reproduce:**
- Create and confirm a Sales Order for 40 units of the product. This generates a Manufacturing Order (MO).
- Navigate to the generated MO and add a line for Work Order(set Expected Duration: 1000min).
- Edit the product's Reordering Rule (e.g., change the min Quantity).

for steps reference you can use [this video](https://drive.google.com/file/d/120srSySVHI0FzaWCruz0LVIBKCjK4oOL/view?usp=sharing)

**Error:**
`KeyError: 1`

**Root Cause:**
- The KeyError is triggered when a reordering rule is edited. At this moment, the system calls the `_quantity_in_progress` method to update the forecast. This method prepares a results dictionary (res) that only knows about the ID of the record currently being edited (which might be a new, unsaved record with a temporary ID).

- The issue arises in the loop that processes confirmed Manufacturing Orders, at [1], the value of orderpoint.id is still `<NewId origin=2>` and on trying to access it at [1] causing an error

[1]- https://github.com/odoo/odoo/blob/f1e11af050aa4d7be40e5179dc67a74ff81de076/addons/mrp/models/stock_orderpoint.py#L138

**Solution:**
This commit ensures that only valid orderpoint IDs are processed at [1]

Sentry-**6135193468**

**Issue**
When accessing the EC Sales List report via the smart button from the VAT Return page, downloading the XML without explicitly selecting a period omits the <Month> element—even though a month is visibly preselected.

**Steps to Reproduce**
1. Install the Accounting module and Belgium localization.
2. Go to the Accounting dashboard.
3. Open the VAT Return via the "Miscellaneous Operations" section.
4. Click the smart button to access the EC Sales List report.
5. Use the gear icon to export the XML.
6. Observe that the XML <Period> section only includes the <Year>—the <Month> is missing.

**Root Cause**
If no period is explicitly selected, the report uses a period_type of "tax_period". However, this value was not handled when generating the XML, so the logic to include the \<Month> or \<Quarter> elements skipped it. As a result, only the \<Year>, which is always included, was rendered.

**Fix**
Extend the handling of tax_period to derive the period from the company’s tax periodicity settings and adjust the filter accordingly. This ensures that the generated XML always includes the \<Month> or \<Quarter> element, in addition to \<Year>, whenever the report is based on a tax period.

Opw-4702613

Currently, an error occurs when submitting the 'Send Email' form.

Steps to Reproduce:

 - Install the `website` and `web_studio` modules.
 - Go to `website` > `Click on Edit` > `Drag and drop form`.
 - click the form and in actions select the `more models`, and select
   `outgoing mails(mail.mail)` model and `save`.
 - `Submit` the form, and the error appears in the `logs`.

**Error:**
`KeyError: 'website_form_signature'`

**Cause:**
This error occurs when submitting the "Send Email" form from the
 website. By default, the form action is `"Send an E-mail"`, and when 
the user `changes` the form’s model to outgoing mails (mail.mail), 
which also has the action "Send an E-mail," the system checks the 
existing model [1] and retrieves it. Since `shouldRerender` is set to 
false, [2] is not executed, and as a result, the `email_to(hidden field)` 
is not present in the form. And the website_form_signature is added 
from [3], but due to the condition at [4], the code at [3] is not executed. 
When it is accessed at [5], KeyError is raised.

**Fix:**
This commit ensures that when the user changes the model, 
`rerenderXml` is executed so that the `hidden field` is also added.

[1]: https://github.com/odoo/enterprise/blob/359a1c546fc9e4bc113517bf6ea912a70a9ea123/website_studio/static/src/website_form_editor.js#L155-L156

[2]: https://github.com/odoo/enterprise/blob/359a1c546fc9e4bc113517bf6ea912a70a9ea123/website_studio/static/src/website_form_editor.js#L174-L178

[3]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L252

[4]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L236

[5]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/controllers/form.py#L88

sentry-6746753251

*{quality_control,stock}_picking_batch

### Steps to reproduce:

- Got to Quality > Quality control > Control Point
- Create a quality control point:
  - Operation: receipt
  - Control per quantity or product
- Create a and confirm a receipt transfer with 2 products
- Go to the receipt list view > select your receipt > Wheel action > Add to wave > Add to a new wave > Add only one of the move line to the wave
#### > A new picking is created and the move line reassigned to it but the related quality check picking_id is not updated. 
> In particular, there is no "quality check" button on the new picking and the "quality check" button of the first picking allows you to process a QC related to the wave transfer.

### Cause of the issue:

While the move lines or move are can be moved to a new picking during the `_add_to_wave` call:
https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/stock_picking_batch/models/stock_move_line.py#L69-L90 Nothing is done with respect to the quality check which pciking_id field is not computed:
https://github.com/odoo/enterprise/blob/d73f7ef6fe61ccddbe1fe4e32c1670611ba3c5d2/quality/models/quality.py#L185

### Fix:

While the quality check measured on move_line are linked to a move line, the quality checks measured on products and operation are not. For the first kind, we rely on an override of the write method of stock move lines to reassign the check to the apporpiate picking. For the other kinds, we add a post batch hook to unlink the obsolete checks and recreate the appropiate one. Note that since operation and product types are created during the action confirm of moves and since certain moves will be created and auto confirm during the new picking creation here: https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock_picking_batch/models/stock_move_line.py#L90 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L857 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L1263-L1267 https://github.com/odoo/enterprise/blob/b99d7073a34b24d4d3b863278e68f292fdd3c0b0/quality_control/models/stock_move.py#L12-L15 we rely on the `extra_move_mode` to avoid quality check creation during this step (as they will be created in the hook).

Community: https://github.com/odoo/odoo/pull/223852

opw-5009635

Forward-Port-Of: odoo/enterprise#92951

Before this commit, if a blackbox was unplugged and re-plugged, and it was assigned a different serial port by the Raspberry Pi, it would show up as a new device in the database meaning the existing configuration wouldn't work.

After this commit, we handle the blackbox as a special case, and if the name of the device matches exactly with our existing blackbox, we update its identifier instead of creating a new device.

This does require a new device specific check in the controller which is quite ugly. Another approach would have been to make the identifier of the blackbox equal its FDM ID instead of the serial port, but this was not done for the following reasons:
- Changing the identifier format in stable would cause all existing clients' blackboxes to become unconfigured once their IoT box restarts.
- Making the identifier different to the serial port would require a hack in the blackbox driver to change its own identifier and update the devices dictionary, since the serial interface assumes all devices use the port as their identifier.

task-5055027