The "social reason" tag in the VAT export should be a company name. Forward-Port-Of: odoo/enterprise#50638

The "social reason" tag in the VAT export should be a company name.

Forward-Port-Of: odoo/enterprise#50638

Before this commit, SerializationFailure could happen when the invoice are sent to the customers. It would trigger the following traceback: ```py File "/home/odoo/src/enterprise/saas-16.4/sale_subscription/models/sale_order.py", line 1859, in _process_invoices_to_send subscription.validate_and_send_invoice(invoice) File "/home/odoo/src/enterprise/saas-16.4/sale_subscription/models/sale_order.py", line 1875, in validate_and_send_invoice self.env.cr.commit() File "/home/odoo/s

Before this commit, SerializationFailure could happen when the invoice are sent to the customers. It would trigger the following traceback:

```py
 File "/home/odoo/src/enterprise/saas-16.4/sale_subscription/models/sale_order.py", line 1859, in _process_invoices_to_send
    subscription.validate_and_send_invoice(invoice)
  File "/home/odoo/src/enterprise/saas-16.4/sale_subscription/models/sale_order.py", line 1875, in validate_and_send_invoice
    self.env.cr.commit()
  File "/home/odoo/src/odoo/saas-16.4/odoo/sql_db.py", line 450, in commit
    self.flush()
  File "/home/odoo/src/odoo/saas-16.4/odoo/sql_db.py", line 136, in flush
    self.transaction.flush()
  File "/home/odoo/src/odoo/saas-16.4/odoo/api.py", line 851, in flush
    env_to_flush.flush_all()
  File "/home/odoo/src/odoo/saas-16.4/odoo/api.py", line 713, in flush_all
    self[model_name].flush_model()
  File "/home/odoo/src/odoo/saas-16.4/odoo/models.py", line 5918, in flush_model
    self._flush(fnames)
  File "/home/odoo/src/odoo/saas-16.4/odoo/models.py", line 5991, in _flush
    process(model, id_vals)
  File "/home/odoo/src/odoo/saas-16.4/odoo/models.py", line 5941, in process
    model.browse(ids)._write(vals)
  File "/home/odoo/src/odoo/saas-16.4/odoo/models.py", line 4176, in _write
    cr.execute(query, params + [sub_ids])
  File "/home/odoo/src/odoo/saas-16.4/odoo/sql_db.py", line 321, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.SerializationFailure: could not serialize access due to concurrent update

```

Forward-Port-Of: odoo/enterprise#50612
Forward-Port-Of: odoo/enterprise#50269

When scanning a package on a batch picking, we receive "The operation cannot be completed: Error, a partner cannot follow twice the same object." This happened because the user is defined for all pickings in the batch and the _setUser function calls the rpc method to update the user before configuring the cached data, causing the second (async) iteration to reselect the first picking because the cached data is not yet updated. Forward-Port-Of: odoo/enterprise#50532

When scanning a package on a batch picking, we receive "The operation cannot be completed:
Error, a partner cannot follow twice the same object."

This happened because the user is defined for all pickings in the batch and the _setUser function calls the rpc method to update the user before configuring the cached data,
causing the second (async) iteration to reselect the first picking because the cached data is not yet updated.

Forward-Port-Of: odoo/enterprise#50532

Two many2one to ir.attachment were added on table that can have a lot of record in there respective table. The deletion of ir_attachment need to check the new foreign constraints on those table which can take a lot of time. It can block the autovacuum since _gc_lost_attachments can timeout To speed up the delete, btree indexes neet to be added on many2one that point to ir_attachment Forward-Port-Of: odoo/enterprise#50573

Two many2one to ir.attachment were added on table that can have a lot of record in there respective table.

The deletion of ir_attachment need to check the new foreign constraints on those table which can take a lot of time.

It can block the autovacuum since _gc_lost_attachments can timeout

To speed up the delete, btree indexes neet to be added on many2one that point to ir_attachment

Forward-Port-Of: odoo/enterprise#50573

Problem: The user is unable to export or post closing entries due to a traceback that warnings is of None type. The method, _dynamic_check_lines, tries to assign an item to warnings which is a dict. However, since warnings was not initiliazed, it throws a traceback. Solution: Initialize warnings as an empty dict when it hits the failed_control condition This will unblock the user from exporting the tax report or posting the closing entry for the tax report. Steps to reproduce on Runbot(

Problem:
The user is unable to export or post closing entries due to a traceback that warnings is of None type. The method, _dynamic_check_lines, tries to assign an item to warnings which is a dict.
However, since warnings was not initiliazed, it throws a traceback.

Solution:
Initialize warnings as an empty dict when it hits the failed_control condition This will unblock the user from exporting the tax report or posting the closing entry for the tax report.

Steps to reproduce on Runbot(ALL):
Switch to BE Company CoA
Enable "0% EU S" purchase tax
Create a vendor bill using this tax
Try to post Tax Closing Entry for the period which includes the created vendor bill Receive technical error
OR
Try to export the Tax Report

opw-3560681

Forward-Port-Of: odoo/enterprise#49887

Prior to this commit, there was a white gap on the right side in the frontend view. This was due to a missing class enabling the column size to be set correctly on large screens. To fix that, this commit introduces this missing class. task-3592631 Forward-Port-Of: odoo/enterprise#50511

Prior to this commit, there was a white gap on the right side in the frontend view.
This was due to a missing class enabling the column size to be set correctly on large screens.
To fix that, this commit introduces this missing class.

task-3592631

Forward-Port-Of: odoo/enterprise#50511

This is a legal requirement for Mexico, the PDF must be a printed representation of the CFDI and the fiscal regime is a data that is present on the XML of the payment  opw #3515408 Forward-Port-Of: odoo/enterprise#50619 Forward-Port-Of: odoo/enterprise#47685

This is a legal requirement for Mexico, the PDF must be a printed representation of the CFDI and the fiscal regime is a data that is present on the XML of the payment

![image](https://github.com/odoo/enterprise/assets/6758279/5b13a0fd-78c4-48f1-9481-ad90481ac0c8)

opw  #3515408

Forward-Port-Of: odoo/enterprise#50619
Forward-Port-Of: odoo/enterprise#47685

Before this commit, in helpdesk homepage, the daily target inputs in the 'My Performance' area were reasonably functional in focused state, but in dark mode, they exhibited an undesirable box-shadow/inset effect. This commit addresses the issue by applying a 'form-control' class to the inputs and removing any superfluous classes, thereby enhancing the visual consistency and aesthetic. <table> <tr> <td>Before</td> <td> After</td> <tr> <td> <img alt="before" src="https://github.com/od

Before this commit, in helpdesk homepage, the daily target inputs in the 'My Performance' area were reasonably functional in focused state, but in dark mode, they exhibited an undesirable box-shadow/inset effect. This commit addresses the issue by applying a 'form-control' class to the inputs and removing any superfluous classes, thereby enhancing the visual consistency and aesthetic.

<table>
<tr>
 <td>Before</td>
 <td> After</td>
<tr>
 <td>
 <img alt="before" src="https://github.com/odoo/enterprise/assets/80678921/fef930e2-06d3-4932-ac91-726f6fddd132">
</td>
 <td><img alt="after" src="https://github.com/odoo/enterprise/assets/80678921/16321474-0070-4987-9e35-c4b963f8dc6f">
 </td>
</table>


task-3593349

Forward-Port-Of: odoo/enterprise#50536

The recruitment settings were using the iap_buy_more_credits widget, even tho there is no hard dependency between IAP and Recruitment. The widget has been moved to the enterprise module `hr_recruitment_extract`. Closes odoo/odoo#114747 Forward-Port-Of: odoo/enterprise#49576 Forward-Port-Of: odoo/enterprise#37959

The recruitment settings were using the iap_buy_more_credits widget, even tho there is no hard dependency between IAP and Recruitment.

The widget has been moved to the enterprise module `hr_recruitment_extract`.

Closes odoo/odoo#114747

Forward-Port-Of: odoo/enterprise#49576
Forward-Port-Of: odoo/enterprise#37959

Issue: ====== When you cancel repeat with type `until` for a `planning slot` it will not get saved after saving the form. Steps to reproduce the error: ============================= - Install planning - Go to planning create a new slot from the Gantt (default) view. - Add resource , choose date as a period of 2 days for example (doesn't matter), select repeat, change forever to until and select the date for some day in next month for example and save it. - Click on the created slot and

Issue:
======
When you cancel repeat with type `until` for a `planning slot` it will not get saved after saving the form.

Steps to reproduce the error:
=============================
- Install planning
- Go to planning create a new slot from the Gantt (default) view.
- Add resource , choose date as a period of 2 days for example (doesn't matter), select repeat, change forever to until and select the date for some day in next month for example and save it.
- Click on the created slot and unselect repeat and click save.
- Click again on the slot , it will show that repeat is still selected.

Origin of the issue:
====================
The reason behind this issue is that _compute_repeat_until is called when changing repeat value and thus changing the values of `slot.repeat_until` to False and then in the save `inverse_repeat` is called and it will not match all the conditions in the second if : The condition on `repeat_until` will be False.

Solution:
=========
I removed the `repeat_until` from the conditions to be checked.

opw-3550191

Forward-Port-Of: odoo/enterprise#48969

Step to reproduce: - Order two same combo products in pos_restaurent - Only one product will appear on the kitchen display Previously the _get_order_changes method was computing the orderline changes based on a key composed of the product id, the full product name and the note. This was done considering the fact that the merge orderline was working. Combo products are not handled by the merge orderline. Because of this, if 2 orderlines of combo product were the same, only the last orderline

Step to reproduce:
- Order two same combo products in pos_restaurent
- Only one product will appear on the kitchen display

Previously the _get_order_changes method was computing the orderline changes based on a key composed of the product id, the full product name and the note. This was done considering the fact that the merge orderline was working. Combo products are not handled by the merge orderline. Because of this, if 2 orderlines of combo product were the same, only the last orderline would be taken into account. To prevent this, this commit changes the key to the uuid which is a unique identifier to an orderline.

Forward-Port-Of: odoo/enterprise#49893

Since changes have been made in default tax settings, incoming emails with invoices for l10n-cl are not configuring the tax correctly. This ensures that the default tax is being added correctly. This PR is a revision of #49332 wich did not work since method `_get_withholding_taxes()` returns a set, and the default_purchase_tax cannot be added that way. Besides, as the default tax is the main one, we put it first in the sequence of taxes. Forward-Port-Of: odoo/enterprise#49651

Since changes have been made in default tax settings, incoming emails with invoices for l10n-cl are not configuring the tax correctly.

This ensures that the default tax is being added correctly.

This PR is a revision of #49332 wich did not work since method `_get_withholding_taxes()` returns a set, and the default_purchase_tax cannot be added that way.

Besides, as the default tax is the main one, we put it first in the sequence of taxes.

Forward-Port-Of: odoo/enterprise#49651