Starting from version `18.0`, the module `l10n_es_edi_verifactu` is dependent to `certificate` because of moving the model `l10n_es_edi_verifactu.certificate` into standard model `certificate.certificate`[^1].

On the other side when we install the module `l10n_es_edi_verifactu` then the `certificate` is beiung installed because:

1. (dependency)[^2] --> l10n_es
2. (auto install)[^3] --> l10n_es_edi_facturae
3. (dependency)[^4] --> certificate

But we can uninstall the `certificate` while having `l10n_es_edi_verifactu`. It will make the db unusable with this traceback if we uninstall `certificate`:

```
Traceback (most recent call last):
  File "/home/odoo/.local/lib/python3.10/site-packages/werkzeug/serving.py", line 319, in run_wsgi
    execute(self.server.app)
  File "/home/odoo/.local/lib/python3.10/site-packages/werkzeug/serving.py", line 316, in execute
    application_iter.close()  # type: ignore
  File "/home/odoo/.local/lib/python3.10/site-packages/werkzeug/wsgi.py", line 466, in close
    callback()
  File "/home/odoo/.local/lib/python3.10/site-packages/werkzeug/wrappers/response.py", line 439, in close
    func()
  File "/home/odoo/src/odoo/18.0/addons/bus/websocket.py", line 916, in <lambda>
    response.call_on_close(lambda: cls._serve_forever(
  File "/home/odoo/src/odoo/18.0/addons/bus/websocket.py", line 1030, in _serve_forever
    for message in websocket.get_messages():
  File "/home/odoo/src/odoo/18.0/addons/bus/websocket.py", line 322, in get_messages
    self._handle_transport_error(exc)
  File "/home/odoo/src/odoo/18.0/addons/bus/websocket.py", line 625, in _handle_transport_error
    registry = Registry(self._session.db)
  File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 108, in __new__
    return cls.new(db_name)
  File "<decorator-gen-13>", line 2, in new

  File "/home/odoo/src/odoo/18.0/odoo/tools/func.py", line 97, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 129, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 485, in load_modules
    processed_modules += load_marked_modules(env, graph,
  File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 365, in load_marked_modules
    loaded, processed = load_module_graph(
  File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 195, in load_module_graph
    model_names = registry.load(env.cr, package)
  File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 302, in load
    model = cls._build_model(self, cr)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 736, in _build_model
    raise TypeError("Model %r does not exist in registry." % name)
TypeError: Model 'certificate.certificate' does not exist in registry. - - -

```

[^1]: https://github.com/odoo/odoo/pull/219953
[^2]: https://github.com/odoo/odoo/blob/b991f766e28dc71f8627fdfbf2d59589d9707d3a/addons/l10n_es_edi_verifactu/__manifest__.py#L9
[^3]: https://github.com/odoo/odoo/blob/b991f766e28dc71f8627fdfbf2d59589d9707d3a/addons/l10n_es_edi_facturae/__manifest__.py#L41
[^4]: https://github.com/odoo/odoo/blob/b991f766e28dc71f8627fdfbf2d59589d9707d3a/addons/l10n_es_edi_facturae/__manifest__.py#L16

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

Currently, in a continental perpetual setting for the stock valuation, the inventory valuation lines are not created when closing the session if the orders when not invoiced.

Steps to reproduce:
-------------------
* Using My Belgian Company
* In the settings search for inventory valuation
  * Set inventory valuation to Perpetual
  * Any cost method, AVCO for example
  * Set up valuation account and journal
* Create a product
  * Type -> Goods
  * Track inventory by quantity
  * Set a purchase cost
  * Put some quantity on hand
  * Add category
* In the settings of the category
  * Set up Stock account
  * Set up costing method, AVCO for example
  * Set inventory valuation to perpetual
* Open pos session
* Make an order for the product, put partner, invoice it
* Close session, go to session journal items
> Observation: Valuation lines are present
* Open pos session
* Make an order for the product, no partner, no invoice
* Close session, go to session journal items
> Observation: Valuation lines are missing.

Why the fix:
------------
When the company is set with perpetual inventory valuation, in the context of the point of sale, there should not be any difference between anglo saxon and continental accounting.

When we check the same flow with anglo-saxon, there is no difference for the creation of the inventory valuation move line whether we invoice the order or not. Inventory valuation lines are always present.

Valuation entries are created in `_create_stock_valuation_lines()` if information is available regarding `stock_valuation`. https://github.com/odoo/odoo/blob/51f1982367809581530e4d126ed515c0df6c4daa/addons/point_of_sale/models/pos_session.py#L1258-L1273

The information for `stock_valuation` is supposed to be computed in `_accumulate_amount()`.

However this is currently only computed when we have the anglo saxon accounting:
https://github.com/odoo/odoo/blob/51f1982367809581530e4d126ed515c0df6c4daa/addons/point_of_sale/models/pos_session.py#L953

Instead we will now only check if the company is valuating the inventory in real time.

We also apply the same fix on paid orders we want to invoice afterwards.

opw-5167946

Forward-Port-Of: odoo/odoo#240176

When exporting invoices, the VAT number of the company could be wrong if the fiscal position of the invoice defines a foreign VAT number. In that case we need to use it.

Steps to reproduce:
1. Install a European localization (ex: l10n_at)
2. Enable EU Intra-community Distance Selling. You should now have new OSS fiscal positions. Update the one you want to use with a foreign VAT.
3. Create a valid foreign customer. (within the EU)
4. Create and send an invoice for this customer.
5. In the PDF, there is an embedded factur-x file. Notice how the VAT number under the SellerTradeParty corresponds to the company's VAT, not the foreign VAT number defined on the fiscal position.

This is more apparent because we use the correct VAT number in the PDF file but not in the corresponding XML.

This commit fixes this issue by first checking if we have a foreign VAT number defined on the fiscal position of the invoice. If so, we use it.

opw-5182837

Forward-Port-Of: odoo/odoo#241436
Forward-Port-Of: odoo/odoo#236692

When creating a delivery slip, if the product sold is a kit and it's component doesn't have a description, the name will be repeated.

Steps to reproduce:
-------------------
* Create a product A with a bom of type kit
* Add a product "comp" in the bom (don't give it a description)
* Create a sales order with the product A and confirm it
* Go on the delivery and create a delivery slip
-> Issue, the name of the product "comp" appears twice.

Observation:
-------------
The name is added in description_picking field, since it is considered that the fallback for the description for outgoing deliveries should be display_name:
https://github.com/odoo/odoo/blob/584f94e3246b6b59641bf83d4e707f2e872bc1e8/addons/stock/models/product.py#L293-L301

In _compute_description_picking, information about the bom will be added :
https://github.com/odoo/odoo/blob/08c5fbbb5bc44c4810cd07188b29090c3060e14f/addons/mrp/models/stock_move.py#L235-L236

This causes the issue because the filter to prevent repeating the name on the delivery slip is implemented directly in the XML:
https://github.com/odoo/odoo/blob/08c5fbbb5bc44c4810cd07188b29090c3060e14f/addons/stock/report/report_deliveryslip.xml#L83-L85
However, since we have added elements to the description (the bom information), this filter will not be applied, leading to the repeated name.

opw-5265906

Forward-Port-Of: odoo/odoo#236948

Currently, an error occurs when a user attempts to pay an invoice.

**Steps to Reproduce ([Video](https://drive.google.com/file/d/1onmo1mxeZgH6fkQOoueGCgC67HPjYHX6/view)):**

 - Install the `Accounting` module.
 - Go to `Payment Terms` and create `a new Payment Term` with at `least two Due Term lines`.
 - Go to `Invoices` and `create a new Invoice`.
 - Add one invoice line and set the `Payment Term` to the `newly created payment term`.
 - In the `Journal Items` tab > `Enable the Due Date` column (optional hidden).
 - From the two `Receivable journal items`, remove the `Due Date` from one of the `receivable lines`.
 - Now `Confirm the invoice` and `Click on Pay`.

**Error:**
`TypeError: '<' not supported between instances of 'datetime.date' and 'bool'`

**Cause:**
This error occurs when the user clicks Pay, than it going to calculate the total amount to pay from here [1]. If the payment term has more than one term line, it creates more than one receivable invoice line, and the receivable invoice lines are sorted from here [2]. When two or more invoice lines have the same move_id, they are sorted based on the due date. However, if one of the receivable lines does not have a due date, the error is raised.
Similarly, as shown in [3], when the system retrieves the installment data, it sorts the lines based on the due date and raises the same error.

**Fix:**
This commit ensures that when there is no due date on any receivable invoice line and two lines belong to the same invoice, the comparison uses the maximum date as like here [4] and places that line at the end for that invoice, thereby maintaining the correct flow. The same fix is applied while retrieving the installment data, as described above.

[1]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/wizard/account_payment_register.py#L703

[2]- https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/wizard/account_payment_register.py#L635

[3]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/models/account_move_line.py#L3305

[4]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/models/account_move_line.py#L522

sentry-713241246

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

Forward-Port-Of: odoo/odoo#241744
Forward-Port-Of: odoo/odoo#241060

## Issue:
When exporting the XML for a VAT return, the client nihil field was incorrectly set to YES
According to Belgian regulations, this is only allowed on the last report of the calendar year
https://finances.belgium.be/sites/default/files/downloads/165-625-directives-2019.pdf

## Cause:
Prior to 18.3, nihil was a checkbox option on export
Since 18.3, it is automatically selected based solely on a price formula, without checking the report’s date

This PR brings back the Client Nihil checkbox in 19.0
But didn't change the default value
Causing the issue to still be present
https://github.com/odoo/enterprise/pull/99496

## Steps to reproduce:
- Select the Belgian company
- Open the Tax Return and select the VAT Return
- Click Returns and enter an opening date in January
- Click Review for the first available report
- Ignore errors and return to previous page
- Click on Submit -> Download XML
- Before the fix, ClientListingNihil is set to YES

## Potential remaining issue:
The legal document specify that it should also be checked in case of "cessation d’activité"
So it may be interesting to consider adding the option back

opw-5184056

Forward-Port-Of: odoo/enterprise#102482
Forward-Port-Of: odoo/enterprise#98982

**Step to reproduce:**

1. Install pos_pricer module:
2. Open the Point of Sale app and create a product.
3. Go to the Product Variants menu.
4. Open that product.
5. Activate developer mode.
6. Click on the Bug icon (top-right corner).
7. Click on Data.

**Issue:**

A traceback is raised with the error:
`Compute method failed to assign product.product(191,).pricer_display_price`

The method `_compute_pricer_display_price` was removed in this commit https://github.com/odoo/enterprise/commit/87b1672ac7c1d27cd9eab05138b78f6a9439fea7 , and was reintroduced
in a later commit https://github.com/odoo/enterprise/commit/4575d3dfdbd0ccd9bf57bddbd35a89bd47c48798 to avoid the AttributeError.

**Cause:**

The computed field `pricer_display_price` is a type Char and and is non-stored was not being assigned
a value inside the compute method. So ORM requires that records to be assigned a value in a compute method.

**Solution:**

To fix this, assign a default value to `pricer_display_price` inside the compute method to prevent the error.

opw-4887318

Forward-Port-Of: odoo/enterprise#90676
Forward-Port-Of: odoo/enterprise#88517

Related to https://github.com/odoo/odoo/pull/174844

Enteprise Related https://github.com/odoo/enterprise/pull/103014

I have created the following plugin for [fixit](https://github.com/Instagram/Fixit):
 - https://github.com/OCA/odoo-pre-commit-hooks/blob/main/src/oca_pre_commit_hooks/checks_odoo_module_fixit/prefer_env_translation.py

Where it identify all the `odoo._` cases and transform automatically to `self.env._`

Running the following command:
```bash
export FIXIT_ODOO_VERSION=19.0
find . -name "__manifest__.py" -execdir oca-checks-odoo-module-fixit --fix --enable=prefer-env-translation {} \;
git diff --name-only \
  | grep '\.py$' \
  | xargs ruff check --select F401 --fix
```

(We need to run 2 times since that if the same line that the same issue so it is fixed once)


# TODO
- [x] Wait to push all the cases

### Run autofixes for only files changed
- [x] Run autofix for imported but unused
```python
git diff odoo/master --name-only \
  | grep '\.py$' \
  | xargs ruff check --select F401 --fix
```
- [ ] Remove unicode literals from strings u''
- [ ] Missing whitespace around operator
- [ ] Trailing comma on bare tuple prohibited [enterprise/l10n_mx_reports/models/trial_balance.py:34](https://github.com/odoo/enterprise/blob/e5e365248daf59713d92c65f7ac024a4a9897c28/l10n_mx_reports/models/trial_balance.py#L34)