Sales Pack - XInvoice

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

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

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.

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

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

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

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]

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)

[ThomasB]

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 Look here: https://github.com/dompdf/dompdf/pull/3269

[user_4711]

thank you! i'll keep an eye on it, too.

[item]

i have "like" on github.. maybe the PR will be merged

[yuri]

Yet another problem to solve is generating CII. Currently we only have UBL implementation.

[hom]

Hello Yuri,

Firstly, I would like to thank you for the great job you did implementing e-invoice!
It must have been a lot of work, especially as there are so many different standards.

I installed the latest sales pack 2.4.1 and made all possible adjustments so that I could create an e-invoice according to the XRechnung standard. The implemented validator does not show any errors either, but there are fields that are additionally required and I don't know whether I simply haven't found them or whether they are not (yet) implemented.

The following is missing for me:

1) With the XRechnung Standard 3.0.1/3.0.2 the following field is required: ProfileID. The field references the BT-23 requirement, where a static value is stored according to which rules or standards the invoice was created. For Germany (as an example), the value "urn:fdceppol.eu:2017oacc:billing:01:1.0" would be entered. As this may differ in other countries, it would certainly be helpful to store the ProfileID as an additional field in the ‘Seller Information’. If there is no general list, at least a free field would be useful.

2) It is also necessary to store the payment information. This is to be used as section ‘PAYMENT INSTRUCTIONS’ BG-16 and contains information on how the payment should be made. I am not quite sure where this information is to be stored in the ESPO or whether this setting has not already existed for a long time and I have just not found it.
The PAYMENT INSTRUCTIONS have the following attributes
- Payment means type code : Code [1]
- Payment means text : Text [0..1]
- Remittance information : Text [0..1]
- CREDIT TRANSFER : CREDIT TRANSFER [0..*]
- PAYMENT CARD INFORMATION : PAYMENT CARD INFORMATION [0..1]
- DIRECT DEBIT : DIRECT DEBIT [0..1]

Please let me know if I can make the settings myself or if they already exist.
I am happy to continue supporting the process and thank you again for the great work!

[yuri]

Thanks for input.

I've added the standard ProfileID value for XRechnung in the new version.

The online validator for 3.0.1 does not catch when the ProfileID is missing for some reason.

Regarding Payment Instruction. There's no the Payments functionality in Sales Pack at the moment. It was planned for the future. Before we have it implemented, I'm not sure how we could make it possible for users to specify values for an E-Invoice.

[yuri]

Added a preparator interface. Developers can add additional items to an E-Invoice from custom fields and related entities.

[hom]

Thank you very much, that sounds excellent!

[hom]

Hello Yuri,

do you have an example or instructions on how and where the preparator interface can be addressed?

[yuri]

I don't have an example.

Bind implementation https://docs.espocrm.com/development/di/#binding

Interface:

Espo\Modules\Sales\Tools\Invoice\EInvoice\Preparator

To be bound to a custom implementation.

The default implementation:

Espo\Modules\Sales\Tools\Invoice\EInvoice\DefaultPreparator

To be called inside the custom implementation.

This should be trivial for programmers who have experience in OOP.

This is not an official guideline. No guarantee that the implementation will not change in the future.