account_invoice_import: use native odoo invoice email hook

[TeoGoddet]

Odoo provide some hook to plug email invoice decoder
https://github.com/odoo/odoo/blob/540dc692495928fedb297d5b0f2a31ddfd590976/addons/account/models/account_move.py#L3468

I was wondering why not using them to plug mail invoices into this module.

What do you think of this ?

I may carry on some work on this to have native integration.

[bosd]

I like the idea!
If i remember there was somewhere a discussion about thr refactoring of these edi modules.

Some are quite complex. Some functions can be handled on core now?

[TeoGoddet]

This is the thing that run on new message on invoice :

    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

[bosd]

Have you seen this? #246
I don't have enough knowledge ,but my question is.. Is that code still needed or will the transfer of the invoices be handled by the (new) oca edi module?

[TeoGoddet]

You mean this module : https://github.com/OCA/edi/tree/14.0/edi_oca
Indeed we could create a new backend type email (like storage and webservice)

But then account_invoice_import should provide components for edi_oca to process documents.

I really like this separation between getting/sending docs and processing them.

I'm tagging @simahawk regarding the new backend type.

[simahawk]

There are 2 different things here:

1. refactoring existing modules to reuse odoo core features
2. plug such modules into the edi framework

Point one is the main subject of this issue.
Point two is another story. For the long term we might want to re-factor all modules to be based on edi framework (eg: always generate an edi.exchange record) -> to be discussed. Good topic for the OCA days in October ;)

For integrating them, you can reuse all their features (maybe some little changes / fixes required) in a glue module as I did here for sale_order_import https://github.com/OCA/edi/blob/14.0/edi_sale_order_import/components/process.py -> reuse the same wizard.

See also my comment here #246 (comment)

[simahawk]

To answer your question regarding the backend type: it should be done per macro area (eg: standard/format).
For instance here https://github.com/OCA/edi/tree/14.0/edi_ubl_oca/data we have a base module for UBL exchanges and here https://github.com/OCA/edi/blob/14.0/edi_sale_order_import_ubl/data/edi_exchange_type.xml I define a default exchange type for sale order import.
Fact is: the base module (in this case account_invoice_import) is totally independent from this and it kicks in when you combine an exchange type w/ the components.

[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.