account_invoice_import : improving handling of simple PDF invoices

[alexis-via]

This issue is about PDF supplier invoices that don't have any XML attachment. For those invoices, we have 2 modules:

• account_invoice_import_invoice2data
• account_invoice_import_simple_pdf

So far, I have always considered that account_invoice_import_simple_pdf would replace account_invoice_import_invoice2data. But, following discussions with some users, I'm starting to change my mind. Each module has it's own advantage:

• account_invoice_import_invoice2data: ability to share invoice templates among different Odoo servers by sharing the yaml files
• account_invoice_import_simple_pdf: ability to add support for a new vendor without technical skills

So it could be interesting to be able to use the 2 modules on the same Odoo server:

1. if the PDF invoice can be read by an invoice2data template, use it
2. otherwise, try to find a simple_pdf configuration

Technically, it may be as simple as removing the following raise in account_invoice_import_invoice2data: https://github.com/OCA/edi/blob/14.0/account_invoice_import_invoice2data/wizard/account_invoice_import.py#L56

Another related topic: If there is no invoice2data template nor simple_pdf configuration, we raise an error, cf https://github.com/OCA/edi/blob/14.0/account_invoice_import/wizard/account_invoice_import.py#L97
Starting from Odoo v13, it is possible to create an "empty" draft invoice with the PDF as attachment without partner and without any line. This is what Odoo EE does when it is unable to recognize the invoice.

Advantages:

• if you have setup a mail gateway to create vendor bills, you get all the PDF invoices that you receive as draft invoice (currently, the PDF invoices which are not "recognized" are skipped and the accountant has no way to see it in Odoo, cf https://github.com/OCA/edi/blob/14.0/account_invoice_import/wizard/account_invoice_import.py#L1420)
• if you are importing the PDF invoice manually via the Invoice import wizard, you avoid the error message of the wizard and you save a few seconds creating the vendor bill manually and adding the PDF invoice as attachment (of course, you still have to select the partner, set the date and create the invoice line manually).

Drawback:

• If you use the mail gateway, any spam that has a PDF attachment will create a draft vendor bill !

It would be interesting to have the feedback of people who have used Odoo EE to know their opinion about these draft empty invoices.

[avmediadesign]

Being able to handle all invoices (via e-mail gateway or manual import) regardless if there is or not an invoice2data template or simple_pdf configuration would be an valuable enhancement.
The fallback to empty draft invoices would then mimic the first step when importing invoices in Odoo EE.

[TeoGoddet]

Odoo v14 has a mechanism to plug multiple invoice reader when mails are received

See #566
https://github.com/odoo/odoo/blob/540dc692495928fedb297d5b0f2a31ddfd590976/addons/account/models/account_move.py#L3468
def _message_post_after_hook(self, new_message, message_values):
# OVERRIDE
# When posting a message, check the attachment to see if it's an invoice and update with the imported data.
res = super()._message_post_after_hook(new_message, message_values)

    attachments = new_message.attachment_ids
    if len(self) != 1 or not attachments or self.env.context.get('no_new_invoice') or not self.is_invoice(include_receipts=True):
        return res

    odoobot = self.env.ref('base.partner_root')
    if attachments and self.state != 'draft':
        self.message_post(body=_('The invoice is not a draft, it was not updated from the attachment.'),
                          message_type='comment',
                          subtype_xmlid='mail.mt_note',
                          author_id=odoobot.id)
        return res
    if attachments and self.line_ids:
        self.message_post(body=_('The invoice already contains lines, it was not updated from the attachment.'),
                          message_type='comment',
                          subtype_xmlid='mail.mt_note',
                          author_id=odoobot.id)
        return res

    decoders = self.env['account.move']._get_update_invoice_from_attachment_decoders(self)
    for decoder in sorted(decoders, key=lambda d: d[0]):
        # start with message_main_attachment_id, that way if OCR is installed, only that one will be parsed.
        # this is based on the fact that the ocr will be the last decoder.
        for attachment in attachments.sorted(lambda x: x != self.message_main_attachment_id):
            invoice = decoder[1](attachment, self)
            if invoice:
                return res

    return res

[TeoGoddet]

We are using odoo empty invoice and we like it.
Odoo can set the partner based on the email.
We would love to be able to use advanced decoders such as simple_pdf the same way.
The is also a decoder for swiss qr invoice that is being created in the ch loc

[TeoGoddet]

Here is what I think about how the invoice processing should be done and split between the repos

We should rely on odoo only if the decoders api are stable enough.

@alexis-via what do you think of this ?

Odoo decoders are registered here : https://github.com/odoo/odoo/blob/6743f3084f509733d563c26655f4ce6aa00695fa/addons/account/models/account_move.py#L3487
Here is an example of a decoder (odoo edi) : https://github.com/odoo/odoo/blob/522067b2cf5f3484c60cd3e73785a4adb15bf3e7/addons/account_edi/models/account_edi_format.py#L449

Main Tasks :

• edi framework invoice processor using odoo decoders
• plug the account_invoice_import wizard into odoo decoders
• register account_invoice_import_* as odoo decoders

[pasgou]

@TeoGoddet
That's what I ask for since years but without any answer.
The most important part is that if the document is not compliant with a model (and it is difficult to create those models), the only solution is a message. Frustrating and Lost of time.

[alexis-via]

I fully implemented what I described in this ticket on this PR: #630

[pasgou]

Hello, what about 12.0 CE?

[bosd]

So far, I have always considered that account_invoice_import_simple_pdf would replace account_invoice_import_invoice2data. But, following discussions with some users, I'm starting to change my mind. Each module has it's own advantage:

Glad that you see an place for both of them. 😉
My 2 cents on tis topic. The invoice2data is much more capable and flexible, as it is capable to import invoices on a line level. (see my pr on this).
The module is relatively quick as well. As opposed to enterprise edition.
However, the big disadvantage is that it is very hard to create the yml files.
It should be on a level, that a functional consultant / accountant can make one.

I am playing with the thoughts of making a template builder wizard module.
An invoice is basically an adress block. Some key value pairs, with an table like structure down below.
An guessing mechanism style wizard could be made to recognize the key values, generate a regex and store it in the db.

As an example, we know what kind of value we expect. We can lookup the key.
Basic example:
Dutch: Factuurdatum. 18/07/2022
English: Invoice date: 18/07/2022
(Odoo has already some translations in place to suggest a matching mechanism.)
As another example, odoo already has some code in place to validate VAT numbers.
Thus we could write a mechanism to parse all the extracted text from the invoice, when a valid VAT number is found. Create the corresponding regex.

For the table like structure, I'm working on integrating camelot table parsing into invoice2data.
From a code perspective, a lot of code from account_invoice_import_simple_pdf could be re-used for a invoice2data template builder.
@alexis-via What do you think of refactoring the account_invoice_import_simple_pdf to an invoice2data template builder module?

I like the proposal of @TeoGoddet .
Out of curiousity Is it possible to use the oca modules on the enterprise edition?
For example if Enterprise fails, can it fallback to use the oca import methods?

[bosd]

Also, let's import the invoice's when not all the invoice lines can be matched to a product.
#604

[github-actions]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.