Closed OSevangelist closed 2 years ago
OSevangelist
commented
5 years ago @alexis-via i hope that kind of clarifies the matter. I could ask Amjad in my team to test it against the validator or do you already have an idea why it probably wont work. If what i wrote is not clear enough please don't hesitate to ask
OSevangelist
commented
5 years ago Hi @alexis-via i just wanted to inform you that i we have invested on considerable amount of time on the specs of XRechnung and we are now do more or less understand the boundaries of Facture-X / ZugFERD 2.0 and xRechnung. Long story short: xRechnung is another Standard that specifies an invoice as an machine-readable XML. It defines a set of +50 business rules that the XML needs to follow (apart from being a syntactically correct XML according to one of 3 standards, UBL is just one (probably the most widely used one) of).
Having said this xRechnung needs a considerable amount of implementation time assuring the validity of the information that goes into the XML generation process. Right at the moment one would be able to generate an invoice that would be a correct invoice in simple fiscal terms using Odoo that you may safely transform into a Facture-X invoice using your set of modules but that still break a considerable amount of the aforementioned business rules. We are currently working on assuring the syntactical correctness of the information in the UI stage of Odoo even before any invoice is being generated. This is required to ultimately implement xRechnung for Odoo.
According to our actual task back log we may come back on the matter in decembre or early 2020. In any case if you have questions just drop me a comment
alexis-via
commented
4 years ago @OSevangelist Thanks for your messages. Could you give few examples of business rules that you need to implement in Odoo to be fully compliant with xRechnung ? I have such business rules in my module l10n_fr_account_chorus (https://github.com/OCA/l10n-france/tree/10.0/l10n_fr_chorus_account) to generate invoices compliant with Chorus Pro, the e-invoicing plateform of the French administration. But these rules are specific to Chorus... I also have a few in account_invoice_factur-x (for example : prices can't be negative ; only qty can be negative). But I don't have so many of them...
alexis-via
commented
4 years ago I also want to add that I'm very glad that German community members are now getting interested in e-invoicing ! I feel that Germany is an important player in e-invoicing in Europe and you are genius because you invented the ZUGFeRD standard, which is the best concept I've seen so far in electronic invoicing (PDF invoice with embedded XML). I think that wide use of e-invoicing is only possible with ZUGFeRD/Factur-X ; I don't think that pure-XML invoices are the future for real-life B2B usage. The failure of e-fff standard in Belgium (XML invoice with PDF in base64 in the XML !) is one example ; seems Belgian people never heard of it (my PR for e-fff support in Odoo never got any interest from Belgian OCA members https://github.com/OCA/l10n-belgium/pull/60). xRechnung will certainly be used in B2G, but I don't think it will be a leading standard for B2B.
I was a bit disappointed to see that, when I developed the OCA modules account_invoice_zugferd on Odoo v8, nobody seemed to care in the German OCA community... and glad that you guys are now in the race for electronic invoicing !
github-actions[bot]
commented
2 years ago 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.
Scope @alexis-via and me were discussing about the XRechnung standard briefly during OXP 2019.
I took the task to review the current status of the spec and make sense on how this relates to Facture-X.
Reasoning
There is quite a bite of information (though on German) on the following web page
The governmental entity "Koordinierungsstelle für IT-Standards" is coordinating the efforts. XRechnung is an XML-only standard (i.e. no encapsulating PDF like in Facture-X) that refers to the same European Standard EN 16931 as Facture-X / ZugFERD does.
The following link (also GERMAN)
basically says that Facture-X / ZugFERD 2.0 over XRechnung has the advantage of having the PDF encapsulated and allowing a "basic" and an "extended" profil (with more information). The latter link essentially also says that ZugFERD 2.0 compliant invoices can be used for the official invoicing towards governmental entities (which is the functional scope of XRechnung), so i think there is no specific need to work on a separate XRechnung module for.
According to
https://www.xoev.de/sixcms/media.php/13/XRechnung-v1-2-1.pdf
Page 12 an "UBL invoice and credit note messages as defined in ISO/IEC 19845:2015 and UN/CEFACT Cross Industry Invoice XML message as specified in XML Schemas 16B (SCRDM - CII) should pass the conformity validator on
https://github.com/itplr-kosit/validator
if they also
The first three items are tested automatically, the last one can only be validated by human intelligence with appropriate context. The most complex thing to comply with are the 65 business rules, constraints and extending rules (pages 61 ff.) defined in
https://www.xoev.de/sixcms/media.php/13/XRechnung-v1-2-1.pdf
I am not sure if the UBL xml export of the current module already complies to all or most of these but this may be tested.
Summary / Next steps If an UBL-file exportable by the already existing module already complies to the XRechnung conformity validation than we may only add some controls / translations / explanations for users of the modules that effectively allow using these as XRechnung documents.