### 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#75599
Forward-Port-Of: odoo/enterprise#68555

*: 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

Forward-Port-Of: odoo/enterprise#73837

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#75639
Forward-Port-Of: odoo/enterprise#73956

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

Forward-Port-Of: odoo/enterprise#73816