Sales Pack - XInvoice

[user_4711]

sounds great, but i only found this discussion about PDF/X PDF/A Support in dompdf https://github.com/dompdf/dompdf/discussions/3191

[user_4711]

please take a look again at this place: https://github.com/horstoeko/zugferd...tPdfMerger.php we can use our created pdf documents and merge them with the xml data.


ZUGFeRD vs XRechnung:


File format:

ZUGFeRD is a so-called hybrid format (PDF/A-3), consisting of a visible PDF part in which a machine-readable XML part is embedded. In contrast, the XRechnung is a pure XML file.


Syntax:

The specification of a syntax ensures a uniform technical implementation of the e-invoice in the EU. The XML schemas UBL (=Universal Business Language) and CII (=Cross Industry Invoice) are considered permissible syntaxes. While ZUGFeRD can only be implemented in CII syntax, the XRechnung can be implemented in both syntaxes.


Target group:

The B2G sector, i.e. the sending of invoices to German authorities or the federal administration, was specified as the target or user group of the XRechnung invoice format. At the same time, ZUGFeRD emerged as the currently most widely used and therefore most accepted invoice exchange format between companies (B2B sector).
Advantages and disadvantages:

The X-Invoice was developed (specifically) for the B2G sector, while the ZUGFeRD format was specifically tailored to the needs of the business world. The latter format also covers the requirements of public administration from version 2.1.1 (Latest Version 2.2)

[yuri]

XRechnung is already almost implemented.

horstoeko/zugferd is not an option for us. We already use the PDF printing functionality based on dompdf which currently does not support PDF/A. Once they support it, we will be able to combine the current PDFs with the XRechnung XML. They plan to support it but no any timelines.

[user_4711]

yuri Thanks for putting my post in the correct place.

As it looks for now:

B2G -> XRechnung works 100%, perhabs ZUGFeRD will work too but without warrenty
B2B -> ZUGFeRD: easy readable by humans AND has the XML Data integrated



i think we should look at the following projects:



Project horstoeko/zugferd

This package provides only support for CII - not UBL

Supported profiles

• EN16931 Minimum
• EN16931 Basic
• EN16931 Basic WL
• EN16931 Comfort
• EN16931 Extended
• EN16931 XRechnung 1.x
• EN16931 XRechnung 2.x
• EN16931 XRechnung 3.x

Source: https://github.com/horstoeko/zugferd



Project horstoeko/ubl

read and write xml files containing electronic invoice data in the UBL format

Source: https://github.com/horstoeko/ubl



Project horstoeko/orderx

read and write xml files containing electronic orders data in all Profiles ( https://www.ferd-net.de/standards/order-x/index.html )

Source: https://github.com/horstoeko/orderx


direct Download for Zugpferd: https://www.awv-net.de/upload/ferd/zugferd22de.zip

Edit: format

[yuri]

https://forum.espocrm.com/forum/extensions/107297-new-statutory-rule-for-e-invoice-in-germany#post107297

[yuri]

Tried validation on https://invoice-portal.de/en/xrechnung-validator/.

While XRechnung 2.3 requires the Buyer Reference, the 3.0 version allows to omit it.

Checked the 3.0.1 specs (in German), it stipulates that some rules are applied only for B2G.

[yuri]

Thanks for pointing out information.

> When using XRechnung in B2B, no routing ID is required to address XRechnung.

But the standard tells that the field is mandatory. I understand, it will be up to the invoice issuer (Espo user) to specify some arbitrary value.

[ThomasB]

Maybe check this: https://en.e-rechnung-bund.de/e-invo...yer-reference/

https://xeinkauf.de/faq/xrechnung (german only, used translator)

How is the routing ID (Leitweg ID) used to address XRechnung in B2B?

When using XRechnung in B2B, no routing ID (Leitweg ID) is required for addressing XRechnung invoices. In the “Buyer reference (BT-10)” element, any other suitable identifier can be used for internal routing purposes. The “Buyer reference (BT-10)” element is merely a text field and does not use any schema definitions.

[yuri]

Another questions regarding German invoices. XRechnung has a rule BR-DE-15 "For German suppliers, the element “Buyer reference“ (BT-10) shall be provided".

Quote:

"BT-10 Buyer reference: The Leitweg-ID is an identifier developed to address public entities in Germany and may be used within XRechnung. KoSIT does not provide any Leitweg-ID from German public authorities. Public authorities themselves should provide the Leitweg-ID to the issuers of electronic invoices."

But, if XRechnung becomes mandatory not only for B2G but for B2B, how the Leitweg-ID can be provided/obtained?

[yuri]

There's a general EN 16931 standard that is extendable by design. Different countries have different standards upon that basic once. Usually, it's additional validation rules or more restrictive rules. The e-invoice should also contain the specification identifier.

I consider an international (Europe only for now) solution, not only German/France specific.

[shalmaxb]

As far as I understand, there are general European rules, complemented with some countrywise rules. The Link from peterberlin provides the german version, but there is an english verson for developers: https://en.e-rechnung-bund.de/e-invo...are-companies/
I am not able to judge all this, but perhaps it could help you yuri .

[yuri]

I have some questions which are important for the future implementation. Will appreciate if anybody with experience could answer.

1. Would we need the ability to export the same invoice in different formats? When one format is needed for a customer, another – for our company. For example, XRechnung and RO_CIUS.

2. Would we need the ability to export different invoices in different formats? For example, one invoice for Romanian customer in their regional format/standard, another invoice – in German format.

Thanks

[yuri]

One more project that may be useful https://github.com/easybill/zugferd-php.

[yuri]

There's some movement in Dompdf into supporting PDF/A. That's good news for us.

[yuri]

> EspoCRM is not suitable for generating invoices in Germany.

Maybe still suitable as it's not yet 2025.