Proposed changes for account_invoice_import v16

[alexis-via]

As I said in my PR #753 which contains the migration of the module account_invoice_import to v16, I plan to make several important changes. Here are my ideas, ordered from highest importance to lowest importance :

1. Remove the "Update" scenario. Currently, there is a "Create" and an "Update" scenario. The "Update" scenario corresponds to the scenario where a draft invoice is created from the purchase order and you want to update it with the real invoice received from the supplier. My idea would be to keep only the "Create" scenario. When the supplier invoice is linked to a PO, we would NOT use the button on the PO to create a draft invoice ; instead, we would import the supplier invoice as a new invoice and then we would start a wizard that makes the links between the invoice lines and the purchase order lines and compare the prices. This wizard would be independent from the account.invoice.import wizard.

2. the object account.invoice.import.config would become optional. So it would be possible to import a supplier invoice without an account.invoice.import.config. The logic would be the following:

• if the pivot format contains several lines -> multi-line import. Otherwise -> single line import.
• if the pivot format contains information about the product -> try to match an existing product. If no product matches or if there is no information about the product in the pivot format -> create invoice line without product, using the account from the first invoice line of the previous posted invoice of the same supplier (and otherwise use the default expense account of the company). Same logic if there is no product and the pivot format doesn't contain any information about the tax: use the tax from the first invoice line of the previous posted invoice of the same supplier ; otherwise use the default purchase tax of the company.

3. Change the datamodel of the account.invoice.import.config:

• remove the field "invoice_line_method"
• add a boolean field "Force single line". When importing a supplier invoice with a pivot format that contains several lines and this option is checked, Odoo would create a single line invoice.
• the field static_product_id would be renamed to "product_id": it would be used when there is no product information in the pivot format or when the product information in the pivot format doesn't match any existing product.
• same for the field "account_id" : it would be used when we could not set a product on the line and therefore we couldn't get the expense account from the product.
• same for field "tax_ids" : it would be used when we could not set a product on the line (so we couldn't get the purchase taxes) and there was no tax info in the pivot format (or that information didn't match an existing tax).

4. Use a warning banner for import warning. In the current implementation, import warnings are written in the chatter. But we can't expect users to read the chatter after every import. So it would be better to have a yellow warning banner on the invoice that contains a list of the invoice import warning. We would have a button to wipe the invoice import warning once the user has taken them into account (so we would continue to write the warning in the chatter).

5. in the current implementation, when importing an electronic invoice of a new supplier, the wizard proposes to create a new supplier (or update an existing supplier) ; if the user opts for creating a new supplier, Odoo displays the form view of a new partner with a default value for the name, VAT and all the other partner information that Odoo could get from the pivot format. Then the user can finalize the configuration of the partner (fiscal position, payment mode, bank account, etc...). After that, the user has to start the wizard again and import the electronic invoice a second time. To avoid that, I propose another implementation: the supplier invoice is created with partner_id=False (like for the mail gateway) and the default vals to create a new partner is stored in a new dedicated JSON field. A button on the invoice form view (displayed only when the JSON field has a value and partner_id=False) allows to create a new partner. Another button on the form view of the invoice allows to "Update" the invoice : in reality, it won't "update" the invoice, but it will delete and re-import it. This button would also be useful when the invoice has been imported via the mail gateway and the partner has several invoice import configuration and the first one was taken by default, and the user wants to switch to another import config.

I have another idea to simplify and improve usability, but I'm not sure it's a good idea: drop the object account.invoice.import.config and move its fields to res.partner with company_dependent=True. Advantage of this change: give more visibility to the fields of account.invoice.import.config. Drawback: it removes the ability to have several different account.invoice.import.config for the same partner. In real life, the only case where you need to have several account.invoice.import.config on a partner is when you have a partner that provides you, on a regular basis, several different services on separate invoices and you don't try to match products. I think it rarely happens.
As I said, I'm not sure this change would be a good idea. As account.invoice.import.config would become optional, giving more visibility to it is not as important as before. But I would be happy to have you opinion on this idea anyway.

I'm waiting for your feedback on these proposed changes!

[alexis-via]

@bosd please give your opinion !

[bosd]

Thanks @alexis-via for your detailed write-up. Plans & Ideas to improve usability.

1. Remove update scenario

I'm neutral on this one. In micro organizations the outlined flow (problem) is not applicable.
I'm for simplifaction. On the other hand, the Update scenario makes sense. For example as implemented in Enterprise, where the attachement can be re-ocr'd.

2. object account.invoice.import.config would become optional.

IMO, This is a big improvement. Very much welcomed. It would greatly improve the useability.
Preveting one to make almost similar configs for a lot of partners.

3. Change the datamodel of the account.invoice.import.config

This change would be an optional one for me.
I slightly tend to prefer to stick to the current model. As it leaves room for more flexibility.
Example. Received an invoice from a supplier. You know the products on the invoice from this vendor cannot be matched. But you want to actually import it as a multiline import.
So one could manually assign the proper (analytic) accounts to the lines.
Using a config "multiline no product" could be benificial in such case to reduce noise in the chatter.

I have one suggestion to add to the model.
While using invoice2data to import (or maybe also with others) there is not always an uom available.
Which leads to filling the chatter with a message that the "none" uom cannot be found. Instead the UOM "Units" is being used.
I would like to have an option to set the default uom for a supplier. So these chatter messages will be muted.

4. Use a warning banner for import warning.

 I'm not botherd by the chatter messages. I'm in the camp of "extracting as much info from the invoice as possible" don't let it fail on missing products, u.o.m. or taxes.
 Just auto import as much as possible and deal with the exceptions manually.
 
 In the current situation import is failling too quickly.
  One import error will result in an import failure. (e.g. Missing tax line, unmatched product ect.)
 Which means it is impossible to make corrections.
 The user is left to encode the whole invoice manually.
 (Which is a lot more work, and error prone as opposed to making corrections.)
 
 For the exception handling, there are already modules which can handle that after the fact occured.
 One could implement it according to their own use case / business needs.
This could for example be achieved by this module:
 https://github.com/OCA/account-invoicing/blob/14.0/account_move_exception
 
 

5. wizard proposes to create a new supplier

 Need to give this more thought to form an opinion.
 Personally I'm mainly using the uploadscript or file import. Yes, the workflow could maybe be improved.
 Maybe there is an (easier to implement? option) . To send back the user to the import screen after creating/updating the supplier.
 
 A "real" update of invoice import could still be beneficial. For example when using the invoice2data or import_simple module.
 One has made small improvements on the template and wants to update the previously imported invoice.
 

6. drop the object account.invoice.import.config and move its fields to res.partner

 This makes sense and improves usability. Indeed the cases when multiple different import configs are required on the same vendor are really rare.

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

[bosd]

@alexis-via Where you able to incorporate these changes into the code somewhere?

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