Sales Pack - XInvoice

[yuri]

Yes, you need to set the e-invoice type in the custom preparator.

[Christian Pan]

Hi Yuri!

So I managed to adjust the invoicing logic to not output any negative unit prices anymore and therefore can now generate XRechnung for regular invoices (code 380), cancelled invoices and refunds. All of those are stored in the entity type invoice. Therefore the infomration stored in BT-3 (CreditNoteTypeCode) is always 380 wehn generating an e-invoice. I can't use the internal funtionality of EspoCRM to issue a refund, therefore I need to go this way.
The invoice type is stored as a string in a custom text field of the entity Invoice and also defined by two set link fields (just like the field 'Previous Invoice'), one for the cancelled invoice and one for the the invoice a refund is issued of.

I guess the only way to output a different code other than 380 in the BT-3 field is the custom preparator again, right? Setting a valid id in 'Previous Invoice' results in said field being populated, but no change of the invoice code (still 380).

Thanks in advance!

[Michael Schlumberger]

Hi Yuri,
It's great that ZUGFeRD is now supported.
Now we can do everything with espocrm.

ZUGFeRD requires a PDF/A-3b file.
The Sales module apparently cannot create this, as the requirement seems to be overridden. We use Sales 4.4.3 and 10.0.11.
Or have I overlooked something else that needs to be configured?

Michael

[Christian Pan]

Hm, ok. Then I now at least know what I have to work on.
Thank you very much for the fast reply and help!

[yuri]

This is a constraint of XRechnung, not our constraint. Invoices with negative Unit Price are not allowed by the specification. Such invoice would be invalid and would not be accepted by the portal.

There's no such an option (would be strange for us to implement such) other than customizing the E-Invoice preparator.

[Christian Pan]

Hi Yuri,

thanks for the fast reply!

Yes, we use negative Unit Price, Amount and Grand Total Amount in specific cases. Unfortunately changing that to negative is not possible at this point...

So I guess right now there's no option to just ignore the negative value (i.e. Unit Price, Tax Amount or Grand Total Amount) and simply parse the positive value in the XML file?

[yuri]

Hi Christian,

In XRechnung, negative Unit Price is not allowed, while negative Quantity is allowed. Maybe you used negative Unit Price?

[GLMFM2026]

Oh, I was not suggesting a dedicated discount entity. Just an additional field per invoice that is applied to the total. I just realized that XRechnung allows for 0..n allowance/charge items, which explains the need for an entity. We'll customize the preparator for our use case then, thank you! 👍

[Christian Pan]

Hi!

I'm the poor soul in charge of implementing X-Rechnung in our system and just got it to work today after finally figuring out the solution to the following error when trying to create a X-Rechnung:
"The Seller postal address shall contain a Seller country code (BT-40)
ERROR: (500) The Seller postal address shall contain a Seller country code (BT-40)"

The solution is quite simple, if you know the souce of the issue. We simply didn't specify any country codes like described on https://docs.espocrm.com/administration/addresses/. It took me a while to fix that one. Entering "DE" in the country field in Administration -> Sales Pack settings didn't work either.

Well, with this sorted out I'm now running into the next problem: We can't generate any X-Rechnung when the billed amount of either any invoice item or the grand total amount is negative. In our case cancelled invoiced result in negtive values for amount and grand total amount, as do refunds. Therefore we can't generate any X-Rechnung for any of those two invoice types.

Is there any way to fix that? I already had a look at your link for the custom preparator but don't quite understand that, to be honest.

We are still running on espo v9.3.10 with Sales Pack v4.0.11 since I couldn't update to v10.x yet (a lot of custom invoicing code and other connected systems in our case, which will need a WHOLE LOT of testing afterwards...).

Any help with the X-Rechnung issue would be very appreciated!

[yuri]

Allowances as separate entities are not planned. It was considered to map negative quantity line items as allowances in E-Invoice. It is only an idea in the backlog.

[GLMFM2026]

I suppose that will work for us. Are there plans to officially support invoice allowances in the future?

[yuri]

Since we don't have the allowances feature in Invoices we cannot support it in E-Invoice. It is easy to customize the E-Invoice preparator to support your custom fields: https://forum.espocrm.com/forum/deve...-in-sales-pack.

[GLMFM2026]

Hi! Awesome to hear about ZUGFeRD support at last!

Will there eventually be support for document level allowances (BG-20)? We have currently modeled this using a custom field and a beforeSave script, but it doesn't end up in XRechnung exports this way :/

[yuri]

ZUGFeRD / X-Factur support was added in Sales Pack v4.4.3. It requires EspoCRM v10.0.11 to function.

[hom]

Hello Yuri,

I can provide feedback from Germany. E-invoicing is now used across the board for invoicing federal authorities and, in some cases, state authorities. Our company have been sending all our invoices to authorities via e-invoicing and email for almost a year.
E-invoices are transmitted to authorities almost exclusively via the OZG-RE portal. There are four ways to transmit invoices to this portal:

1) Via Peppol
2) Via email
3) Upload via the web interface, or
4) Direct entry/creation on the web interface

Registration on the OZG-RE portal is mandatory for each of these transmission methods.

In addition to the transmission of e-invoices, Peppol also provides for the exchange of all kinds of other documents. However, I am not aware of any authority or communication where this happens. Currently, only e-invoices are exchanged via the OZG-RE portal.

So basically, Peppol is a common way to transfer e-invoices. However, this requires you to have a paid Peppol service provider or (even more expensive) to operate your own Peppol access point.

I am therefore not sure how great the demand for Peppol is, especially since Peppol's other services for transferring documents other than e-invoices (in my view) are not yet relevant.

Perhaps other (customers) among you will come to a different conclusion because there are national differences or because you are active in areas that we do not cover.

Best regards, H*