Sales Pack - XInvoice

[yuri]

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

[hom]

Hello Yuri,

if a global solution for payment processing is not possible, instructions for creating and customizing custom fields would be very helpful.
Many thanks in advance.

[Nina]

Thank you Yuri!

You can't see the wood for the trees...
... it was very obvious.

[yuri]

Hi Nina,

We have a built-in Due Date field in the Invoice entity type. You need to use it instead of the custom field. You may need to add it to the Detail layout.

[yuri]

I think I'll write a tutorial how to add use custom fields in e-invoices.

After some research and analysis I came to a conclusion that the payment terms design we have discussed above will not suit well if we add the Payments feature to Sales Pack in the future.

[Nina]

HI!

As we should already be sending out the first e-invoices... :/
I wanted to take care of the settings in ESPO today.


Maybe I don't have a good overview yet, but I still get the following error messages and can't find where I can currently make the entries.


Invalid invoice.

Failed rule ID: BR-CO-25

In case the Amount due for payment (BT-115) is positive, either the Payment due date (BT-9) or the Payment terms (BT-20) shall be present.


When we started using the sales pack, we actually created fields for ‘Payment due date’. But it doesn't know how to use them now.

Unfortunately, this is the first time I've dealt with e-invoicing. Unfortunately, I haven't found anything in the documentation at the moment.

Or has this not yet been implemented?
I can't quite make heads or tails of the thread here ;D

Maybe you can give me a hint where I can find the settings

[hom]

Hi Yuri,

I share your view that stability should come before rapid implementation. My question was more about whether implementation can be expected before the end of the year? Because this is the only way to meet the obligation to use e- invoicing, which comes into force at the beginning of next year.

[yuri]

I don't know yet. It's risky to hurry with implementation

[hom]

Hi Yuri,

do you think that payment information for electronic invoicing and a description field (BT-22) will be implemented in near future?

[hom]

ok, that sounds great.

[yuri]

I read that in Germany it's a requirement to have one payment mean per Invoice. But it's not in all countries that way.

There's is a parameter to limit max number of items in a Link-Multiple field. An admin can set it to 1.

[yuri]

It's better to implement according the original standard. It will be up to user whether to add multiple payment options. If we implement one, it will be impossible to migrate in the future to many without issues.

[hom]

I don't think it is intended to specify multiple payment methods in an e-invoice. As far as I have checked the available templates and programs, there is always only one payment method to be used. As far as I have seen, there are not even different accounts for a bank transfer. Only one payment method is used with the corresponding information.

If anyone has any other information on this, please write.

[yuri]

Thanks for input.

As the standard allows multiple Payment Means and it's a common practice to offer multiple payment means in an Invoice, we'd rather allow multiple means too.

It could be done with many-to-many relationship. Payment Mean would be a separate entity.

[yuri]

> Please also include the "Description" field from the invoice module in the E-Invoice as an "Invoic note" (BT-22). The field already exists, it is just not yet included in the E-Invoice schema.

It's tricky as one may use Description for internal purposes and not willing the text to be exposed to a customer