Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ADD] import your vendor bills from XMLs files #24303

Closed
wants to merge 1 commit into from

Conversation

Projects
None yet
6 participants
@smetl
Copy link
Contributor

commented Apr 18, 2018

@pedrobaeza

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2018

@alexis-via you would be interested in this

@pedrobaeza

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2018

UBL is a standard not only for Belgium AFAIK

@smetl

This comment has been minimized.

Copy link
Contributor Author

commented Apr 18, 2018

@pedrobaeza UBL has a lot of subsets and customizations for different countries. E.g. in Belgium, this customization is E-FFF.

@pedrobaeza

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2018

But isn't better to have the common standard in a module and only includes in l10n_be_* the subset? This way, when adding for example compatibility for UBL in France, you don't need to repeat code.

You can also check current OCA modules that we have for UBL compatibility (migration to v11 in progress, but similar to this v10 version):

https://github.com/OCA/edi/tree/10.0/base_ubl
https://github.com/OCA/edi/tree/10.0/account_invoice_import_ubl

@alexis-via

This comment has been minimized.

Copy link
Contributor

commented May 3, 2018

@smetl e-fff is just standard UBL 2.0 with a list of required fields. Country-specific stuff in UBL standard are pretty minor and are usually about:

  • country-specific identification numbers of companies
  • which fields are required, which fields are optional
  • exact nomenclature used for taxes (but, at least in EU, taxes are almost only VAT taxes and we can use the rate to find the corresponding taxes instead of the nomenclature)
  • the exact version of UBL used (2.0 for e-fff, but it's the same as 2.1 for the usual fields of an invoice)

That's why, in the OCA, 99% of the code for UBL is generic and only 1% is country-specific.

@smetl

This comment has been minimized.

Copy link
Contributor Author

commented May 7, 2018

@alexis-via I know, I know. At this moment, this stuff is only used in l10n_be but don't worry, the UBL standard will be in a dedicated module when it will be necessary.

@pedrobaeza

This comment has been minimized.

Copy link
Contributor

commented May 8, 2018

@smetl I think it's better to do it the best way from the beginning and avoid headaches later to the migration teams. This also will favor extensible community modules that don't depend on l10n_be* modules and with ugly patches. Can you please consider this?

@jco-odoo

This comment has been minimized.

Copy link
Contributor

commented Feb 20, 2019

@pedrobaeza @alexis-via I am trying to check the electronic invoicing standards more closely and I wonder if it would not be better to use the PEPPOL standard (based on UBL) instead of UBL, at least for the countries (Belgium, Norway, the Netherlands, France, Denmark, ...) that support it.

PEPPOL also has an eDelivery network however based on AS2 and if you have any ideas about that, it would be nice to know about it. It is a little more complicated of course than sending a mail with a pdf+xml as with Factur-X, but that way you know it has been received correctly as well. (to the government e.g.)

@pedrobaeza

This comment has been minimized.

Copy link
Contributor

commented Feb 21, 2019

Let me research about this format and tell you back.

@alexis-via

This comment has been minimized.

Copy link
Contributor

commented Feb 21, 2019

@jco-odoo PEPPOL is a great initiative to have both an e-invoicing standard and an interoperable transmission protocol. PEPPOL uses UBL with it's own CIUS (Core Invoice Usage Specification). Respecting the PEPPOL CIUS is certainly a good thing to do, because these are field-proven CIUS that have a large adoption.
PEPPOL was initially designed as a transmission protocol for B2G (business to governments) but it's now adopted for B2B in some countries. I heard that it's adopted as the interoperability channel for private invoicing operators: instead of setting up private P2P communication channels between invoicing operators, they all connect to PEPPOL and it allows them to exchange invoices directly in a standard and interoperable way.
Currently, PEPPOL has a wide-spread adoption in Norway (B2G and B2B), a small adoption in some countries of northern Europe, and no adoption at all for the moment in France and other countries of southern Europe. That's why I haven't worked on PEPPOL CIUS myself so far, but it is on my roadmap for the OCA/edi stack.

But, what we really need from Odoo in the short term, is a better Factur-X implementation. I'm not talking about the PDF part ; I know that PDF/A-3 is not an easy topic. I'm talking about the XML part: your implementation still lacks the nomenclature. Odoo must implement the nomenclature for unit of measures, taxes and payment methods. Otherwise, the XML file embedded in the PDF will not be complete/valid. The good news is that this nomenclature is common for UBL and CII/Factur-X.

FYI, the OCA implementation for the nomenclature is available in https://github.com/OCA/community-data-files:

  • for unit of measures, it is the module "product_uom_unece"
  • for taxes, it is the module "account_tax_unece"
  • for payment methods, it is the module "account_payment_unece"
    These modules are already available for v12 (or have a PR waiting approval).
    When you will implement the nomenclature for taxes, it will allow localization to add the nomenclature on the tax templates they provide and will avoid maintaining OCA modules to add nomenclature on taxes (see for example the module l10n_fr_account_tax_unece (OCA/l10n-france#175).

So my advice is: adopting PEEPOL CIUS is great, settings up PEPPOL gateways would be great too, but let's start to fix what is currently broken in the Odoo e-invoicing stack: the XML of your Factur-X invoices that lack the nomenclature.

@pedrobaeza

This comment has been minimized.

Copy link
Contributor

commented Feb 28, 2019

I don't have anything more to add apart from what Alexis has said, which is the great expert here. Josse, tell us if you want us to make any PR adding these UNECE related stuff.

@jco-odoo

This comment has been minimized.

Copy link
Contributor

commented Feb 28, 2019

Thanks a lot for your explanation @alexis-via . The reason unece was not done before in Factur-X, is that the fields themselves are not required and put a lot of extra fields/clutter in the code. We have branches somewhere where it was added too, but were never merged.

For the UoMs it would be quite straightforward, but for the taxes and the payment methods it seems a lot more complicated. For the taxes it would also mean letting depend localizations on a unece/factur-x module so we can set the fields in the tax templates, so there is quite some localizations to adapt then? And do we need code.list or can we just use selection fields?

Would it improve for the import of invoices, because in practice most accountants probably still verify it. Or are you sending factur-X to the government somehow where you get a bad response?

@alexis-via

This comment has been minimized.

Copy link
Contributor

commented Mar 6, 2019

@jco-odoo About UNECE data on UoM, taxes and payment methods:

  1. if you want to generate a Factur-X invoice profile EN 16931 that really comply with EN 16931, these data MUST be provided. If you test the factur-x.xml file generated by Odoo v12 against the official CII schematron of EN 16931 that is available here https://github.com/CenPC434/validation/tree/master/cii you will see that the XML part of Odoo invoice is not compliant for that reason. If you don't want to loose time to install the Java tools for schematron, you can use this Factur-X validator https://services.fnfe-mpe.org/ which uses the schematron to test the XML part.
  2. if you add the UNECE fields on taxes, it will allow localisations to provide this data on taxes, but it won't oblige localisations to depend on the module account_facturx and it won't oblige localisations to provide the UNECE data on taxes ! And, in the code of the module account_facturx, you can make sure that if these fields stay empty, you would not raise an error but just not set the corresponding XML tag. That way, Odoo users that set the right value for UNECE fields on their taxes (manually or via the localisation) would generate compliant Factur-X invoices ; those who don't set UNECE data on they taxes would generate not-compliant Factur-X invoices, just like in Odoo v12. For me, there is no problem here.
  3. Adding the UNECE field on payment.method is easy : no impact on localisations, only 1 new field to set on module that add a payment method (and this field can stay optional).
@jco-odoo

This comment has been minimized.

Copy link
Contributor

commented Mar 6, 2019

@alexis-via But about the taxes, what is the reason for the type and category to use Many2one instead of selection fields?

Do you have these only for the French localizations or others as well? Is it difficult to determine them?

@jco-odoo jco-odoo referenced this pull request Mar 12, 2019

Open

Master unece jco #31788

@william-andre william-andre force-pushed the odoo-dev:master-edi-import-las branch from 4c4cb42 to 7d49380 Mar 19, 2019

@robodoo robodoo added the seen 🙂 label Mar 19, 2019

@william-andre william-andre force-pushed the odoo-dev:master-edi-import-las branch 4 times, most recently from 311d008 to d55c51e Mar 20, 2019

@robodoo robodoo added the CI 🤖 label Mar 21, 2019

@qdp-odoo
Copy link
Contributor

left a comment

few changes to do before I even consider the PR

  • setting option "allow to import xml bills" is useless as the "import bills" button is already there with account module
  • account_invoice_import_xml is useless as account_facturx is auto installed, and the UBL import should plug into (l10n_be_edi depends on account_facturx)
  • XSD of l10n_be_edi shouldn't in data, as there are large files that would make big blobs in the repo. Use instead what we've done for l10n_mx_edi (see post_init hook): download the files at install

thanks :-)

@jco-odoo

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2019

@qdp-odoo We should not merge this, but think about a more generic concept instead as there is now a CIUS which allows one core specification for a lot of European countries which gets adaptations by country.

@robodoo robodoo removed the CI 🤖 label Mar 25, 2019

@william-andre william-andre force-pushed the odoo-dev:master-edi-import-las branch from fc347f4 to 6e209f2 Apr 1, 2019

robodoo pushed a commit that referenced this pull request Apr 4, 2019

[ADD] l10n_be_edi: allow import of XMLs as Vendor Bills
Task 1823110
New module to import bills in the belgian e-invoice format.

Author: las@odoo.com
Co-Author: wan@odoo.com

closes #24303

Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
@robodoo

This comment has been minimized.

Copy link
Contributor

commented Apr 4, 2019

Staging failed: ci/runbot on 714ad5b4d8b43b5bb895e78fa7d75be5e2d7baff (view more at http://runbot.odoo.com/runbot/build/493481)

@qdp-odoo

This comment has been minimized.

Copy link
Contributor

commented Apr 4, 2019

@william-andre test failed in staging (but passed on the PR). A rebase might be necessary

@robodoo retry maybe

@robodoo

This comment has been minimized.

Copy link
Contributor

commented Apr 4, 2019

Staging failed: ci/runbot on a7e867df9b6caeebc315315f62b388c150cbdc74 (view more at http://runbot.odoo.com/runbot/build/493519)

@robodoo robodoo added the error 🙅 label Apr 4, 2019

@william-andre william-andre force-pushed the odoo-dev:master-edi-import-las branch from 09bfea6 to d99cdbf Apr 5, 2019

@robodoo robodoo removed the error 🙅 label Apr 5, 2019

[ADD] l10n_be_edi: allow import of XMLs as Vendor Bills
Task 1823110
New module to import bills in the belgian e-invoice format.

Author: las@odoo.com
Co-Author: wan@odoo.com

@william-andre william-andre force-pushed the odoo-dev:master-edi-import-las branch from d99cdbf to 9eb500c Apr 5, 2019

@robodoo robodoo added the CI 🤖 label Apr 5, 2019

@qdp-odoo

This comment has been minimized.

Copy link
Contributor

commented Apr 5, 2019

robodoo pushed a commit that referenced this pull request Apr 5, 2019

[ADD] l10n_be_edi: allow import of XMLs as Vendor Bills
Task 1823110
New module to import bills in the belgian e-invoice format.

Author: las@odoo.com
Co-Author: wan@odoo.com

closes #24303

Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
@robodoo

This comment has been minimized.

Copy link
Contributor

commented Apr 5, 2019

Merged, thanks!

@robodoo robodoo closed this Apr 5, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.