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

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

The tax report (KMD report) and annex to the tax report (KMD INF report) for Estonia needed to be reworked to correct errors, address rounding differences and overall improve the way the KMD and KMD INF reports are presented.

With this commit:
- better auditing of the report lines is enabled by adding balance_from_tags to the action_audit_cell.
- rounding fields are added to res_config_settings and to its view
- calls _postprocess_vat_closing_entry_results to apply the rounding in the tax closing.
- rewrites the KMD INF report.
- adds a warning for potential transactions not included in the KMD INF report due to missing country or VAT in the partners.

KMD INF Report
This commit creates one report composed of two sections with different columns, using the custom engine to construct both parts.

Part A contains information on invoices issued, grouped by move_id and id, to allow showing multiple lines per invoice when different tax rates and/or special tax types are in one invoice. It only includes invoices with taxable supply at 22%, 20%, 9% and 5%. It excludes invoices of partners whose Tax ID is / and foreignes partners who have a Tax ID not starting by EE.

Part B contains information on invoices received, grouped by move_id. Each line showcases information about one invoice with taxable supply at 22%, 20%, 9% and 5%. It relies on a Tax ID starting with EE.

The reports follow the guidelines available in
https://www.emta.ee/en/business-client/taxes-and-payment/tax-returns-exchange-information/vat-return-forms-vd-and-vdp (forms valid from 01.01.2024 onwards).

task-3997203

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

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

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

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

Steps to reproduce:
[l10n_be_us_consolidation_demo]
- go to consolidation > Test Chart > Consolidated Balance > Comparison > Test Chart
- click on a cell to proceed to an audit

Issue:
Stacktrace

Cause:
Journal id is not defined. When there are multiple periods we use the `ComparisonBuilder` https://github.com/odoo/enterprise/blob/4367042c8c7f2190d23019e591c332045b7d4993/account_consolidation/report/trial_balance.py#L139

Which, contrarily to the DefautBuilder, journals is not defined. In the AbstractBuilder (inherited in the two builders), `auditable` is set to True without consideration of the builder's definition https://github.com/odoo/enterprise/blob/3e5ac3554f4fded90fd37c56c7c60723aec59404/account_consolidation/report/builder/abstract.py#L278

On the front side, whenver we click on a auditable cell, we call the action_open_audit but journal_id is defined https://github.com/odoo/enterprise/blob/2d774344109c2f9b55d9ea6160ae99aeca4f0420/account_consolidation/static/src/components/consolidation_report/line_cell/line_cell.js#L19-L38

-> error

Solution:
Asusming that `auditable` is the rule and the case for the comparison builder is the exception, auditable is set to False only in the ComparisonBuilder

Since `consolidation` is meant to be decommissioned, the least impacting fix is being applied.

Note:
in 16.0, the cells are not auditable when using comparison periods. opw-4265031

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

Currently, when reducing the quantity of a line, the notification for the cancelled items is not sent

Steps to reproduce:
-------------------
* Set up the preparation display on the category food
* Open both restaurant and preparation display
* In the restaurant place an order for an item with a quantity of 3
* Send the order to the kitchen
* Change the quantity to 2
* Send the order to the kitchen
> Observation: The notification is not sent to the preparation display

Why the fix:
------------
When reducing the quantity, data looks like this
`{'change': True, 'sound': False, 'category_ids': {}}`. Since `category_ids` is empty, `preparation_displays` will alsos be empty which explains why the preparation display does not receive the notification, it is simply not sent.
https://github.com/odoo/enterprise/blob/42b7b322d6c720de45661e3370397adaf74fe1f4/pos_preparation_display/models/preparation_display_order.py#L29-L40

When augmenting the quantity we add the category here: https://github.com/odoo/enterprise/blob/681c4bca67e9e312f66d797e45fb7e1c3a10b983/pos_preparation_display/models/pos_order.py#L135

We use the same logic when reducing it. This is already done in more recent version:
https://github.com/odoo/enterprise/blob/42b7b322d6c720de45661e3370397adaf74fe1f4/pos_preparation_display/models/pos_order.py#L166

opw-4332578

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