# CONTEXT
The refactor PR https://github.com/odoo/odoo/pull/191911 introduced a nice/needed refactor of the fetchmail methods.

But in doing so a small logic error sneaked in.
More specifically:
This try/except/else block
https://github.com/odoo/odoo/blob/1f672b95a145b32d1ef2da9e83d82cd950045b5d/addons/mail/models/fetchmail.py#L305-L313 fails to account for the fact that in certain conditions a exception is expected while the `message_process` methods try to match the mail content with Odoo records.

One example:
If you fetch an email in the inbox that is addressed to an email address that is **not** an email alias in the database, it will raise a ValueError. Example:
```
ValueError: No possible route found for incoming message from "John Doe"
<john@example.com> to "Josephine" <mon_amour@odoolove.com>
(Message-Id <shrekislove@odoo.com>:). Create an appropriate mail.alias
or force the destination model.
```

It follows that the `else` block is never triggered and `handled_message` will not be called, which would have marked the email in question as "READ".

This means, that the next time the fetchmail CRON job runs, it will retry to refetch the same (failing) emails, which A) means lost time and processing time for a non relevant email B) if the backlog of failing emails is important enough, it will clog the mail fetching and we will never reach new emails.

## Proposed fix:
Remove the else block, meaning that the `handled_message` get's called even after an exception.

A this level of the stack we presume that any exception is either expected or the results of a misconfiguration (mail flows or Odoo configuration). So the mail was handled and should be marked a read in the mailbox being fetched.

OPW-5122869

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

Forward-Port-Of: odoo/odoo#230486

**Steps to reproduce:**
- Install Accounting and l10n_mx_edi_stock_30
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)

- In Accounting settings, select "Solucion Factible" as PAC
- Create a product:
  * Product Name: XYZ
  * Product Type: Storable Product
  * UNSPSC Category: 25101929 Mobile office van
  * Tariff Fraction: 0101299999 Los demás.
  * UMT Aduana: Units
  * Weight: 1.00

- Go to "Inventory / Operations / Transfers / Deliveries"
- Create a delivery:
  * Delivery Address: [a Mexican contact] (e.g. INMOBILIARIA CVA)
  * Product: Product XYZ
  * Transport Type: Federal Transport
  * Vehicle Setup: [something] (e.g. [ABC123] DEMOPERMIT)
  * Gross Vehicle Weight: [anything]
  * Distance to Destination (KM): [anything]
- Validate the delivery
- Generate Delivery Guide
=> CFDI document should be created and signed by the government
- Print Carta Porte

**Issue:**
The "CCP ID" in the PDF is different than the one in the CFDI sent to the government.
Each time the Carta Porte is printed, a new "CCP ID" is generated and use in the PDF.
This also leads to a different QR-code in each PDF.

**Cause:**
When the Carta Porte is printed, instead of fetching the data from the existing CFDI document, they are recomputed.
The problem is that "l10n_mx_edi_idccp" field is a non-stored computed field and its value is a RFC 4122 identifier.
Each time the compute method is called, a new identifier is generated.

**Solution:**
When printing the Carta Porte, retrieve "CCP ID" from the existing CFDI document.

opw-5208648

Forward-Port-Of: odoo/enterprise#99034
Forward-Port-Of: odoo/enterprise#98920