This fix corrects how customer and vendor account identifiers are formatted when exporting general ledger data in DATEV format for German accounting. Previously, the system inconsistently handled account codes for duplicate receivable/payable accounts. Now all accounts are properly formatted according to DATEV standards, ensuring accurate financial reporting exports.

When exporting GL in datev format, the receivable/payable
accounts were not well formatted.

Steps:

- duplicate the Receivable Account (A)
- create a customer C with receivable set as A
- create and confirm an invoice for C
- go to GL and export datev file
-> column konto is account code of A, it should
   be 1000000 + C.id, according to datev (starting by
   1 for customers and 7 for Vendors)

Before this commit, we were making the distinction between
the customers that had the "original" receivable account and the others,
and we were displaying the account code in the second case. It should be
the datev format in any case.

opw-4117993

Forward-Port-Of: odoo/enterprise#69573

This update fixes how Odoo calculates and rounds tax amounts on Mexican invoices (CFDI) to comply with Mexican tax authority requirements. The system now ensures that tax calculations stay within the allowed 0.01 rounding error margin, preventing invoice rejections by Mexican authorities. This is critical for businesses operating in Mexico that use the global rounding method for invoices.

This commit adds an additional step when aggregating the values for
sending invoice CFDI, and ensures the final result to be within the
allowed maximum rounding error of `0.01`.

Purpose:

When creating an invoice with the following amounts:

- line 1: 505.0, tax_16
- line 2: 495.0, tax_16
- line 3: 475.0, tax_16
- set tax_16.price_include to True

The CFDI result of the invoice when generated using "round globally"
method on either normal or global sending will be rejected by the
mexican authorities.

This is caused by an inherent flaw of how Odoo calculates line amounts.
The `compute_all` method in taxes rounds all the lines in cfdi_values to
2 digits precision in the final result, resulting in a loss of precision
when calculating the total amounts.

The mexican authorities requires us to make sure that:

1. the sum of the base/tax amounts in the lines (Conceptos) matches the
   total
2. the rounding of the total base and tax amount to be within 0.01
   rounding error

In the provided example, in Odoo, we will generate a total of 1271.54
base amount and 203.46 tax amount. This is not acceptable by the mexican
government because 1271.54 * 0.16 equals 203.4464, which when compared
with our result of the tax amount exceeds the maximum allowed rounding
error.

To fix this, we have to sacrifice our correctness and generate amounts
that will have disrepancies whenever we need it (for global rounding
method).

We will now re-calculate the base and tax amounts in `cfdi_values` based
on the total amount and generate new amounts with 6 digits precision,
and apply that on each line of Conceptos.

The 2 digit rounding precision limit on `Importe` and `ValorUnitario` 
XML will be changed to 6 digits to make sure we pass the first
requirement, as the mexican authorities will also calculate their total
and check if it matches our total. Due to this change, all of the test
files than contain this element needs to be udpated too.


task-id: 4071712

This update fixes a compatibility issue with the latest Chrome 128 browser version that affects the payroll dashboard testing. The fix ensures that the payroll dashboard tests run correctly by properly handling browser events in the newer Chrome version, maintaining system reliability and test accuracy.

This update adds necessary safety measures to the Uruguay EDI module to prevent test database copies from accidentally communicating with external systems or affecting production data. This allows the support team to safely investigate issues on database duplicates without risk of impacting customers or production systems.

This commit adds the missing neutralization necessary for the l10n_uy_edi
module introduced in [1]

The purpose of the standard neutralization framework is to allow us to
create database copies that will not interact with external systems in
ways that could impact the production database (or if it is not possible
to prevent the interactions, make sure that they are benign or won't
result in actual changes), or impact the customers of the operator of
the production database.

This is mainly useful to allow safe support investigation on database
duplicates.

[1] https://github.com/odoo/enterprise/pull/51266

This fix resolves an issue where users couldn't drag and drop signature template components in Firefox. The problem was caused by Firefox's lack of support for drag and drop on button elements. Users can now easily drag and drop new components throughout the entire button area, not just the text inside, improving the template creation experience.

The problem was that the button tag doesn't support drag & drop functionality in Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=568313).

Steps to reproduce (On firefox):

- Open Sign up

- Open template

- Try to drag and drop new compoent

- You can only drag and drop through the text inside

opw-4085496

Fixed an issue where customers could open the date picker and select new rental dates even when a rental product was already in their cart, which had no effect since rental periods can only be modified from the cart. The calendar button remains visible to display helpful information, but the date picker is now disabled in this scenario to prevent confusion.

Issue
-----
[website_sale_renting]
In case there is already a rental product in the cart, it is still possbile
to open the date range picker by clicking the calendar button and selecting
a new period, which will have no effect as the rental period can only be
changed from the cart.

Change
-----
Disable the date picker but keep the calendar button as it contains a help
message.

opw-4076088

This fix restores the "I am unavailable" (unassign) button that was missing from the planning gantt view after a technical update. The button allows employees to mark themselves as unavailable for scheduled shifts. The fix ensures the button now appears correctly in the shift details dialog by properly passing the necessary context information.

Since the convertion of the gantt view to OWL in saas-16.1 the search_default_* type context is no longer passed from the gantt view to the gantt.form dialog window of a record, thus the "I am unavailable" button couldn't appear anymore

replaced the search_default domain by 'my_planning_action' in planning gantt view and transmited the corresponding context through the openDialog method in the planning_gantt_controller

Task-3819134

This update corrects an incorrect documentation link displayed on the helpdesk team form view. Users will now see the correct knowledge base reference when accessing team settings, ensuring they have access to the right support resources.

This PR fixes a wrong documentation link in the helpdesk team form view.

Task-4102472

This fix corrects how phone numbers from Ivory Coast and other countries with leading zeros are formatted for WhatsApp. Previously, the leading zero in numbers like "0708151718" was being removed during formatting, resulting in incorrect phone numbers. The fix now preserves these leading zeros as required, ensuring customers can be reached at the correct WhatsApp numbers.

Current behaviour:
---
Ivory Coast phone numbers aren't formatted correctly 
`0708151718 => 225708151718`

Expected behaviour:
---
`0708151718 => 2250708151718`
National number leading zero should be preserved

Steps to reproduce:
---
```py
from ... import phone_validation as wa_phone_validation 
wa_phone_validation.wa_phone_format(
    record, number='0708151718',
    force_format="WHATSAPP",
)
```
Result => `'225708151718'`
Should be => `'2250708151718'`
NB: record has an Ivory Coast `country_id`

Cause of the issue:
---
`WHATSAPP format` is country_code + national_number
But because `national_number` is an `int`, the leading zero gets removed.

Fix:
---
See [phonenumbers/phonenumber.py](https://github.com/daviddrysdale/python-phonenumbers/blob/7f60158f325ed2ee14212b71ef7e7dc2ce5f01bb/python/phonenumbers/phonenumber.py#L124 )
The `italian_leading_zero` is set True when the national number starts with a zero, 
and it should be kept. (ie: Italian numbers) `number_of_leading_zeros` counts the zeros.
Taking those into account when formatting.

opw-3963124

This update fixes a confusing technical error that appeared when users tried to select a model they don't have permission to access in the Data Cleaning module. Instead of showing a technical traceback, users will now see a clear, user-friendly error message explaining that they don't have access to that model.

Problem:
When a model is selected that the user doesn't have access to, a traceback is shown instead of a clear error message.

Steps to reproduce:

- Install Data Cleaning.
- Go to Data Cleaning > Configuration > Duplication.
- In the Model field, select "Account Chart Template".
- A traceback occurs.

opw-4113923

This fix prevents users from renewing subscription contracts that haven't been invoiced yet. Previously, a subscription could be renewed even if it had never generated an invoice, which violated business rules. Now the system will display an error message when attempting this invalid action, ensuring subscriptions are only renewed after they've been properly started with an initial invoice.

Steps to reproduce:
- Subscriptions > New > Set recurrence
- Set 'Date of next invoice' in the future
- Renew

This should raise a ValidationError because renewing a subscription which was never started (no invoice) is invalid, as specified in the error message "You cannot upsell or renew a subscription that has not been invoiced yet".

opw-4116538

This fix resolves an issue where scanned barcodes were not being properly saved in the Manufacturing ShopFloor module. The system was not correctly registering changes when barcodes were scanned, and the "Continue Production" feature was not utilizing the proper save mechanism. This ensures that all barcode data is now accurately captured and persisted.

Scanned barcodes were not saved (setting field in record do not register the change).
Continue Production did not take advantage of saveModel parameter of doActionAndClose

Fixed an issue where the GSTR-3B tax report for Indian companies was not showing data from bank reconciliation transactions. The report now correctly captures manual reconciliation entries with tax information, ensuring complete and accurate tax reporting for section 3.1(d) of the GSTR-3B form.

* With an IN company setup
* Open the bank Reconciliation widget
* Make a manual reconciliation with tax 18% IGST RC
* Go to tax report GSTR-3B
* Issue: there is no impact on the report (3.1 d)

This occurs because in the report we take into account move of type `out_invoice` while move registered in the bank journal are of type `entry`

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4058256)
opw-4058256

Forward-Port-Of: odoo/enterprise#67520

Draft event registrations will no longer receive periodic WhatsApp notifications until they confirm their attendance. This prevents confusing situations where attendees receive reminders with ticket information before their registration is fully validated.

Draft registrations should not receive any periodic notification until they confirm they will be attending.

This avoids awkward situations where the reminder contains a ticket but their ticket isn't validated yet.

task-4104891

This fix enables users to set approval rules on form buttons that are linked to actions via XML identifiers. Previously, the system only supported approval rules on buttons with numeric action references, limiting flexibility in workflow customization. This enhancement expands the approval workflow capabilities in Odoo Studio.

Have a button in a form view of type="action" and name="some.xml_id"

Before this commit, it was not possible to set approval rules on it.

This was due to code in general expecting an int, which is only part of the API for viewButtons (see `action_service.js:doActionButton`)

After this commit, it is possible to set approval rules on such button.

backport of odoo/enterprise#69399

opw-3925360

This fix restores the EDI certificate that was missing from the Chart of Accounts (COA) SAT XML export for Mexican companies. The certificate is now properly included in the XML file when users download the COA SAT report, ensuring compliance with Mexican tax authority requirements and consistency with other SAT reports.

**Steps to reproduce:**
- Install l10n_mx_reports
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Go to "Accounting / Reporting / Audit Reports / Trial Balance"
- Download "COA SAT (XML)"

**Issue:**
The certificate is not present in the XML.

**Solution:**
Add the EDI certificate of the company in the "COA SAT (XML)" as it was done in previous versions and as it is also done in the "SAT (XML)".

opw-4076158

Forward-Port-Of: odoo/enterprise#68887