Description of the issue/feature this PR addresses:
This pull request adds  `l10n_ar.partner.tax_billing` on the `l10n_ar_partner_tax` model, granting read, write, and create permissions (but not unlink) to users in the `account.group_account_invoice` group.

Current behavior before PR:
Only users with administrator access rights on the Accounting module could modify the "Perceptions / Withholdings" Section on the "Accounting" tab of the partners.
<img width="1236" height="673" alt="image" src="https://github.com/user-attachments/assets/92b42973-2b01-4019-8e23-5e3cbf5111a4" />


Desired behavior after PR is merged:
Users with invoicing rights can modify the Accounting module could modify the "Perceptions / Withholdings" Section on the "Accounting" tab of the partners. This is needed to properly create the invoices with the perceptions / withholding that apply, for example in cases where by default all partners are set with perceptions, but some depending on their activity are not taxed. In that case, the user that created the partner needs to be able to modify the field by putting a 0% aliquot or deleting the perception line on the contact. 




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

Forward-Port-Of: odoo/odoo#225180

When two timeoff (one with Ignore Public Holidays and the other without) have the same dates, if you modify a public holidays that happend during that time, it will trigger a traceback.

Steps to reproduce:
-------------------
* Marc demo and Abigail Peterson using the same calendar
* Create a "Paid time off" leave for marc demo: June 19 - June 20
* Create a "Extra time off" for abigail: same date
* Update Time off type "Extra Time Off" to "Ignore Public Holidays"
* Approve both leave request previously created
* Create public holidays on June 19 --> traceback

Observation:

When both time off have the same dates it will overide the value in the dictonary https://github.com/odoo/odoo/commit/0d846ecd1ec7ff5149d580d3494b1a4bab1e68d2#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R464 and when it will try to call the employe_id it will trigger the traceback https://github.com/odoo/odoo/commit/f72ac3a14d76d4fb53ec3a092d08afafe4c35888#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R561

Why the fix:
------------
Added a new key on work_days_data to avoid the collision of two similar timeoffs.

opw-4933820

Forward-Port-Of: odoo/odoo#225884
Forward-Port-Of: odoo/odoo#221942

**Steps to reproduce:**
- Install accountant

- Go to "Accounting / Configuration / Invoicing / Payment Terms"
- Create a payment term having at least 2 installments (e.g. 20%-80%)

- Create a bill:
  * Vendor: [any]
  * Payment terms: [the created payment term]
  * Amount: 1000
- Confirm the bill

- Pay the first installment from the bill (i.e. 200)
- Go to "Accounting / Vendors / Payments"
- Select the payment and create a batch
- Validate the batch payment

- From Accounting dashboard, go to Bank journal
- Create a statement:
  * Partner: [None]
  * Amount: -200
- Reconcile the statement with the batch payment

- From the bill, pay the second installment (i.e. 800)
- Go to "Accounting / Vendors / Payments"
- Select the payment and create a batch
- Validate the batch payment

- From Accounting dashboard, go to Bank journal
- Create a statement:
  * Partner: [None]
  * Amount: -800
- Reconcile the statement with the batch payment

**Issue:**
The following UserError is raised:
"You are trying to reconcile some entries that are already reconciled."

**Cause:**
When reconciling a batch payment, all the payment term lines from the invoices/bills linked to the payment are used.
However, in this case, when the first batch payment has been reconciled, the first payment term line of the bill (linked to the first installment) has been reconciled.
It should not be reused when reconciling the second batch payment.

**Solution:**
Exclude reconciled payment term lines when reconciling a batch payment.

opw-4830185

Forward-Port-Of: odoo/enterprise#92524
Forward-Port-Of: odoo/enterprise#91367

Issue:
----------------------------------------
When creating a repair order that has a quality point (defined for all products or for a specific product), or when trying to create a new lot/serial number from the repair order, a traceback is triggered:
`ValueError: Invalid field 'lot_id' in 'quality.check'`

Steps to reproduce:
----------------------------------------
- Install the `quality_repair` module.
- Create a Quality Point for Operation: Repair Orders and set Control per Product/Operation.
- Create a Repair Order and add a product to repair.
- Save the Repair Order.
- Traceback is triggered.

Cause:
----------------------------------------
In PR https://github.com/odoo/enterprise/pull/90930, the `lot_id` field was replaced by a many2many field `lot_ids`.
Repair orders were still trying to assign `lot_id`, causing the error.

Solution:
----------------------------------------
In this commit, we ensure that `lot_ids` is set properly, allowing repair orders with quality checks to work smoothly and enabling users to assign lots/serial numbers without triggering errors.

Task ID:- 5067457

Issue:
----------------------------------------
When creating a manufacturing order and trying to allocate it to the desired sale order or outgoing picking, a traceback is triggered: `AttributeError: 'stock.move' object has no attribute 'group_id'. Did you mean: 'grouped'?`

Steps to Reproduce:
----------------------------------------
- Install the `mrp` module and enable `Allocation Report for Manufacturing Orders`.
- Create a product with a BoM.
- Create a Sale Order or outgoing picking for the product.
- Create a Manufacturing Order and go to the allocation report.
- Try to assign it to the picking.
- Traceback is triggered.

Cause:
----------------------------------------
In PR odoo#212679, the `group_id` field was replaced by a many2many field `reference_ids`.
However, the `_action_assign` method still tried to set the value of `group_id` instead of `reference_ids`, causing the error.

After this Commit:
----------------------------------------
In this commit, we ensure that `reference_ids` is used and set properly instead of `group_id`, allowing users to assign quantities to the desired picking smoothly without errors.

Task ID: 5076863

### [FIX] html_editor: prevent removal of unremovable links with images

The override that remove a link on `deleteImage` command did not check
if the link was unremovable before removing it.

### [FIX] html_editor: prevent removal of links in contenteditable=false

If a link was `contenteditable=true`, but inside a
`contenteditable=false`, it could be removed

### [FIX] html_editor: prevent removal of unremovable links in batch removal

If the selection covers several links, the "unlink" of the toolbar
removes all the links selected. This included the links which were
supposed to be unremovable.

The procedure for removing the links is changed to avoid removing the
unremovable nodes.

The availability of the tool in the toolbar is also changed to better
reflect whether there is links to remove. In case of unremovable links,
the tool is shown as disabled

Steps to reproduce:
- Open website builder
- In the toolbar, insert links just before and after the "Contact Us"
- Select from the link inserted before, to the one after
- In the toolbar, click "Remove Link"
- Bug: the link on "Contact Us" is gone, but it was "unremovable"
  (Saving after these steps currently breaks the toolbar's rendering)

Forward-Port-Of: odoo/odoo#223237

Since the initial [website builder refactor], when in translate mode
in website builder, pressing an arrow key when the cursor is inside the
text of a carousel moved to the next slide once, pressing again caused
a crash. Before the refactor, there was also the slide behavior but not
the crash.

The arrows triggers the slide because the contenteditable is inside
the slide in translate mode. It does not trigger it in normal edit mode
because the contenteditable is on an ancestor.

This commit fixes it by changing the config pass to the bootstrap
carousel in edit mode, so that the carousel does not slide on keyboard.
Changing this config makes the event handlers to stop the keydown event
on the other parts of the carousel redundant, so they are removed

Steps to reproduce:
- Open website bulider
- Drop the snippet "Quotes Minimal"
- Add a second language to the website
- Edit the translation for the second language
- Click on the text in the quote in the carousel
- Press a left or right arrow key
- Bug: the slide changed (instead of moving the cursor in side the text)
- Click on the text of the slide that is now shown
- Press again the arrow key
- Bug: Crash

[website builder refactor]: https://github.com/odoo-dev/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
task-4367641

Forward-Port-Of: odoo/odoo#226273

ISSUE
=====

Introduced in odoo/enterprise@bce7e94650c337a9046958a7689c81db5b2a4c73 , we now allow configuring a number of max simulatenous appointments per resource / user per slot, when manage_capacity is False.

However, this broke the booking flow when enabling a payment on the appointment type as well, for resources with capacity > 1. More specifically, as soon as the remaining capacity is lower than the resource's own capacity.

STEPS TO REPRODUCE
==================

0. Install payment_demo, in order to be able to test the payment issue. Install website_appointment_sale to ease the testing too.
1. Create an appointment type for 'Resources', enable 'Up-front payment'.
2. Set a new resource with capacity = 2 on the appointment type.
3. Make sure manage_capacity is False, and number of simultaneous appointments (max_bookings) is set to 1.
4. Go to the front end and pick any slot.
5. Fill the form and 'proceed to payment'
6. Try to 'pay now'
7. You get a validation error message telling you that the slot is not available anymore. But it is not the case since it is a new type and new resource.

FIX
===

For resources, created booking lines were setting capacity_used to the resource's capacity, unless shared. (meaning: the resource is completely used, even if the reserved quantity is smaller). It made sense before but not for this new feature. It should only use 1 capacity, as we count the number of different simulatenous appointments, and it is unrelated to the resource's own capacity.

When creating the meeting at the end of the regular flow, the computed field on capacity_used on appointment.booking.line will set it to 1 when manage_capacity is False. Hence, no issue will happen there in practice as the meeting is always created in that case and capacity_used updated.

However, when enabling a payment, we create a calendar.booking instead, with calendar.booking.lines. And based on those, we evaluate availability when checking the cart before going to payment.

Those are simply created from values in the controller, and the model is much simpler. Therefore, we fix the issue by manually setting the capacity_used to 1 when creating the booking lines in the front-end booking flow, in the case of an appointment without capacity management.

Task-4963012

Forward-Port-Of: odoo/enterprise#91700

Steps to reproduce:
- With an MX Company setup
- Set USD rate to:
  - 0.049216958195 for day 1
  - 0.053418803419 for day 2
- Create an invoice in USD as follows:
    - line 1: price_unit 91, quantity 64, tax 16%
- Confirm and send CFDI
- Register full payment in MXN
- Send Payment CFDI

Issue: Payment validation will fail with error

Code : CRP20268
Message : El campo BaseP que corresponde a Traslado, no es igual a la suma de
los importes de las bases registrados en los documentos relacionados donde el
impuesto del documento relacionado sea igual al campo ImpuestoP de este elemento
y la TasaOCuotaDR del documento relacionado sea igual al campo TasaOCuotaP de
este elemento.
Message : Valor esperado: 109025.275956 valor reportado: 109025.275862

This occurs because the precision set in https://github.com/odoo/enterprise/commit/e642e4d6d35c79d02c799d12451f3e2d92ab96e9 is high and can lead to failed
verification due to rounding on our side, because we compute BaseP using
the full digits of EquivalenciaDR, but, according to the specs, we
send it rounded to 10 digits.

opw-4750981

Forward-Port-Of: odoo/enterprise#94465
Forward-Port-Of: odoo/enterprise#92768