*: account_edi_ubl_cii, account_peppol

Revamping around Peppol to simplify onboarding.

1. In previous commit [1], we added a footer in email when relevant with some Peppol
related information.
2. Simplify the res.config.setting view.
3. Auto-install the Peppol module for following countries:
AT, BE, CH, CY, CZ, DE, DK, EE, ES, FI, FR, GR, IE, IS, IT, LT,
LU, LV, MT, NL, NO, PL, PT, RO, SE, SI.
4. Peppol Registration wizard: **Remove SMS validation** => we are assessing some
KYC, but the SMS validation is not preventing much, so its only adding frictions.
Remove the migrations key from the wizard, if the user has registered a key through his
previous Access Point, we retrieve it and automatically migrates the participant.
Small UI improvements.
5. Print & Send wizard: refine warnings, disable the "by Peppol" checkbox
if the customer is not on Peppol. Add some modals with explanations about Peppol
if the customer is on Peppol but the Sender didn't check the option.
6. Partner form: Hide in debug some too technical field. Small UI improvements.
7. EAS cleanup: revamp EAS description to be shorter and clearer. Better handling of translations.

[1] https://github.com/odoo/odoo/commit/4e984c0ae234f02bd07d96fc555d5b5e9ad144c3

task-4332306

*: account_payments, l10n_ar, l10n_cl, l10n_in_edi, l10n_in_edi_ewaybill, l10n_it_edi, l10n_latam_invoice_document, payment_asiapay

---

Description of the issue this commit addresses:

When there is no move in the current sequence, the moves you create take a slot in the sequence while being drafts, this means that if you do not confirm moves in the order they were created, the second move to be confirmed has a lower sequence number than the first which breaks continuity.

---

Desired behavior after this commit is merged:

This commit makes it so that no sequence number is ever assigned while the move stays in draft. A dynamic placeholder shows the user what the name will be with the sequence "template" but it is only used once the move is confirmed.

For subsequent moves, meaning when a first sequence number has been consumed, the old behavior of showing "Draft" as a name stands but there is still no sequence number consumed.

---

Enterprise PR: https://github.com/odoo/enterprise/pull/73837
task-4241510

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

*: account_reports, l10n_ec_reports_ats, l10n_es_reports, l10n_uy_edi

---

Description of the issue this commit addresses:

The community PR linked to this one modified the naming behavior of moves and therefore tests have broken. This PR adapts thoses tests to the new behavior.

---

Old vs. New naming behavior:

Let's consider an empty journal. In this journal three moves are added with decreasing date (move1 is the most recent, move2 is in the middle and move3 is the oldest). now we batch the moves and post them together.

Before, the first move of a journal would consume the first sequence number upon its creation even in draft and subsequent moves in would be named "/". When batched and posted afterwards, in the `_compute_name()` method, a `.sorted()` would order the moves by date (account.move(3, 2, 1)) and would use that order to name them. As the first sequence number is burned, move3 will use the second number and move2 will use the third number in the sequence. Resulting names: move1: 1, move2: 3 and move3: 2.
With x moves: move1: 1, move2: x, move3: x-1, move4: x-2, ...

Now, since no sequence number name is ever assigned to a draft entry, upon their creation, all three moves are named "/". And then, when they are batched and posted. they will be ordered 3,2,1 just like before but when naming move3, the first sequence number isn't consumed anymore so it will be named 1, move2 will be name 2 and move1 will be name 3.
Resulting names: move1: 3, move2: 2 and move3: 1.
With x moves: move1: x, move2: x-1, move3: x-2, move4: x-3, ...

---

Desired behavior after this commit is merged:

Tests that were relying on the fact that the first move of a sequence uses the first sequence number upon creation and not when posted are now adapted to take into account that sequence number are consumed when posted.

In l10n_ec_reports_ats, moves without a latam document number are ignored for    
the ATS export because missing that attribute means they don't have names which 
makes them unfit for the export anyway.

---

Community PR: https://github.com/odoo/odoo/pull/185326
task-4241510

**Steps to reproduce:**
- Install Accounting
- Create an analytic plan (e.g. XYZ)
- Create 2 associated analytic accounts (e.g. XYZ_1 and XYZ_2)
- Create a journal entry with the first analytic account:
  * Journal: Miscellaneous Operations
  * Journal Items:

    | Account        | Analytic Distribution | Debit | Credit |
    | ------------- | ------------ | ----------------- | --------------------- |
    | 101000 Current Assets |         XYZ_1         |  100  |   0 |
    | 600000 Expenses       |                       |   0   |  100 |

- Create another journal entry with the second analytic account:
  * Journal: Miscellaneous Operations
  * Journal Items:

    |  Account        | Analytic Distribution | Debit | Credit |
    |----------------|-----------------|---------------|---------------|
    | 101000 Current Assets |         XYZ_2         |  200  |   0 |
    | 600000 Expenses       |                       |   0   |  200 |

**Use case 1:**
- Go to "Accounting / Accounting / Journal Items"
- Add a custom filter: [("Distribution Analytic Account", "is in", "XYZ_1")]

**Issue 1:**
Nothing happens. The filter doesn't work.

**Use case 2:**
- Go to "Accounting / Configuration / Accounting / Horizontal Groups"
- Create a group:
  * Reports: Balance Sheet
  * Field: Distribution Analytic Account
  * Domain: [("Plan", "is in", "XYZ")]
- Go to "Accounting / Reporting / Statement Reports / Balance Sheet"
- Set Horizontal Group to the created one

**Issue 2:**
A grouping is done by analytic account (visually) but no filter is done on the data.
The value on all the columns are the same.
The configuration of field "Distribution Analytic Account" in the horizontal group doesn't apply.

**Cause:**
`distribution_analytic_account_ids` is a computed field without a search defined.

opw-4302877




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

Currently, an exception is generated when the user archives a document and its
folder and tries to delete both folder and document once from Trash.

Steps to produce:
- Open document and create folder and add document in folder
- Now delete document and folder
- Go to Trash > open list view > Select all records > Click on Delete

error
```
MissingError: Record does not exist or has been deleted.
(Record: documents.document(1,), User: 1)
```


This is because 'to_delete' contains all documents (self), including the folder
that we deleted, and `removable_parent_folders` contains only the folder that
we deleted. Now when cleaning records, [1] unlinks all files, including folders,
and [2] again tries to delete the folder that we already deleted with [1].

This commit will fix the above issue by filtering `removable_parent_folders`
now it is filtering records folders thats id not in self ids.

[1] - https://github.com/odoo/enterprise/blob/5ba1aa66ab17d686da648025c8921995938115ed/documents/models/documents_document.py#L1935
[2] - https://github.com/odoo/enterprise/blob/5ba1aa66ab17d686da648025c8921995938115ed/documents/models/documents_document.py#L1941

sentry-6048388238

Improve loop detection and break. Indeed heavy usage of mailgateway on
Odoo servers lead us to face email loops. Those lead to email being disabled
on our servers due to email limit, and to other issues (spam, never ending
notifications, ...) on hosted servers.

Three scenarios are fixed with this PR. See individual commits for more
details. Those are
 * having followers using alias email, and using a mail provider that rewrites
   msg-id: we cannot detect message duplication and this may generate loops.
   Several mail providers rewrite message IDs and that is a pain for us. We
   therefore add a custom header allowing to keep message ID in envelope;
 * replying to bounce may create bounce in loops: this is fixed using the
   loop detection custom reference;
 * detect loops on record update in addition to record creation: do not limit
   loops detection on aliases creating records, also check updated records;

Task-3895869
OPW-4051539
OPW-4295745
OPW-4302257

Forward-Port-Of: odoo/odoo#190767
Forward-Port-Of: odoo/odoo#187696

For now, a user chan change the locations of a done SML, making it
valuable while it was not (or the opposite), which leads to a broken
stock valuation.

To reproduce the issue:
1. In the Settins, enable
   - Automatic Accounting
   - Storage Locations
2. Create a product category C
   - Method: FIFO
   - Valo: Auto
3. Create a product P
   - Inventory tracked
   - Category P
   - Cost $1
4. Update its quantity
   - 10 x P at WH/Stock
5. Inventory > Reporting > Moves History, open SML related to P
6. Update the SML:
   - From: WH/Stock
   - To: WH/Stock/Shelf 1
   - Quantity: 100
7. Inventory > Reporting > Locations, look for P
   - There are two lines
     - -100 at WH/Stock
     - 100 at WH/Stock/Shelf 1
   - And, therefore, the total on hand is 0, which makes sense
8. Inventory > Reporting > Valuation, look for P

Error: There are two lines, one that adds $10 to the valuation (from
step 4) and a second one that adds $90. This is incorrect, the SML
is now an internal move and should not add any value to the stock.
In fact, the first line should even be cancelled

Letting the user changes a done SML can be convenient, but he should
not be able to change the locations as he wants since the code does
not handle all cases.

OPW-4275417

Forward-Port-Of: odoo/odoo#190511

Steps to reproduce the issue:
=============================
- Have 2 p elements where the last one have a link at the end of it
- Copy the 2 lines
- Paste them
- The box around the link is shown which indicates that the cursor is
  inside the link
- Try to add content
- The content is added oustide the link

Origin of the issue:
====================
When the selection have the p element and inside it there is an a
element , currentNode will be the p and not the a, but lastposition
will have the link node which is not padded with zws yet. So we put the
selection without the padding and then it's added which changes the
selection to have anchor node on the end of the ufeff charater inside
the link (`<a>&#xFEFFcontent&#xFEFF[]<a>`) which makes the selection
appears as inside the link but adding content will be after the link.

Solution:
=========
We need to pad the link with zws in case the selection we put is at the
edges of the link.

 ----------------------------------------------- 

Before:
=======
In rtl lang, the cursor gets stuck at the edge of the link using the
arrow keys.

After:
======
No the cursor moves correctly in rtl lang. We need to make `arrowLeft`
as go to next and `arrowRight` as going previous

task-4089193

Forward-Port-Of: odoo/odoo#185707

revert the commit
as when we fetch archived warehouse's pos type
it will raise error for other source or destination loction for newly created stock operation type like

even functinally also there is no need to fetch
archived warehouse's operation type.
```
quality Control
cross Dock,
Storage type
```
we got this error during upgrade :
```
File "/home/odoo/src/odoo/saas-17.4/odoo/sql_db.py", line 347, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "default_location_src_id" of relation "stock_picking_type" violates not-null constraint
DETAIL:  Failing row contains (33, 0, 28, 56, null, null, null, 4, null, null, 1, 1, 1, QC, internal, at_confirm, FBAQC, ask, {"en_US": "Quality Control"}, null, f, f, t, null, f, null, 2024-10-16 05:14:53.18448, 2024-10-16 05:14:53.18448, optional, optional, no, optional, null, null, t, null, null, 2x7xprice, 4x12_lots, pdf, null, null, null, null, null, null, null, null, null, t, null).
```

due to this two fix:
https://github.com/odoo/odoo/pull/151719/commits
https://github.com/odoo/odoo/pull/175838/files

so we need to avoid to fetch archived warehouse's picking type.

ref:
odoo/upgrade#6631

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#185244

Improve loop detection and break. Indeed heavy usage of mailgateway on
Odoo servers lead us to face email loops. Those lead to email being disabled
on our servers due to email limit, and to other issues (spam, never ending
notifications, ...) on hosted servers.

Three scenarios are fixed with this PR. See individual commits for more
details. Those are
 * having followers using alias email, and using a mail provider that rewrites
   msg-id: we cannot detect message duplication and this may generate loops.
   Several mail providers rewrite message IDs and that is a pain for us. We
   therefore add a custom header allowing to keep message ID in envelope;
 * replying to bounce may create bounce in loops: this is fixed using the
   loop detection custom reference;
 * detect loops on record update in addition to record creation: do not limit
   loops detection on aliases creating records, also check updated records;

Task-3895869
OPW-4051539
OPW-4295745
OPW-4302257

Forward-Port-Of: odoo/odoo#190767
Forward-Port-Of: odoo/odoo#187696

When the user tries to reset the password, a traceback will appear.

Steps to reproduce the error:
- Install ``auth_signup``
- Configure "Outgoing mail server"
- Now Log out
- Click on Sign in > Reset Password > Enter your email >
  Click on ``Reset Password`` twice

Traceback:
```
InFailedSqlTransaction: current transaction is aborted, commands ignored until end of transaction block

  File "odoo/http.py", line 2365, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1892, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1955, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 137, in retrying
    result = func()
  File "odoo/http.py", line 1922, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2082, in dispatch
    return self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 331, in _dispatch
    result.flatten()
  File "odoo/http.py", line 1389, in flatten
    self.response.append(self.render())
  File "odoo/http.py", line 1381, in render
    return request.env["ir.ui.view"]._render_template(self.template, self.qcontext)
  File "home/odoo/src/enterprise/18.0/web_studio/models/ir_ui_view.py", line 1315, in _render_template
    return super(View, self)._render_template(template, values)
  File "odoo/addons/base/models/ir_ui_view.py", line 2185, in _render_template
    return self.env['ir.qweb']._render(template, values)
  File "odoo/tools/profiler.py", line 306, in _tracked_method_render
    return method_render(self, template, values, **options)
  File "odoo/addons/base/models/ir_qweb.py", line 597, in _render
    template_functions, def_name = irQweb._compile(template)
  File "odoo/tools/profiler.py", line 314, in _tracked_compile
    return method_compile(self, template)
  File "odoo/addons/base/models/ir_qweb.py", line 666, in _compile
    return self._load_values(base_key_cache, generate_functions)
  File "odoo/addons/base/models/ir_qweb.py", line 2524, in _load_values
    return get_value()
  File "odoo/addons/base/models/ir_qweb.py", line 635, in generate_functions
    code, options, def_name = self._generate_code(template)
  File "odoo/addons/base/models/ir_qweb.py", line 691, in _generate_code
    element, document, ref = self._get_template(template)
  File "odoo/addons/base/models/ir_qweb.py", line 822, in _get_template
    doc_or_elem, ref = self._load(ref_alias) or (None, None)
  File "odoo/addons/base/models/ir_qweb.py", line 859, in _load
    view = IrUIView._get(ref)
  File "odoo/addons/base/models/ir_ui_view.py", line 2085, in _get
    return self.browse(self._get_view_id(view_ref))
  File "odoo/addons/base/models/ir_ui_view.py", line 2073, in _get_view_id
    view = self.sudo().search([('key', '=', template)], limit=1)
  File "odoo/models.py", line 1717, in search
    return self.search_fetch(domain, [], offset=offset, limit=limit, order=order)
  File "odoo/models.py", line 1749, in search_fetch
    return self._fetch_query(query, fields_to_fetch)
  File "odoo/models.py", line 4180, in _fetch_query
    fetched = self.browse(query)
  File "odoo/models.py", line 6154, in browse
    if not ids:
  File "odoo/tools/query.py", line 261, in __bool__
    return bool(self.get_result_ids())
  File "odoo/tools/query.py", line 225, in get_result_ids
    self._ids = tuple(id_ for id_, in self._env.execute_query(self.select()))
  File "odoo/api.py", line 962, in execute_query
    self.cr.execute(query)
  File "odoo/sql_db.py", line 354, in execute
    res = self._obj.execute(query, params)
```

After this commit, user can not click on ``Reset Password`` button multiple times.

sentry-5661309399

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

Forward-Port-Of: odoo/odoo#184862

**Issue:**
In dark mode, for current day, half days off are displayed with white background in the Field Service Gantt View for the working part.
![image](https://github.com/user-attachments/assets/1ca587ff-7a12-4011-858a-2110bd2bbfd0)

**Expected:**
In dark mode, worked half days should have same background as entire worked day for current date.

**Steps to reproduce:**
- Activate Time Off and Field Service apps and activate Dark Mode;
- In `Time Off / Management / Time Off` create a new half day off time for any employee under contract (e.g. Mitchell Admin) for the current day;
- Approve and validate;
- Move to `Field Service / Planning / By User`;
- Remove all search filters and display using Gantt View by week or by month;
- *(opt) Create a new task for the chose user if does not appear*;
- Look at the current day cell of the user.

**Cause:**
No dark theme background color is set to override the light theme.

**Fix:**
Setup background color for dark theme by overriding hard coded light theme color: https://github.com/odoo/enterprise/blob/7778a8e45502da89e27910efab401d3556d8c7f7/web_gantt/static/src/gantt_view.scss#L21
![Capture d’écran 2024-12-16 à 09 18 38](https://github.com/user-attachments/assets/293d4863-706f-4df0-8ab0-5107673c84eb)
![Capture d’écran 2024-12-16 à 09 57 09](https://github.com/user-attachments/assets/a554f745-4945-414f-8f0b-98ef64e1868f)


opw-4368966

Forward-Port-Of: odoo/enterprise#75651

Some users need to make invoices with 100% discount lines. If they try then will receive this UCFE error that does not let us to validate the invoice in DGI .

> ERROR: CODE 31: Error: El contenido del elemento 'Item' en espacio de nombres 'http://cfe.dgi.gub.uy' está incompleto. Lista esperada de elementos posibles: 'SubDescuento, RecargoPct, RecargoMnt, SubRecargo, RetencPercep, MontoItem' en espacio de nombres 'http://cfe.dgi.gub.uy'. 

In order to make it work we need to adapt the module to accept this kind of lines that actually represent an "Entrega Gratuita" (Indicator 5 in Uruguay)

- We check if the line is a 100% discount, if it is then we marked as Entrega Gratuita when we are creating XML (Indicator 5)
- Now that we can have lines and also invoices with total value 0.0 we need to adapt our XML because if value 0.0 then some tags were not added to the final XML - it was interpreted as False and the result was and invalid XML becasue we were missing a mandatory tag. Now we can tags that have 0.0 value to the final XML.
- Now that we can have lines 0.0 total amount, and also invoices 0.0 total amount, if we are using foreign currency then we need to avoid error computing the currency rate (division by zero). Now we detect this cases and use the date rate. Also, the rate is only been computed when actually we are going to use it.

LATAM 1296 / ADHOC Ticket 83295

Forward-Port-Of: odoo/enterprise#73956

### Steps to reproduce:
- Activate developer mode
- Install the 'l10n_ec' module and switch to an Ecuadorian company
- In Settings > Technical > Database Structure > Decimal Accuracy change the number of decimals for "Product Price" to 4 for example
- In Accounting, create a new Customer Invoice
- Select 'Instituto Ecuatoriano' as Customer
- Add a line with a price with 4 decimals
- Select 'Sin utilization del sistema financiero' as Payment Method
- Confirm
- On the blue popup at the top of the page, click 'process now' to get the XML in the chatter
- In the XML the "precioUnitario" field only has 2 precision digits, it has been rounded
- When adding a discount of 100% this field has all precision digits needed

### Cause:
The price_unit is calculated differently if the discount is 100%. The "precioUnitario" field should always have the number of precision digits specified in the settings.

### Solution:
We need to find the unit price without the discount, but without the included. This value is not computed.
As the values computed in the account.move.line are already rounded based on the currency (2 digits) we need to
recompute the values using `compute_all` and multiplying by the `price_digits` to not round in `compute_all`.

The way the rounding is made here is by taking the decimal precision from the settings and making it a power of 10 in `price_digits` (4 decimals results in price_digits = 10000). Then we compute the taxes with `price_unit * price_digits`. As, per definition,  `price_unit` has the number of digits used in the calculation of `price_digits`, we end up with an integer. But after the results of `compute_all` may no longer be an integer. We need an integer to keep the decimal precision. This is why, in the result, there is a call to `round()`.
The call to `float_round()` is to make sure there are not more decimals than 6. This is needed as the number displayed in the XML will always be of 6 decimals, so if the client set a number of decimals greater than 6, it will be rounded in the XML but not on the invoice. To ensure that both values are the same, we round the value here.

Some tests had "precioUnitario" with strange values that did not match the actual price_unit. It was because the precedent way to calculate this field was not perfect, I guess.

opw-4120341

Forward-Port-Of: odoo/enterprise#75152
Forward-Port-Of: odoo/enterprise#68555

This fix is to avoid the an error that occurs when a country does not have the VAT information set. Before this fix, when that situation happened the method get_vat_country returned False as those fields values and therefore the XML could not be processed since it was expected an integer and it got a boolean. After this fix, if a country does not have VAT information, the field will be process as 0 and the XML will be created, so the invoice will be confirmed. 
We already had this approach in the past, inside the method wsfex_get_cae_request, but it was lost in a refactor made on the module. So what I did was just to recover that approach. 
https://github.com/odoo/enterprise/commit/33ea78a5bb34e657c16bcbb704eeb71897ae642d#diff-2459e118c605cf039bb94c62561285ad753b6a27c571f10a25547ee9b01aa318L741. 


Steps to reproduce the error:
- Create a test contact based on Uruguay.
- Go to Contacts/Configuration/Localization/Countries and delete all VAT information from Uruguay (Natural Person VAT, Legal Entity VAT, Other VAT) .
- Create an invoice for the test client created before, add a product and all needed fields and try to confirm the invoice.
-  An error will pop up, saying that the server was unable to read request because of an error in the XML document.

Forward-Port-Of: odoo/enterprise#75501

### Issue:

With commit odoo/enterprise@8a3e03841ac6e609a9fe882c10e547bd039d7fcc, changes were made in `_get_post_fix_tax_amounts_map` to cover more cases and fix cases that broke because of it.
In 17.2, with similar code to the fix having no rounding, the tax and base amount are not rounded.
This resulted in an issue for cases with multiple taxes, see test case in 18.0:
`8% tax` with an amount of `1.196` and `16% tax` with an amount of `1.677`.
Addition of both tax amounts is `2.873`, rounded to `2.87`, but amounts are rounded separately to `1.20` and `1.68`, the sum of which is `2.88`.

In 17.0, where base and tax are rounded before being returned, there is no issue with multiple taxes.

### Fix:

In the same commit, total calculation was moved to the end of `_get_global_invoice_cfdi_values`, using subtotal and taxes totals after they were calculated. This allows for the calculation of `TotalImpuestosTrasladados` using rounded tax groups totals.

opw-4050778

Forward-Port-Of: odoo/enterprise#75370