PDF/A no embedded XML

[oca]

PDF/A no embedded XML

[alexis-via]

Yes, I use veraPDF to check that it's a valid PDF/A file.

To generate a valid PDF/A file with Odoo, I use the py3o reporting engine (via the module "report_py3o_fusion_server" cf https://github.com/OCA/reporting-engine/tree/10.0/report_py3o_fusion_server) and I configure the PDF export options in the py3o configuration in Odoo to generate PDF/A (almost all the PDF export options of libreoffice are available in Odoo/Py3o). AFAIK, it's not possible to generate a valid PDF/A file with the default reporting engine of odoo (qweb + mkhtmltopdf). Note that, AFAIK, the OCA runbot doesn't have a fully configured py3o reporting engine with report_py3o_fusion_server because it requires several py3o software components and a headless libreoffice server running in the background.

The demo invoices of Factur-X are generated with Odoo v10 + py3o cf http://fnfe-mpe.org/wp-content/uploads/2018/11/5.-FACTUR-X-V1.0.3-Examples-2.zip

But generating valid PDF/A with py3o + Odoo only works with a Factur-X invoices ; it currently doesn't work with an UBL Sale order (but it should not be so difficult to develop if it's really needed).

[OSevangelist]

Hi @alexis-via thanks for the prompt response i already thought this (i.e. reporting engine) may be the reason of it and given your explanation it makes perfect sense why it doesn't work on the runbot and neither on our landscape (i don't like java stacks on our landscape ;-) However, the py3o report engine afaik has so many advantages that its maybe worth to review the rule of thumb there. We will definitly give it a try and if you don't mind propose a change to the README to avoid misunderstandings on this right from the beginning. Thx a lot !

[pedrobaeza]

I also don't like to put Py3o for only generating Factur-X. Can you tell me then how Odoo is getting Factur-X in their module https://github.com/odoo/odoo/tree/12.0/addons/account_facturx?

[alexis-via]

The factur-X standard says that you should use PDF/A. With the qweb reporting engine (and therefore also with the account_facturx module of Odoo v12), it is not possible to produce PDF/A, so the Factur-X invoices produced by these systems is not 100% compliant to the Factur-X standard... but I don't think it's a big deal !
For me, it's like a web page that is not compliant according to the W3C HTML validator (https://validator.w3.org/) : it still works very well most of the time with all browsers ! The important thing is to have a valid XML file and put it as attachment in the PDF with the correct filename "factur-x.xml".

[pedrobaeza]

Thanks for the clarification, @alexis-via

Spanish government is thinking about adopting Factur-X as the digital invoice format deprecating the bad FacturaE one, but it's not yet approved. If so, I will come back to this and check possibilities.

[OSevangelist]

@alexis-via ok, but does that mean that even though qweb reporting engine won't produce valid PDF/A it still somewhat correctly attached XML underneath the PDF? (and if yes, how do you actually check this w/o verapdf... Hexeditor ;-) ).

Assuming that i understood you correctly i wouldn't either mess too much with standard compliance and stay with standard qweb instead (especially if i know how to potentially get it right running the extra mile).

@pedrobaeza for the spanish goverment this is good news

[alexis-via]

@OSevangelist yes, if you use the Qweb reporting engine with the OCA/edi modules, it will generate a valid "factur-x.xml" file and it will correctly attach it in the PDF. You can check that with any modern PDF reader that can show PDF attachments (evince, okular, Acrobat Reader, Firefox, SumatraPDF).

My opinion is the following : it's always better to be 100% standard compliant, but it's not a big deal if you're not fully PDF/A-3 valid according to veraPDF. The important thing is to have a good embedded XML file with all the information and widen the use of the Factur-X standard to have as many invoice in this format as possible.

The real problem in my opinion is the account_facturx module of Odoo 12 that has a poor XML without the nomenclature for unit of measures, taxes and payment methods: it will limit possibilities for customers that receive these invoices (for example, they will not be able to set the correct unit of measure on the invoice line when importing such an invoice). I warned Odoo R&D about this in July/August 2018 (so before the release of Odoo 12), but they didn't listen :-(

[alexis-via]

@OSevangelist FYI, there is a Factur-X Hackathon in Paris on January 24/25 (http://fnfe-mpe.org/evenements/hackathon-factur-x/). The event is free. I'll be there during the 2 days.

[OSevangelist]

@alexis-via are you aware of some similar thing in Germany. As far as i remember the Zugferd guys were joining the french people to merge it to facture-x in the first place. I found that obiously some Germans are going to attend the meeting as well

https://www.xing.com/communities/posts/hackathon-in-paris-24-punkt-strich-25-punkt-01-punkt-2019-1015785968

Unfortunately i won't make it that date but maybe next time. Please be so kind and inform me as soon as you become aware of a subsequent workshop on the matter. Best Frederik

[OSevangelist]

The real problem in my opinion is the account_facturx module of Odoo 12 that has a poor XML without the nomenclature for unit of measures, taxes and payment methods: it will limit possibilities for customers that receive these invoices (for example, they will not be able to set the correct unit of measure on the invoice line when importing such an invoice). I warned Odoo R&D about this in July/August 2018 (so before the release of Odoo 12), but they didn't listen :-(

Unfortunately knowing everything (or many things) better and often inventing the wheel twice seems to be a kind of the ingrained strategy of S.A. I personally don't think it is only reluctance or misunderstanding but the real reason is, they want to keep their code free of even the smallest slice of foreign code (even if contributed under all terms) for some reason. Applies to many artifacts like MRP, product configurator and facture-x. Maybe partly they want to keep community members busy with dealing with these senseless obstacles that distracts them from doing other even greater things.... At least economically that is a crystal clear case of lost overall wellfare

[alexis-via]

I can only agree with your last comment...

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