Sales Pack - XInvoice

[yuri]

Here's the tutorial on how to add custom fields: https://forum.espocrm.com/forum/deve...-in-sales-pack

[Nina]

Hey,

We delivered the first XRechnung invoices yesterday!
Thanks to the tutorial!

Now we've received the first feedback - we need to add more fields. The feedback came from several customers :/

We were asked for BT-19 (Buyer accounting reference) - ‘Cost centre’ - "Kostenstelle"

Also options for the following fields:

- Specialised service (specialist service) "Fachdienst"
- Product (I don't know what is meant here, I got a numerical value)
- Order number (I think BT-13)
- Is there a free field? e.g. for remarks?

Are these still provided or is there a copy template to implement them?

Thank you very much!

Nina

[yuri]

Hi Nina,

Buyer References is already there. You might need to add it to the Invoice's Detail layout.




BT-13 is not available out of the box. You can use a custom field to store the Purchase Order Reference. The library has "setPurchaseOrderReference" method.

> Is there a free field? e.g. for remarks?

Not yet. I think you can use a custom field and the "addNote" method.

> Product (I don't know what is meant here, I got a numerical value)

I don't know what it is.

[Nina]

Hey,

Thanks for your reply.
I have swapped the Electronic Address Identifier with the Buyer Reference :/....... sorry...

That's the standard from hell :/

Thank you very much! I'll have a look at the other fields.
Hopefully you'll understand it all at some point

[yuri]

In v2.6.6 added Purchase Order Reference and Note fields. These fields are mapped to E-Invoice.

[Nina]

Hey,

I would like to know how to change the invoice type

There are the following types ( <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>:

TypeCode: 326 - Partial invoice (actually: Partial final invoice)
TypeCode: 380 - Invoice (current standard)
TypeCode: 381 - Credit note
TypeCode: 384 - Invoice correction

Is there a possibility?

We have many “partial invoices” - we previously split the order.
In the same way as our cancellation now has to work differently.

How could this be set up?

Thank you!

[yuri]

Hi Nina,

Use the tutorial to create a custom preparator. Then, in your custom preparator class you can call $eInvoice->setType(381); Where 381 is an example code.

[yuri]

I have already worked out the data design for payment means. The way it will be coherent with an extensible providers feature. Will be available in a future version.

[hom]

Hello Yuri,

the eInvoice in Espo works quite well with some custom adjustments. Thanks for that!

However, it turns out that a small adjustment would be necessary, which cannot be solved sensibly with a custom field. It concerns the description of an invoice item (BT-154). This is not included in the eInvoice, but already exists as a standard field in the invoice.

Would it be possible to include the existing item description field as an item in the eInvoice?
The field would have the following assignment:
BT-154 Item description - Item description

This field is not a mandatory field, but the item description is almost always necessary for customers to be able to check the invoice.

Please let me know if it's possible?

HOM

[yuri]

Hi, I'll look into.

[hom]

Hi Yuri, thanks for adding the notes to the eInvoice. That helps a lot!

[yuri]

In the future version there will be E-Invoice support for:

• payment Credit Transfer
• SEPA Direct Debit mandates
• taxable shipping charges

[yuri]

Hi everyone,

I was thinking about integrating with some PEPPOL access point service. If anybody has some thoughts on this subject, please share.

[Provata]

Yuri,

have a look when it becomes mandatory for which size of company - and check against your customer base.

We are a small SME - "end of 2027" for us.

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

[yuri]

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

[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

[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 :/

[GLMFM2026]

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

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

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!

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

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

[yuri]

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